Unfortunately, for static content all you can do is set expirations, unless you route static through your application, which I wouldn’t recommend.

For dynamic content however, you should make sure to generate etags and expiration times for as much stuff as possible, such as for example user avatars. What you then do is compare the etag the browser sends to you to the one you’ve generated, and return a 304 if they match. I’d recommend caching the generated etag but not the actual content; It is not worth it, simply pull it out of the datastore when it’s actually needed; In other words when the etags don’t match, or one isn’t provided.

My personal experience tells me that setting expiration and etag works best for caching, the other options are not worth the bother.

I’ve run into some of the same issues. Looking at your site, I notice that none of your static files return 304’s on subsequent requests, resulting in firefox requesting them on every single request. You might want to look into generating proper expirations and etags – I found this to help a metric ton on app engine, particularly for e.g. uploaded images (since they come from the datastore). Your 10 min expirations doesn’t seem to make firefox actually bother caching anything.

In addition to this; The short term cpu quota is extremely easy to saturate during spikes if your site does not run with a good deal of headroom to the ~350ms google considers the max for a reasonable request. The reason for this is that google will spawn up new processes, and this is very expensive (typically 3x as long – if not more, depending on complexity). At the same time request handling time will increase on existing processes (why that counts in the request time I don’t know; It’s in their framework/infrastructure, not in our code).

All in all, the quota system is funky as hell, and I struggle to understand how they expect us to ever use those 200k gigacycles you get every ~5 hours (the stats shown on the dash is for a 5 hour window), since any reasonable load to come near that will end up triggering enough high cpu warnings to exhaust that separate quota before even getting close. I suspect the quota works in this way so they can charge you for spikes, and use the free quota as a buffer for real sites, so you end up paying for getting slashdotted, but not normally.

How many requests have you been getting out of curiosity?

The limits, as Shane stated, are short term CPU limits. The problem is that I have no idea what is causing them. I’m not doing a lot of parsing or anything. It’s a simple site and I’m trying to be as good a citizen as possible — caching stuff whenever possible, etc.

I mean I’m getting over quota errors on a view that does essential nothing more than rendering a Django template — there must be something wrong with the system.

My friends at Google just cleared the quotas again but that’s just a short-term solution. This short-term quota thing has to be fixed somehow.

I’m sending over my code to the Google team in a few moments so they can look it over and make sure that I haven’t implemented the KillGoogleAppEngine anti-pattern or anything so maybe something will come of that.

But, looking at the logs, I really don’t think it’s my code.

@Fernando: There are several reasons I’m sticking with them. First and foremost, I still believe that it’s going to be a great platform and I’ve learned heaps about it. When it does mature a bit more, I plan for us to take advantage of it. The way I see it, we have a group of some of the top engineers in the world working for our app every day at Google.

Also, it’s not trivial to port away from Google App Engine. Yes, the site is 90% Django but the remaining 10% is the datastore and that’s not trivial to port. Hosting on the SDK is not an option (it’s not a deployment environment.)

There’s a tax you pay for being an early adopter but, in this case, I feel that it will be a worthy investment. And, if none of us took the plunge and braved it, then there would be no innovation. Standing and pointing from the sidelines is all well and good but new platforms need early adopters and — even more importantly — they need to listen to them and their feedback.

We just have to get through this rough patch — and the Google team are helping out as much as they can so I’m sure that we will.

HOWEVER, if it can’t be used for production sites then how are folks supposed to figure out if it can work for them at all? The quota’s the head site is hitting are not ones you can pay to get over — they are specific limits on processing and bandwidth over a very short period of time put in place so you don’t use up your quotas or overload a particular back end machine in a short period of time.

This line pretty much sums it up: “All of our quotas are listed in terms of a rolling 24 [hour] window, although there are limits on the amount of resources your application can consume during shorter periods of time.”

One thing is a quota and another appears to be an fixed limit of an undocumented amount. Also read the paragraph at the bottom of this page: http://code.google.com/appengine/articles/quotas.html

The problem here is that they make it unclear if you’ll ever be able to pay to get over the limits. I’ve seen Google apps return errors at times and then start working again. This limiting factor may be part of how their infrastructure works to keep as much as possible running for as much time as possible.

The fact that the errors can’t be caught is interesting. The fact that the limits can be hit with 404s is very bad.

If the limits hold true even in to “ForeverBeta” and if 404s still count against quotas and limits, then GAE may forever remain Google Toy Engine for micro-projects.

Let’s just hope efforts that Aral, and others, are putting in will sway Google in a way that allows true scaling of apps under stress rather than just blocking apps under stress.