Google AppEngine dashboard

From Iphone
Jump to: navigation, search

Server Engines

If your app requires a server back end, your developer may have gone with Google's App-Engine (GAE.) For certain kinds of processing, GAE provides a number of benefits:

  • The full force of Google's data-center infrastructure.
  • Free for small amounts of data.
    • This allows testing and small data loads to happen at no cost.
    • The Free usage has bandwidth and CPU quotas. Read the GAE billing page for more info.
  • HTTPS (secure HTTP) is available at no charge.
  • It has a solid, well documented API and, hence, is easy to develop for certain types of applications.

The Dashboard

A quick tour of the GAE Dashboard:

  • Visit The App Engine Page
  • Log in using your Google account credentials (same as your gmail account.)
    • You will be taken to the "My Applications" page. Select your app.
  • The default view here is the dashboard.
    • Here, you can view your resource usage and, in particular, your progress against the daily quotas.
    • You may see spikes several hours long during development. These represent periods of high testing activity.
      • Don't worry if there is a long period of "no testing." This does not demonstrate that no one was working on your project, only that the activity has been in an other area.
    • NOTE: During development, the server version might change frequently.
      • If you have a preview (ad-hoc) app, it will be tied to a specific version of the server, which is likely not the latest one. This allows ad-hoc previews to be released against a tested, stable server while development continues to move forward to the next phase.
    • Requests Per Second will give you a general sense of how often all users of your app are hitting the server.
    • CPU Seconds per Second" indicates the rate at which you are consuming your CPU quota.
      • A spike in this number may indicate server errors. See Troubleshooting, below, for more information.
    • Quota Denials per Second indicates unfulfilled requests, due to quota limits.

Server Logs

On the left side of your app's dashboard is a link to Logs, which will show you the server's output.

  • Initially, the logs display only messages with a severity of Error or greater.
    • Ideally, the error log would be blank (or the most recent entry a long time ago.)
    • If the server is reporting errors, use the + icon to expand that log entry, and copy/paste the entire text of the log message (it may be quite long) into an email to your developer.
  • To see all of the server output, set the minimum severity to Debug.
    • The server outputs quite a bit of information each time it is used. This is helpful in tracking down problems but is otherwise not particularly interesting.

Data Store Viewer

The Datastore Viewer option (left panel) allows you to view the contents of your server's data files.

   *** IMPORTANT ****
   Do NOT edit the data files by hand!  Do not use the Create or Delete buttons, nor manually edit the contents of records.
   Any mistakes made here will be VERY costly to correct.
   If data needs to be altered, talk with your developer about how to have the server make the changes.

Other than the "gee whiz" factor, the datastore isn't particularly interesting viewing.

Trouble Shooting



Anticipating Quota Limits

Each pricing tier -- including free -- has quota limits for CPU time and bandwidth.

When a quota is met, no more requests will be served until either

  • The quota period is reset (daily, as of this writing.)
  • The quota is raised by purchase of a higher quota level.

Quotas are a powerful tool in that they assure you that some unforeseen event won't drive your server costs through the roof.

Quotas carry the risk that, if set too low, some of your customers may be denied service without explanation.

Before release of your product, some load testing can be done in which several users use your app heavily. From the resulting resource usage, some rough calculations can be done to determine the approximate load your current quotas can handle. IMPORTANT: resource usage is somewhat variable. Different actions taken by different users will result in differing loads on the server. For this reason, it's a good idea to run several tests with several users over a period of time and plan according to worst-case scenarios.

When your app is newly released (and at every update release), monitor your resource usage (on the dashboard) closely so that you can discern trends in resource usage and adjust your quota/budget accordingly. Once you are comfortable with the levels and rate of change, you can reduce your monitoring as appropriate.

Some things to consider:

  • How much resources you need is a business decision with risks at every turn.
    • If your server is typically running at 30% capacity, you have the benefit that your usage could more than triple without interruption but at the cost of too much server.
    • If your server is typically running at 90% capacity, you have the risk that even a small spike in usage could result in unanswered requests (i.e., unhappy customers) but the benefit of lower server costs.
    • As a very coarse rule of thumb, run far-too-much server during initial growth -- 3-10x the daily requirement, monitored and adjusted frequently. Once your usage pattern has somewhat stabilized, carry approximately 50% more server than you need to handle your peak anticipated usage over the next bit of time (that is, have enough server to stay comfortably below 66% capacity), and adjust your quotas as often as your usage patterns indicate that you are falling short (or, in the case of reduced usage, over-server-ed.)
  • How much resource your app uses is also a business decision, though a less risky one.
    • While we write our apps to be reasonably conservative with CPU-time, bandwidth and other resources, not a great deal of effort was spent squeezing every last ounce of performance out of the server, unless you specifically asked for that.
      • This means that there is likely a fair bit of room for improvement. You will need to weigh the benefits of reduced resource usage against the cost of optimizing your server.
      • For smaller user loads, it's typically less expensive -- at least in the immediate term -- to increase the quota. As your user-base increases, it makes more sense to look at reducing per-use server resource usage.

Bottom line: You need to monitor your server's resource usage closely, and understand how various user-actions result in resource-consumption which, in turn, is part of the cost of operation. How you make adjustments to the app and how you monetize your user-base to cover the ongoing costs is YOUR business, and nobody's going to care for it as well as you do!


  • The Billing Settings (left panel) shows your current free and paid quotas, quota limits, and cost per use.
  • The Versions section shows what versions of your server are available. Each time you release a new client app, a new server may be activated simultaneously, depending on the features. DO NOT DELETE old versions until you are absolutely certain that they are no longer used. There is no cost to keeping old versions of the server.
  • There are a number of other items available from your dashboard. Feel free to poke around and learn about them, but DO NOT CHANGE ANYTHING without fully understanding the implications.
    • DO NOT ASSUME, if you don't actually know.