Improving Google App Engine Performance
- Performing in the Cloud
- Measuring the Cost of Class Loading
- Avoiding Cold Startups
- Improving Performance in General
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Throughout this book, a lot of attention is given to performance optimization. By improving performance, you get the added benefit of lowering the usage costs of your application when you surpass the App Engine’s free quota. This chapter explains performance characteristics specific to the Google App Engine environment. It starts by discussing the process of starting and stopping instances in the cloud. The cost of starting an instance is demonstrated by showing the performance of a servlet using a third-party library compared to the performance of a plain vanilla servlet. This chapter also offers pointers for minimizing and, where possible, avoiding cold startups. Finally, it provides a high-level overview of performance-related topics you can find in other chapters in this book.
Performing in the Cloud
One of the unique selling points of cloud computing over traditional hosting is high scalability and flexibility when responding to changes in the demand of your application. The pricing model of cloud computing is especially convenient if you experience sudden high spikes in the number of visitors on a regular basis.
In the cloud, you pay for what you use. On the App Engine, this means that if your traffic is usually below Google’s free daily quota and you have only incidental traffic spikes, you pay only for the computing power used during the days with high spikes. The advantage of cloud computing over having a physical machine park capable of handling high-traffic spikes is that you are not paying for machines that remain idle except during a traffic spike.
This flexibility also introduces a new challenge that might not be apparent at first sight. Responding to changes in demand means starting and stopping instances multiple times per hour. The time necessary to respond to a change in demand is directly related to the time necessary to start your web application. This means that your web application does not necessarily become flexible and scalable simply because it is deployed on the App Engine. You need to optimize your application to get the most out of the specific circumstances of running on the Google App Engine.
Comparing the App Engine to Traditional Web Applications
Whereas the lifetime of a typical App Engine instance is measured in minutes and hours, the lifetime of a traditional web application instance is measured in weeks or months. Traditional web application here means a web application running on a physical machine that you maintain yourself rather than an application running in the cloud.
One of the most common approaches to optimizing the performance of a traditional web application is to take a performance hit on startup of the instance. For example, if you load a lot of classes and data into memory during startup, you can save loading time while processing the actual user requests because starting and stopping an application instance is unrelated to handling a request.
Taking a performance hit during the startup of a new instance is not such a good idea, though, if a website visitor is waiting while your application is starting. You may lose a visitor every time a new instance is started.
In addition, the scalability requirements of the App Engine ask for different storage strategies. Most traditional web applications are based on relational databases. Strategies for optimal usage of a relational database can sometimes be catastrophic when applied to NoSQL storages like the Google App Engine datastore.
As a result, web application frameworks originally designed for use with software stacks can lead to bad results when used on the App Engine without consideration.
Optimizing Payments for Resources
On the App Engine, you pay for the resources you use. This means that optimizing your application to use fewer resources also leads to cost reductions.
On the App Engine, some resources are more expensive than others. The optimal usage versus cost ratio depends on the characteristics of your application. How much data do you store? How much traffic is generated by your visitors? How is the traffic distributed over the total data set? How much data processing is involved? How is the number of visitors distributed over time?
When you consider these questions and look at the current pricing tables on Google’s site, you quickly find that you may have an optimization challenge. Take a look on http://code.google.com/appengine/docs/billing.html for more information.
Although there is no silver bullet for an optimal cost reduction, this book aims to give you the most control over the performance and costs of your web application.