I've been thinking about this issue a little. It's not quite as straightforward as just keeping an instance warm. Even if you have an app that gets multiple hits per second, there will still be cold starts:
* When a new instance comes online to serve more demand. * When you redeploy a version of your app. Is appengine smart about letting new instances added to the pool "warm up" before serving requests? It's hard to tell from my logs but it doesn't look like it. I know appengine is *not* smart about warming up an instance before redeploying. When I redeploy, some large number of users must wait while the appserver(s) startup. One thing to keep in mind during these discussions is how other Java EE environments solve this problem: They *don't*. For a long time it's been assumed in the EE development that server initialization time is irrelevant, and we grew fat libraries that take tens of seconds to minutes to start up. The problem is, this time has *never* been irrelevant - even in a production environment you must deploy new versions of your app, and none of the appservers I'm familiar with are smart enough to keep serving off the old version while the new one loads. Users with unlucky timing always got screwed. We just didn't care because we only deployed code once a week and we added/removed server instances far less often than that. Well guess what, now it's easy - you can deploy up to 1,000 times per day just by clicking a button in eclipse, and server provisioning is now not only trivial but 100% transparent to you. Just try that with WebSphere! You aren't going to like this, but here's the only answer that isn't going to piss off your customers: Stop using Spring. Stop performing eager initialization. Stop assuming that users don't see startup time. Yes, change the way you write code. Jeff On Tue, Jan 12, 2010 at 1:11 PM, Don Schwarz <[email protected]> wrote: > Make sure you are using offline precompilation. We are always working on > optimizations to decrease the latency of loading requests, but here are some > other tips: > http://googleappengine.blogspot.com/2009/12/request-performance-in-java.html > On Tue, Jan 12, 2010 at 3:01 PM, Locke <[email protected]> wrote: >> >> I agree that making users wait 20 seconds for your app to load is not >> adequate for the vast majority of apps. I also agree that >> reengineering everything to try and hide load times from users is a >> poor solution in most cases. >> >> Using cron to keep your app loaded will not consume your quota; it >> will actually conserve your quota. Every time your app loads you will >> be billed for 20s of CPU time. If you keep it loaded, you will only be >> billed for a few milliseconds per 'keep-alive' cron execution. >> >> However, the Google engineers who post here have recommended against >> doing this. If everyone did it, appengine might run out of resources >> (RAM, I assume). >> >> I imagine that Google will need to either find a way to load apps in >> 1/10th the time (the ideal solution), raise prices significantly, or >> ration resources in some other way. >> >> If I may make a suggestion to the Google engineers: offer a "keep my >> app loaded" option and make it available ONLY for billing-enabled >> apps. Disable cron for apps which are not billing-enabled, so that >> people who just want free hosting or are merely toying with appengine >> won't be using up resources all the time. >> >> This way, the people who have shown that they are serious about >> appengine (by laying their cash down) won't be driven away by the >> people who are just fooling with it. > > Yes, we are seriously considering something like this. Please star this > issue for updates: > http://code.google.com/p/googleappengine/issues/detail?id=2456 > >> >> On Jan 12, 1:43 pm, Konrad <[email protected]> wrote: >> > I asked same question on Stack Overflow (http://stackoverflow.com/ >> > questions/2051036/google-app-engine-application-instance-recycling-and- >> > response-times). >> > >> > So far proposed solutions (in SO thread and found on other websites) >> > do not satisfy me. Creating cron or any other kind of periodic HTTP >> > requests to keep instance up and running make no sense. First - there >> > is no evidence that this instance will serve next coming request (eg. >> > from different network location etc.), second - it will consume Quota >> > (which is less a problem). >> > >> > Other solution - refactoring app - replacing critical functionality >> > with lightweight servlet - sounds better, but is GAE forcing to go >> > back to CGI programming style? And I could replace let say - API >> > calls, but to keep UI in better performance shape I would need to >> > throw away Spring MVC. >> > >> > Can anyone confirm that this behavior will not be fixed (yes fixed - >> > as I think it is a blocker for any serious GAE usage)? Or can anyone >> > suggest different solution? >> > >> > Thanks >> > Konrad >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Google App Engine for Java" group. >> To post to this group, send email to >> [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> For more options, visit this group at >> http://groups.google.com/group/google-appengine-java?hl=en. >> >> >> > > > -- > You received this message because you are subscribed to the Google Groups > "Google App Engine for Java" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/google-appengine-java?hl=en. > >
-- You received this message because you are subscribed to the Google Groups "Google App Engine for Java" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
