Do you see that it's consistent at the same times? What's your application ID? I'll look into it.
On Mon, Dec 14, 2009 at 11:28 AM, Dave Peck <[email protected]> wrote: > Hello, > > I have an app (citygoround.org) that, especially in the morning, often > has 10-15 minutes of outright downtime due to server errors. > > Looking into it, I see that right before the downtime starts, a few > requests log the following warning message: > > > Request was aborted after waiting too long to attempt to service > your request. > > Most likely, this indicates that you have reached your > simultaneous dynamic request limit. > > I'm certainly not over my limit, but I can believe that the request in > question could take a while. (I'll get to the details of that request > in a moment.) > > Immediately after these warnings, my app has a large amount of time > (10+ minutes) where *all requests* -- no matter how unthreatening -- > raise a DeadlineExceededError. Usually this is raised during the > import of an innocuous module like "re" or "time" or perhaps a Django > 1.1 module. (We use use_library.) > > My best theory at the moment is that: > > 1. It's a cold start, so nothing is cached. > 2. App Engine encounters the high latency request and bails. > 3. We probably inadvertently catch the DeadlineExceededError, so the > runtime doesn't clean up properly. > 4. Future requests are left in a busted state. > > Does this sound at all reasonable? I see a few related issues (2396, > 2266, and 1409) but no firm/completely clear discussion of what's > happening in any of them. > > Thanks, > Dave > > PS: > > The specifics about our high latency request are *not* strictly > relevant to the larger problem I'm having, but I will include them > because I have a second "side" question to ask about it. > > The "high latency" request is serving an image. Our app lets users > upload images and we store them in the data store. When serving an > image, our handler: > > 1. Checks to see if the bytes for the image are in memcache, and if so > returns them immediately. > 2. Otherwise grabs the image from the datastore, and if it is smaller > than 64K, adds the bytes to the memcache > 3. Returns the result > > I'm wondering if using memcache in this way is a smart idea -- it may > very well be the cause of our latency issues. It's hard to tell. > > Alternatively, the issue could be: we have a page that shows a large > number (~100) of such images. If someone requests this page, we may > have a lot of simultaneous image-producing requests happening at the > same time. Perhaps _this_ is the root cause of the original "Request > was aborted" issue? > > Just not sure here... > > -- > > You received this message because you are subscribed to the Google Groups > "Google App Engine" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<google-appengine%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/google-appengine?hl=en. > > > -- Ikai Lan Developer Programs Engineer, Google App Engine -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
