On Wed, Dec 9, 2009 at 2:11 PM, Devel63 <danstic...@gmail.com> wrote:
> Toby, > > In the past, it was several minutes before an active instance would be > swapped out. Of late, I have seen it repeatedly/regularly happening > within several seconds. > This is something we monitor fairly closely. The average lifetime of an idle VM varies as the load across App Engine varies, but they do not timeout "within several seconds". One thing you might be seeing is that a burst of several requests can cause more than one VM to be loaded simultaneously. > I've avoided (so far) the auto-ping approach; your idea to auto-ping > only when a user is on a page is intriguing. Still wasteful and > "wrong", but perhaps necessary. > Sending a single ping a few seconds ahead of time for a user is very low waste. > Yes, I have voted for the paid warm instance :-) > > Finally, I don't understand how I can significantly reduce my warm up > time. I suppose I could split each "page" into a separate app.yaml > handler (already done for admin versus user tasks), but then the user > would even more certainly run into startup issues when navigating > within the site. Besides, most of the time is spent importing Django > and system stuff I can't control. > You can control whether or not you use Django. I also don't understand how splitting your app into separate handlers would cause more startup issues for you. > The only reason I'm using Dango (0.96) is for translations ... is > there a built-in way to handle translations via webapp? > Sorry, I'm not that familiar with what's available for Python, but my understanding is that Django is aggressive about up front initialization. On Dec 9, 9:26 am, Toby Reyelts <to...@google.com> wrote: > > Responses inline. > > > > On Sun, Dec 6, 2009 at 7:49 PM, Devel63 <danstic...@gmail.com> wrote: > > > Toby, you write that it doesn't usually pay to optimize loading > > > requests. > > > > > I agree with this whole-heartedly when you have your own server, and > > > only load once per day or month. It's probably true using GAE when > > > you have 100K+ page views per day. > > > > I think there's a misunderstanding here. What I said was that it's not > worth > > optimizing loading requests in regards to quota. Latency is a separate > > concern. > > > > > But for lower-volume web sites, GAE performance is atrocious. In my > > > personal case, we have optimized in all sorts of ways (js > > > minification, liberal use of memcache, image sprites, sticking with > > > Django 0.96, etc.) ... but the typical user experience is quite poor. > > > It takes 3-10 seconds for the first page to load, and then often the > > > instance is swapped out while the user reads the current page, so that > > > the next request experiences the same thing. If the app is warm, > > > performance is fine. > > > > If your VM is timing out while a user is actively visiting the site, then > > your site is extremely low traffic. VM timeouts are measured on the order > of > > minutes, not seconds. So, for example, that means that you didn't receive > > any traffic to your VM at all for several minutes between the time the > user > > fetched the first and second pages. > > > > > Maybe this gets appreciably better as traffic improves, but of course, > > > I can't see that at present. > > > > Yes, as stated above, VMs are not aggressively collected. In the normal > > case, if you have an active user of your website, you shouldn't see a > > cold-start per request. Maybe in your particular case you can > asynchronously > > ping your backend (for example, with an AJAX request) a few seconds > before > > they continue onto the next page? > > > > I love GAE in theory, but it's getting > > > > > harder to ignore the reality of low-volume performance. > > > > As stated above, I think you're falling into a particularly bad extreme > > (continuous cold requests for an "active" user). This might require some > > creativity (for example, as above) to work around. > > > > In terms of speeding up the loading request itself, the good news that > the > > bulk of of that time is directly under your control. As an existence > proof > > of this, you should be able to write a "Hello World" python app that > > responds from a cold start on the order of 100ms. This means you might > try > > doing things like paring down the dependencies that you load on cold > > requests. You can also take advantage of the fact that requests for > static > > content bypass your VM and are never "cold". So, for example, you can > serve > > a page that is comprised mostly of static content almost instantly, and > let > > it make AJAX requests to asynchronously fill in its dynamic content as > your > > VM warms up. > > > > If you'd rather just pay to have us maintain a warm VM for you, you can > vote > > on that issue. > > > > > On Dec 4, 3:38 pm, Toby Reyelts <to...@google.com> wrote: > > > > On Oct 23, 3: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 > > > > > > I'm not sure what you mean here, but we have plans to change the > admin > > > > console to explicitly call out loading requests, so you can take that > > > > into account when profiling your application. Until that becomes > > > > available, it's pretty easy for you to detect and log loading > requests > > > > yourself. > > > > > > > 2. It is stupid that google counts warming up your app toward CPU > time > > > > > (leading to profiling, that leads to pinging) > > > > > > A couple of things: > > > > > > 1) CPU time doesn't grow on trees, it comes out of your free or paid > > > > quota. Why should we hide this from you? > > > > > > 2) The number of loading requests your application receives are > > > > inversely proportional to its traffic. If you get more traffic, > you'll > > > > receive fewer loading requests. This means it usually doesn't pay to > > > > optimize loading requests, unless you're just trying to reduce user > > > > latency. > > > > > > > 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. > > > > > > Unfortunately, it takes an inordinate amount of physical hardware to > > > > keep on the order of millions of applications in memory, which is > > > > somewhat counter to free. If our startup optimizations plus your own > > > > optimizations don't satisfy you, then maybe you can voice your > opinion > > > > on paying for a warm VM (http://code.google.com/p/googleappengine/ > > > > issues/detail?id=2456)? > > > > > > > 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. > > > > > > Google App Engine already serves static resources without intervening > > > > requests to application VMs. This means that, for example, you could > > > > serve a page that was entirely static content, with a small amount of > > > > JS to ping your VM with an asynchronous dynamic request to wake it > up. > > > > That page would be served instantly to the user. You need to ensure > > > > though, that the resources are indeed specified as static content in > > > > your app.yaml or appengine-web.xml. > > > > > > > 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<google-appengine%2bunsubscr...@googlegroups.com> > <google-appengine%2bunsubscr...@googlegroups.com<google-appengine%252bunsubscr...@googlegroups.com> > > > > > . > > > For more options, visit this group at > > >http://groups.google.com/group/google-appengine?hl=en. > > -- > > 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-appeng...@googlegroups.com. > To unsubscribe from this group, send email to > google-appengine+unsubscr...@googlegroups.com<google-appengine%2bunsubscr...@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/google-appengine?hl=en. > > > -- 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-appeng...@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.
