hi toby you said: "VM timeouts are measured on the order of minutes, not seconds" - I have not seen this in practice since over a year ago when GAE will still young. currently, every site I've measured is collected in seconds (10, maybe 20)
also: "to write a "Hello World" python app that responds from a cold start on the order of 100m" - again, I have not seen this in practice for quite some time. the simplest of python sites, with no imports and very little code seem to start in the 500ms to 1s range (and sometimes, much longer). Please note Nick's post here, where he changed his original cold-start metrics: http://bit.ly/6Fsoxv I'm now under the impression that slow VM startups is a GAE issue and while user imports are critical to keep them reasonable once they are started, there is a lot of overhead that is completely out of our control. The only way I've found to keep low traffic sites bearable is to use polling from the task queue, so IMO, the title of this post is quite appropriate cheers brian On Dec 9, 12:26 pm, 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-appeng...@googlegroups.com. > > To unsubscribe from this group, send email to > > google-appengine+unsubscr...@googlegroups.com<google-appengine%2Bunsubscrib > > e...@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.
