Google App Engine and High load
The Eurovision 2009 gadget that we, Sterno.ru , made for Google, turned out to be an excellent experience in testing the App Engine and checking what this technology is capable of. Now we understand much better how the Application Engine works at high loads. This article describes the strengths and weaknesses of the Google App Engine, as well as the pitfalls that developers may encounter while using it.
1. Limitation of CPU_ms per request and per page.
If you make a lot of calculations on the server with each request, the page will quickly use up its limit and become inaccessible.
2. Limit on the total number of requests per day.
About one million requests for the service are allowed per day , including requests for pictures and other resources. Under heavy loads, achieving this number is very easy. The main difficulty is that this resource cannot be bought! Even with billing turned on, such requests will not be counted as paid, and upon reaching the same million, the application will stop working. To avoid this, we had to transfer banner files to the Amazon S3 file storage service.
3. Limit on the number of requests per second
With an intensity of more than 500 requests per second, the application stops working. In ordinary situations, achieving such a high load is not easy. In the case of the Eurovision gadget, this happened because of advertising banners. Such a problem may occur if the page with your service is advertised on popular network resources - the main page of Yahoo !, Slashdot or Digg.
1. Cache EVERYTHING!
Everything that is given to user requests should be taken directly from memcache. To completely avoid problems, it is better to create cron'y that will update the cache on a schedule. Then even rare user requests will not require access to the database and perform additional calculations. So we close the weak side of number 1.
2. At maximum, we transfer the static content to external servers.
All images, CSS, Javascript is better to upload to Google Code and give to users directly from it. From our application, users will receive only cached html, and all other requests will no longer load it. This closes the second and third weaknesses.
3. Turn on billing, even if it is not needed.
As already mentioned, there are enough free App Engine limits if the application is well optimized. For the Eurovision gadget, with a load of up to 300 requests per second, 5 cents were withdrawn for the whole time. And even then only on the day of the finale, when, of course, the interest of users jumped.
The main plus of billing (its inclusion allows App Engine to charge money for limit overruns) is that free resources still remain. But resources that cannot be paid for will increase their limits by 50 times! I accidentally noticed that after turning on billing for the Eurovision gadget, the limit on the number of requests per day increased from a million to 50 million :)
4. We do not store user data in the application.
If you save user settings and profiles in the database, then under heavy loads you will have to update the cache too actively, since users will very often save their data in the database. It is clear that a social network cannot be built in this way.
To fully work with users and their data, you must use Google Friend Connect. It is very easy to connect to any site, gives full authorization through Google Account, Yahoo! or OpenID. After that, all user data is stored directly on Google’s servers and does not affect our application in terms of social networks (friendliness, comments, ratings, etc.). In general, FriendConnect is an amazing service that makes it easy to connect powerful social features to almost any site. Of the minuses - it gives an additional load on the browser (due to the use of JavaScipt) and slightly increases traffic during initial loading. However, in the future, all scripts are cached.
You can do almost anything on the App Engine if you can cook it :)
At the same time, even for a loaded site it is quite difficult to exceed free limits (if you work correctly with it), and even if they are exceeded, the fee is low. This is much more profitable than using similar services from Amazon, where you have to pay for each day of use.
Any application needs to be brutally optimized, which increases development time, unfortunately. In principle, this requirement is true for any sites, but in the case of App Engine optimization is doubly necessary! .. Of course, this very much depends on the type of project. If there is not much interactivity on the site, then the situation with the speed of work will be saved by caching at the highest level (returning the generated html). However, far from always the performance problem can be solved so simply.
PS We placed on Habré a copy of this note by Evgeny Demchenko, because we think that it can be interesting not only to GoogleApps.ru readers .
Weaknesses:
1. Limitation of CPU_ms per request and per page.
If you make a lot of calculations on the server with each request, the page will quickly use up its limit and become inaccessible.
2. Limit on the total number of requests per day.
About one million requests for the service are allowed per day , including requests for pictures and other resources. Under heavy loads, achieving this number is very easy. The main difficulty is that this resource cannot be bought! Even with billing turned on, such requests will not be counted as paid, and upon reaching the same million, the application will stop working. To avoid this, we had to transfer banner files to the Amazon S3 file storage service.
3. Limit on the number of requests per second
With an intensity of more than 500 requests per second, the application stops working. In ordinary situations, achieving such a high load is not easy. In the case of the Eurovision gadget, this happened because of advertising banners. Such a problem may occur if the page with your service is advertised on popular network resources - the main page of Yahoo !, Slashdot or Digg.
Tips & Tricks:
1. Cache EVERYTHING!
Everything that is given to user requests should be taken directly from memcache. To completely avoid problems, it is better to create cron'y that will update the cache on a schedule. Then even rare user requests will not require access to the database and perform additional calculations. So we close the weak side of number 1.
2. At maximum, we transfer the static content to external servers.
All images, CSS, Javascript is better to upload to Google Code and give to users directly from it. From our application, users will receive only cached html, and all other requests will no longer load it. This closes the second and third weaknesses.
3. Turn on billing, even if it is not needed.
As already mentioned, there are enough free App Engine limits if the application is well optimized. For the Eurovision gadget, with a load of up to 300 requests per second, 5 cents were withdrawn for the whole time. And even then only on the day of the finale, when, of course, the interest of users jumped.
The main plus of billing (its inclusion allows App Engine to charge money for limit overruns) is that free resources still remain. But resources that cannot be paid for will increase their limits by 50 times! I accidentally noticed that after turning on billing for the Eurovision gadget, the limit on the number of requests per day increased from a million to 50 million :)
4. We do not store user data in the application.
If you save user settings and profiles in the database, then under heavy loads you will have to update the cache too actively, since users will very often save their data in the database. It is clear that a social network cannot be built in this way.
To fully work with users and their data, you must use Google Friend Connect. It is very easy to connect to any site, gives full authorization through Google Account, Yahoo! or OpenID. After that, all user data is stored directly on Google’s servers and does not affect our application in terms of social networks (friendliness, comments, ratings, etc.). In general, FriendConnect is an amazing service that makes it easy to connect powerful social features to almost any site. Of the minuses - it gives an additional load on the browser (due to the use of JavaScipt) and slightly increases traffic during initial loading. However, in the future, all scripts are cached.
Summary:
You can do almost anything on the App Engine if you can cook it :)
At the same time, even for a loaded site it is quite difficult to exceed free limits (if you work correctly with it), and even if they are exceeded, the fee is low. This is much more profitable than using similar services from Amazon, where you have to pay for each day of use.
Any application needs to be brutally optimized, which increases development time, unfortunately. In principle, this requirement is true for any sites, but in the case of App Engine optimization is doubly necessary! .. Of course, this very much depends on the type of project. If there is not much interactivity on the site, then the situation with the speed of work will be saved by caching at the highest level (returning the generated html). However, far from always the performance problem can be solved so simply.
PS We placed on Habré a copy of this note by Evgeny Demchenko, because we think that it can be interesting not only to GoogleApps.ru readers .