Jeff, in one point i disagree.
In a high available einvironment you would have a cluster of load balanced application servers and you would deploy new versions of your app in turn, one at a time. So if one instance is down the other(s) will continue serving your users (though it might require sticky sessions). Of course, this is a must for enterprise applications. Regards, Stephan 2010/1/13 Jeff Schnitzer <[email protected]> > 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]<google-appengine-java%[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]<google-appengine-java%[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]<google-appengine-java%[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.
