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%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<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.
