Besides the cold startup problem, I can't recall reading about any GAE success stories where java was the language of choice. Probably most java frameworks are too big and too slow to start for what GAE is trying to do. What I'm saying is that even if Python is slower as a language, the most crucial factors for a web app performances on GAE are cold startup time (that is lower in python) and access to the datastore (that is the same), not the language speed itself. There have been endless threads on ways to split a java app in order to minimize the cold startup time. Basically one has to keep the frontend as small as possible, and that means not using the frameworks one would normally use (I know a lot of people don't like that).
On Tuesday, 5 February 2013 07:36:17 UTC+13, gafal wrote: > > Hi Tomas, > > thanks a lot for your suggestions. I'm indeed, using Spring framework. > Your suggestions require a lot of work and I'd rather make my application > GAE framework free and get the possibility to change Paas provider if I'm > not satisfied by their service instead of locking me further with GAE. Sure > I like the framework but I'm not completely crazy blind about it ;-) > > > Le lundi 4 février 2013 19:19:38 UTC+1, Tomas a écrit : >> >> Hi gafal >> >> I totally understand your frustration - I've done some development on App >> Engine when it started and I still run some of the application there. I was >> moaning about the cold starts issue in couple of threads but I kind of sure >> that if there would be a simple solution the GAE team would probably fix >> that (I'm little bit worried that if they would do the proposed magic >> button "never start a new instance for user facing request" they will >> probably face some other (for-us external devs unforeseen) issues or maybe >> it just a step against the whole philosophy of the GAE platform - but who >> knows). >> >> However, in last month I've noticed very poor performance of my App >> (which was running on M/S datastore all the time - I was getting a lot of >> cold stars, exceptions from datastore/memcache/tasks) so I've decided to >> redeploy to HR (my data are not important so I didn't need to think about >> db migration and so). And I'm again pretty happy with the performance - I >> didn't change line of the code, I'm using the minimal paid version and I >> keep all the instances on automatic (no resident instance) - I can see that >> the GAE runs two dynamic instances and keeps them alive for tenth of >> thousands request and very occasionally starts a new instance - well last >> time when Google bot visited me (I have a 100k pages in google index now) >> it was quite interesting to watch how the GAE dealt with the traffic, it >> just scaled so beautifully. >> >> I had to say that my app uses pure servlets + jdo so the cold startup >> time is ~5-6 seconds - which is even acceptably for occasional user facing >> requests. I've tried to migrate the app to Spring MVC >> (+velocity+ehcache+rest+bunch of other libraries) and as far as I can tell >> this scenario is not suitable for the GAE atm - cold starts above 45secs >> are too long and the GAE tries to spin up new instances very often. >> >> So the conclusion for myself and maybe something for further discussion >> with other gae devs is (and now I'm talking about java apps only): >> >> 1) forget about using Spring MVC and other Spring based frameworks (if >> you don't want to spend money on multiple resident instances) - you can of >> course try to fire up 1 min cron job to keep dynamic instances app but from >> my experience the scheduler starts some new instance even if there are a >> dynamic instances available >> 2) use pure servlet + jsp's (seems like gae is pretty going to be more >> and more optimized for jsp's - all the precompilation and jar packaging >> which happens on deploy and so on) >> 3) make your app from smaller independent applications - at the moment >> I'm splitting the app logic into smaller components each running as a >> separate app (so I have a component for displaying images/book covers, >> another component for getting book information, another component for >> getting book prices and so on) - I'm going to use these component apps as >> REST/JSON based backends and call them from the main app (which basically >> just puts all data together) through async requests >> 4) be prepared to handle all possible exceptions - anything can happen >> with GAE (datastore, memcache/task and so so) - catch everything and handle >> properly (try to set some timeouts as well) or if your request will timeout >> on stuff like this gae will keep spinning new and new instances >> 5) caching everything - for db use objectify (which caches almost >> automatically) >> >> If you REALLY REALLY would like to use the Spring MVC (or similar DI >> framework) consider to move the frontend app somewhere else - I've put a >> beta version on Appfog (and experimenting with Openshift as well which got >> me on Tomcat7 support + absolutely awesome war deploy through GIT and ssh >> console!) and I test it atm (but I'm still going to keep all the API >> backends on GAE probably) - my MVC app is just presentation logic talking >> through REST template to GAE and some other API's (it doesn't have any >> database) >> >> Just my 2 cents. >> >> Cheers >> >> Tomas >> >> On Tuesday, 5 February 2013 07:03:48 UTC+13, gafal wrote: >>> >>> And of course Multithread activated. >>> Even with min pending latency of 14.9s, some users hit cold instances >>> and get 20 to 40 s latency depending on GAE performances... >>> >>> Le lundi 4 février 2013 18:56:40 UTC+1, gafal a écrit : >>>> >>>> Just to clarify. I've tested all the suggestions offered in the forums. >>>> I'm paying around 100 $ per month to GAE. >>>> >>>> I've warmup requests activated, >>>> I've idle instances, >>>> I've played with the min and max Pending Latency settings >>>> I've cron job every minute >>>> >>>> I did not want to quit (I really enjoyed GAE besides this CRITICAL >>>> issue) and I'm unhappy to do it when I think about all the work I have to >>>> do to free my application from GAE framework. :-( >>>> >>>> >>>>> -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/google-appengine?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
