John, sure it is something worth trying. My experience tells me that an other handler usually means a new instance, but then again you have when the part using Django will be cold started in a brand new instance when needed, even though an instance is already running. So it all depends on your usage pattern - what part is running more frequently etc. One approach is to initiate a cold start of the heavy instance through a ping through js once you feel your user is probably going to request this heavy Django driven page. i.e. a timeout function in your landing page. This is more green and economic solution than pinging in constant intervals. For some info on instance lifetime you can take a look at http://gaengine.blogspot.com/2009/09/server-instance-life-time-part-ii.html
Happy coding On Oct 24, 8:40 pm, johntray <john.tur...@gmail.com> wrote: > Is the current thinking that the biggest startup delay is due to > module imports for Django? My app has 3 distinct parts, only 1 of > which uses Django or any templating. Right now I use a single main() > function for all 3 parts, but would the other 2 parts have better cold- > start times if I partitioned them into a separate handler script that > didn't import any Django stuff? > > On Oct 23, 4:02 pm, bugaco <ice...@gmail.com> wrote: > > > > > I had a bit weird experience with this... > > > So I wrote app (http://analytics.bugaco.com) that runs on App Engine. > > Than I looked at the request logs to see how it is running. > > Request logs suggested that I'm using a lot of CPU time on hitting the > > home page, but after that CPU time significantly decreases. It also > > had annoying red flag suggesting that servlet is using excessive > > resources and that I need to optimize it. > > Testing a bit, I noticed that pinging lets app be warm, and I had cron > > doing the pings for a few days; while also noticing that it does not > > do anything useful > > > Conclusion: > > 1. If log files don't suggest that you are better off pinging people > > would not ping > > 2. It is stupid that google counts warming up your app toward CPU time > > (leading to profiling, that leads to pinging) > > 3. It is very stupid that applications can not denote 'keep this code > > path warm/cache it/or something' that will allow new users not to give > > up on the up until they get first response. > > > So, as a conclusion, I think AppEngine is AWESOME. And I also think it > > SUCKS. > > I love SDK, ability to deploy and test and use all the cool things. > > I don't like the idea that it can not serve a (entry)page in 3-5 > > seconds as I think that it leaves bad taste in users mouth, and > > consequently bad taste in developers mouth. > > > Finally, I am not sure I'll use AppEngine for developing other > > applications as I'd rather go with paid hosting that provides some > > level of performance on serving pages. I think Google would win a lot > > of good will if they at least provide quick serving of static > > resources. > > > One may wonder how to do that, and given that they have all those yaml > > files there may be yaml file that specifies a warm static resource. > > This would decrease a need for pinging your app as it would allow user > > to hit entry page, and google to pre-cache app much easier. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to google-appengine@googlegroups.com To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~----------~----~----~----~------~----~------~--~---
