A little data point action... Very low traffic site (just me, occasionally experimenting with AppEngine/Python). Simple google.appengine.ext.webapp.template usage.
http://browsermodern.appspot.com/ Cold start: 500ms Cold CPU: 400ms Warm start: 10-30ms Warm CPU: 0-20ms Swap gap: 1.5-2.0 minutes While 500ms seconds isn't huge, it can be a concern (for those that want to show more than a blank page or waiting icon during the '50ms first impression window'). I agree that the static+AJAX approach is a fast architecture (coughstilllackingfibertothecurbcough), durable, and fits well with 0.1% datastore misses. Lazy imports might help, for some use cases. http://news.bbc.co.uk/2/hi/technology/4616700.stm http://www.julianbrowne.com/article/viewer/brewers-cap-theorem http://wiki.python.org/moin/PythonSpeed/PerformanceTips#ImportStatementOverhead -- G On Dec 10, 5:19 am, bFlood <bflood...@gmail.com> wrote: > 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.
