Here are information about the load test that I run yesterday on "Qwerty" (my GWT and GAE application).

The peak of requests on the graph is 23 requests/second. I think it is a mean for 1 minute. For users it was impossible to see that the application was under such a load. The application received a maximum of 35 requests/second.

chart

In one hour, the server received 40000 requests. It is about 10 requests/second during one hour.

Just before 4PM, I put a new version of the application in production. At that time their was about 10 requests/second. It was unnecessary and risky. But sometimes you have to upload a new version of your application during high traffic and I wanted to see if it was possible. All run perfectly.

 

Pete Koomen, Product Manager on the Google App Engine Team gives me a couple of tips on make sure my app scales during the load test :

We think scaling on App Engine is a lot easier, but it does require thoughtful design.  If stick to the following principles, you'll be making great use of your free resource quotas.  If, on the other hand, some of your queries are very inefficient, you may run into our quota on "high CPU requests" long before you actually run out of CPU quota.

  • Avoid unbounded queries.  I noticed on your recent scores page that you may be fetching a lot of entities.  In general, large queries like this don't scale, and you should consider showing only the most recent 10 or so scores from each "color".
  • Do computation incrementally using the datastore, rather than all at once.  An example would be keeping a running tally stored in the datastore and incrementing it on-the-fly rather than using Query.count().  HOWEVER, if that tally is written or read on every request, you'll run into trouble fast (see next point).
  • Avoid contention on datastore entities. If every request to your app reads or writes a particular entity, latency will increase as your traffic goes up because reads and writes on a given entity are sequential. One example construct you should avoid at all costs is the gobal counter, i.e. an entity that keeps track of a count and is updated or read on every request.
  • Avoid large entity groups. Any two entities that share a common ancestor belong to the same entity group. All writes to an entity group are sequential, so large entity groups can bog down popular apps quickly if there are a lot of writes to that group. Instead, use small, localized groups in your design.

Some of these came from a blog post on the topic--there are a few more tips there you might find helpful (http://googleappengine.blogspot.com/2008/04/posted-by-ken-ashcraft-software.html)

It could be nice to organize a round 2...