Google App Engine application instance recycling and response times_问答_开发者

I posted this on GAE for Java group, but I hope to get some answers here quicker :)

I decided to do some long-run performance tests on my application. I created some small client hitting app every 5-30 minutes and I run 3-5 of threads with such client.

I noticed huge differenced in response times and started to investigate issue. I found reason very quick. I am experiencing same issues as described in following topics:

Uneven response time between connection to s开发者_运维技巧erver to first byte sent

Application instances seem to be too aggressively recycled

Getting 'Request was aborted after waiting too long to attempt to service your request.' after application idle

I am using Springframework, it tkes around 18-20s to start app instance, which is causing response times to take from 1s (when requests hits running app - very rare) to 22s when fresh application is created.

Is there any solution for this? I was thinking about creating most basic servlet performing critical tasks (serving API call) and leave UI as is. But then I would loose all benefits of Springframework.

Is there any solution for this?

After solving (hacking) numerous constrains of App Engine which I hit while developing my app that is the one I think will make me move out of App Engine... that's simply to much to all the time think how to win with GAE problems than how to solve my application problems...

Any help?

Regards Konrad

I know of some people having a keep-alive thing running in order to have an instance of their app always running. I mean, have a client that sends a request every X seconds so your app doesn't get recycled.

This is a quick thing to implement but seems to go against the spirit of the platform. Make your numbers and check if it is worth it.

Another option would be to refactor your application to make use of more lazy-loading than it does at the moment so it doesn't take that long to kick off.

I don't know if you have any other option apart from these 2.

Use the new precompilation feature.

<!-- appengine-web.xml -->

<precompilation-enabled>true</precompilation-enabled>

What would be good is if we could serialize the DispatcherServlet to the memcache, and then deserialize it from the memcache on a cold start if it is there. Then the instantiation of Spring would be really short.

DispatcherServlet is already marked as Serializable, we just need to find a way to serialize the WebApplicationContext object that the DispatcherServlet contains.

in case folks live in AE-land and want a quick-and-dirty keep-alive pinger, this one works like a charm (windows):

http://www.coretechnologies.com/products/http-ping/

SDK 1.4.0 has this new feature:

Developers can now enable Warmup Requests. By specifying a handler in an app's appengine-web.xml, App Engine will attempt to to send a Warmup Request to initialize new instances before a user interacts with it. This can reduce the latency an end-user sees for initializing your application.

This is definitely a tricky issue with AppEngine applications. The purists will tell you to look at why your application takes so long to start up and work backwards from there. In your case, the answer is obvious: you are using Spring, and it has to load many class files and instantiate many objects.

The pragmatic answer, if you can live without Spring, is to make sure that you app instance stays warm. You can either ping it from an external source frequently enough that AppEngine never unloads it, or you could use an AppEngine cron job that runs frequently enough to keep your app in-memory.

I am sure that Google despises the second option, as that runs against much of the fundamental ideas behind AE, but nevertheless, it is an issue that they and we 9as AE developers) must consider.

Here is a related discussion