Hi guys,



We are using Kinvey in Asia and we seem to be having very slow performance from the baas.kinvey.com server. We've setup monitoring which you can see at https://uptimer.at/https://baas.kinvey.com/appdata/ and its showing around 3,000 ms (!) load times on average. My guess is that this only an issue outside of the USA (we noticed that the server is hosted on AWS East 1).



Could you let us know if you have plans to deploy to other Amazon locations (Singapore would be of particular interest to us). Unfortunately at present it doesn't seem feasible for us to continue using the service unless performance can be improved.



Thanks in advance for your thoughts and advice,

Boris,

Samsung

The various monitoring solutions don't exactly match the performance the app is seeing. For example, they re-establish connections on every request, which includes a TLS handshake. The client libraries keep the connection open.

There are a number of steps you could perform to diagnose/troubleshoot and improve performance. You could run basic tools such as curl and mtr and see where the time is lost.

For most use cases it is highly beneficial to implement caching (http://devcenter.kinvey.com/html5/guides/caching-offline) to minimize round trips to the server.

Deploying in a different geography is, as you can expect, a chicken and egg problem - there has to be enough business to make the initial investment. It is best to talk to sales for this.

The baseline RTT from US to Singapore is 250ms. Adding a sub-100ms processing time at the server, a GET over pre-established connection should be well under 500ms. If you look at the base optimizations, such as connection re-use, reduced payload size (as applicable by the use case) and caching, you may find some dramatic improvements without a lot of work.

Thank you Ivan. We are going to try to implement caching and see if performance reaches acceptable levels. (Our use case is actually primarily on android)



FYI, here are some more test results:



US: http://www.webpagetest.org/result/131218_8J_7ZS/ (0.715s to first view)

Singapore: http://www.webpagetest.org/result/131218_C1_7VH/ (1.678s to first view - more than twice as slow)



And curl from my machine:



boris.masis@PITBORIS ~

$ time curl -L http://baas.kinvey.com/appdata/

{"version":"3.2.12","kinvey":"hello"}

real 0m1.802s

user 0m0.000s

sys 0m0.078s



boris.masis@PITBORIS ~

$ time curl -L http://baas.kinvey.com/appdata/

{"version":"3.2.12","kinvey":"hello"}

real 0m0.845s

user 0m0.015s

sys 0m0.046s



boris.masis@PITBORIS ~

$ time curl -L http://baas.kinvey.com/appdata/

{"version":"3.2.12","kinvey":"hello"}

real 0m0.814s

user 0m0.015s

sys 0m0.046s



boris.masis@PITBORIS ~

$ time curl -L http://baas.kinvey.com/appdata/

{"version":"3.2.12","kinvey":"hello"}

real 0m0.836s

user 0m0.031s

sys 0m0.046s



boris.masis@PITBORIS ~

$ time curl -L http://baas.kinvey.com/appdata/

{"version":"3.2.12","kinvey":"hello"}

real 0m0.786s

user 0m0.000s

sys 0m0.062s



boris.masis@PITBORIS ~

$ time curl -L http://baas.kinvey.com/appdata/

{"version":"3.2.12","kinvey":"hello"}

real 0m0.784s

user 0m0.000s

sys 0m0.046s

Wanted to follow up - did caching make things better?

Hi Ivan,



Yes, caching has definitely helped - it's made a big difference. Unfortunately we're still concerned about initial request times.



Thanks,

- Boris