I took a few measurements of your app around 9AM PST today (Monday). Your VMs were timing out at between 90 seconds and two minutes. As you've noticed, the number of loading requests increases as the amount of traffic on App Engine increases. This is why we discourage active pinging.
On Fri, Dec 11, 2009 at 9:16 PM, Devel63 <danstic...@gmail.com> wrote: > Toby, > > Here's a site that gets almost no traffic (not yet publicized): > www.lifehints.com > > Try it Monday morning at 9am PST and see how quickly it times out. > I've been seeing it apparently time out in a few seconds during the > workday. I suppose it's possible that what I'm seeing is Google > firing up another instance, but that sounds unlikely given that > there's no one else on the site most of the time. > > On a Friday evening (now), it's staying warm for quite some time. > > > On Dec 11, 8:57 am, Toby Reyelts <to...@google.com> wrote: > > On Thu, Dec 10, 2009 at 8: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) > > > > Do you have the appids of specific sites that you believe are timing out > > every 10 seconds? This is not what we're seeing. Are you sure you aren't > > seeing loading requests to several different VMs in parallel? > > > > 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 > > > > Nick's example is not "Hello World". He's cold-starting his blogging app > in > > less than 500ms. (I personally believe that is quite acceptably > responsive). > > > > What I'm driving at is that there's a minimum startup time which you can > not > > control as a developer, and that startup time is very low for python (on > > the order of 100ms). Everything else is under your control: What > > dependencies you have, what web framework you use, whether you push > static > > content and use ajax requests, etc... > > > > > 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-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> > ><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 > > > > ... > > > > read more ยป > > -- > > 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.
