Developing for Performance: application profiling can save you millions.

Recently read up on some features of Google’s AppEngine.  They impose quotas and limits on developers who use AppEngine for hosting.

My favorite is limiting processing time to a maximum of 30 seconds per transaction.  There are also quotas about things such as the number of URL call, image manipulations, data transmission per transaction, memcache api calls, and so on.

The reaction so far seems to be a consensus that they’ve come up with terms of service which reflect good coding and performance standards for a web application… and figured out how to monitor/enforce.  (Google does offer developers the option for paying extra if they can’t squeeze their transaction into the free quotas).

They’ve built application profiling into AppEngine and provided developers the option to use profile_main( )  {instead of the standard main( )} to invoke the profiling tools.  The profiling fuctions write all of the performance data to a log.

I’m not saying I know of any organizations who could have saved a couple hundred million dollars by challenging their developers to utilize existing application profiling tools to meet a similar set of performance standards, in lieu of purchasing hundreds of new servers.  Well, OK, I am saying that.

If you know someone with application performance problems whose thinking about purchasing substantial amounts of new hardware, you might suggest they try some application performance profiling first.   Without this sort of performance (and capacity) information, it’s likely the new equipment will either be deployed to the wrong places.  Or worse, it will be utterly excessive for the situation at hand.
Below are some of the the transaction specific limits from:

Quotas and Limits

Each incoming request to the application counts toward the Requests quota.

Data received as part of a request counts toward the Incoming Bandwidth (billable) quota. Data sent in response to a request counts toward the Outgoing Bandwidth (billable) quota.

Both HTTP and HTTPS (secure) requests count toward the Requests, Incoming Bandwidth (billable) and Outgoing Bandwidth (billable) quotas. The Quota Details page of the Admin Console also reports Secure Requests, Secure Incoming Bandwidth and Secure Outgoing Bandwidth as separate values for informational purposes. Only HTTPS requests count toward these values.

CPU processing time spent executing a request handler counts toward the CPU Time (billable) quota.

For more information on quotas, see Quotas, and the “Quota Details” section of the Admin Console.

In addition to quotas, the following limits apply to request handlers:

Limit Amount
request size 10 megabytes
response size 10 megabytes
request duration 30 seconds
simultaneous dynamic requests 30 *
maximum total number of files (app files and static files) 3,000
maximum size of an application file 10 megabytes
maximum size of a static file 10 megabytes
maximum total size of all application and static files 150 megabytes

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s