Ivan Zuzak – blog

How to supercharge your free AppEngine quota?

Posted in web development by Ivan Zuzak on August 27, 2009

This blog has moved to a new domain. You can view this post here.

AppEngine is awesome! Google’s cloud computing platform is hosting countless web apps, from Google products to innovative personal projects, and is constantly being upgraded with cool new featuresAnd best of all, AppEngine charges for resources (computing, storage and bandwidth) using a freemium pricing model:

“Each App Engine application can consume a certain level of computing resources for free, controlled by a set of quotas. Developers who want to grow their applications beyond these free quotas can do so by enabling billing for their application and set a daily resource budget, which will allow for the purchasing of additional resources if and when they are needed.”

For example, the default free quota has a daily limit of 6.5 hours of CPU time with a maximum rate of 15 CPU-minutes/minute, while the billing enabled quota has 6.5 hours of free CPU time plus a maximum of 1,729 hours of paid CPU time with a maximum rate of 72 CPU-minutes/minute.

Billing for paid resources is controlled with a daily budget which developers set for each of their applications. The daily budget controls the amount of extra resources which may be purchased each day if the app steps over the free quota. The application developer defines how the daily budget is split between each of the billable quotas – outgoing bandwidth, incoming bandwidth, CPU time, stored data and number of recipients emailed. For example, $1 (the minimum daily budget) gets you 5 more CPU hours ($0.10 per CPU hour) and 4 more GB of outgoing bandwidth ($0.12 per GB).

Other than billable quotas, there are also unbillable quotas which increase when you switch to the paid model but are not billed. So, by switching to the paid model, irregardless to how you distribute your budget, your app gets a free bump in the:

  • number of requests it can process from 1,300,000 to 43,000,000 and from 7,400 to 30,000 req/min,
  • number of outgoing HTTP requests from 657,000 to 46,000,000 and from 3,000 to 32,000 req/min,
  • number of memcache calls from 8,600,000 to 96,000,000 and from 48,000 to 108,000 calls/min,

and many others. These are very usable improvements by themselves for apps that need to process a lot of requests (or bursts of requests) which don’t consume a lot of CPU time, or apps that need to make a lot of outgoing HTTP requests that don’t consume a lot of bandwidth.

So here’s the idea for supercharging your free AppEngine quotas:

  1. switch you app to the paid model by enabling billing,
  2. enter the minimum daily budget ($1),
  3. distribute the budget over resources you are 100% sure will not consume their free quota (e.g. if you have a stateless app which doesn’t use the database, put the whole $1 in the stored data quota).

Since you put your budget on resources which won’t consume the entire free quota and since AppEngine doesn’t charge you anything if the app doesn’t step over the free quota – you are essentially getting a better free quota.

EDIT (Sept 5 2009): Yesterday, a week after my original post, Google released AppEngine SDK 1.2.5 which includes a major feature a lot of developers have been waiting for – XMPP support. What’s interesting and relevant for this post is that XMPP has it’s own quotas for the number of API calls, data sent, recipients messaged and invitations sent, and – none of these quotas are marked as billable. Therefore, using the recipe for supercharging your free quota will also get you a significant boost in your XMPP quotas (657k -> 46000k API calls, 657k -> 46000k recipients messaged and 1k -> 100k invitations sent). Pretty cool!

EDIT (Nov 2 2009): I just noticed that it is possible to increase the limit on the number of apps each AppEngine user can create. Currently, each user may create up to 10 AppEngine apps and there was no way to create more when you reached the limit, even by paying (or was there?). However, Google engineers have been approving explicit user requests for increases in the number of apps created on the official AppEngine group. People who have requested an increase have had the limit set to 20 apps.

Are there any other hacks for squeezing more out of AppEngine?  @izuzak


Named arguments in JavaScript

Posted in web development by Ivan Zuzak on August 9, 2009

This blog has moved to a new domain. You can view this post here.

While working on another project (pmrpc, which I will write about soon), the implementation of a feature came down to calling JavaScript functions with named arguments. Unfortunately, the JavaScript language (or EcmaScript to be exact) doesn’t support named arguments, rather only positional arguments.

Usually, JavaScript developers get around this by defining functions to accept a single object argument which acts like a container for all other named parameters:

// params is a container for other named parameters
function callMe(params) {
  var param1 = params['param1'];
  var param2 = params['param2'];
  var param3 = params['param3'];

  // do something...

var result = callMe({ 'param3' : 1, 'param1' : 2, 'param2' : 3 });

This solution works nicely when you are in the position to modify every function to be called this way. However, this is not always the case (e.g. when using external libraries), and also isn’t as readable as having a proper parameter list, and introduces code overhead in every function that implements this principle. What I needed for my project is something that enables calling any JavaScript function with named arguments, without modifying the function itself.

What I came up with (code presented below) is based on the following:

  1. using the toString method of the Function prototype, it is possible to retrieve a string representation of any function definition
  2. from the string representation, it is possible to parse the number, order and names of function parameters
  3. from a dictionary of named arguments, it is possible to construct an array of arguments in the correct order using the parsed representation
  4. using the apply method of the Function prototype, it is possible to dynamically call a function, passing an array of arguments instead of an argument list.
// calls function fn with context self and parameters defined in dictionary namedParams
function callWithNamedArgs( fn, self, namedParams ) {
  // get string representation of function
  var fnDef = fn.toString();

  // parse the string representation and retrieve order of parameters
  var argNames = fnDef.substring(fnDef.indexOf("(")+1, fnDef.indexOf(")"));
  argNames = (argNames === "") ? [] : argNames.split(", ");
  var argIndexes = {};
  for (var i=0; i<argNames.length; i++) {
    argIndexes[argNames[i]] = i;

  // construct an array of arguments from a dictionary
  var callParameters = [];
  for (paramName in namedParams) {
    if (argIndexes[paramName]) {
      callParameters[argIndexes[paramName]] = namedParams[paramName];

  // invoke function with specified context and arguments array
  return fn.apply(self, callParameters);

// example function
function callMe(param1, param2, param3) {
  // do something ...

// example invocation with named parameters
var result = callWithNamedArgs(callMe, this, { 'param3' : 1, 'param1' : 2, 'param2' : 3 });

This could also have been implemented as a Function prototype method and be called directly on a function object, which would simplify usage since the target function parameter wouldn’t have to be passed. But, if the CallWithNamedArgs function indeed was implemented prototype function, could the context parameter be removed also? I.e. is it possible to retrieve the current execution context (this object) of the target function within the CallWithNamedArgs method? The problem is that the execution context within the CallWithNamedArgs method is the Function object on which the CallWithNamedArgs method was called. But what we need is the execution context of the target function, which is the Function object on which the CallWithNamedArgs method was called. That is, what we need is the current execution context of the parent object. Any ideas? @izuzak