Google App Engine and High load
The Eurovision 2009 gadget, which we, Sterno.ru , did for Google, turned out to be an excellent experience in testing App Engine and testing what this technology is capable of. Now we understand much better how the "Application Engine" works under high loads. This article describes the strengths and weaknesses of the Google App Engine, as well as the pitfalls that developers may encounter during its use.
1. CPU_ms limit per request and page
If with each request you do a lot of calculations on the server, then the page will quickly use up its limit and become inaccessible.
2. Limit on total requests per day
')
About one million requests to the service are allowed per day, including requests for pictures and other resources. With heavy loads this number is very easy to reach. The main difficulty is that this resource cannot be bought! Even with billing enabled, such requests will not be counted as paid, and if all the same million are reached, the application will stop working. To avoid this, we had to transfer files for banners to the Amazon S3 file storage service.
3. Limit on requests per second
When the intensity is more than 500 requests per second, the application stops working. In normal situations, to achieve such a high load is not easy. In the case of the Eurovision gadget, it turned out because of the banner ads. 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. We cache EVERYTHING!
Everything that is given to user requests should be taken directly from memcache. To completely avoid problems, it is better to create crones that will update the cache on a schedule. Then even rare user requests will not require access to the database and make additional calculations. So we close the weak side number 1.
2. At maximum, we transfer 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 the rest requests will no longer load it. By this we close the second and third weak side.
3. Turn on billing, even if it is not needed.
As already mentioned, there are enough free limits for App Engine if the application is well optimized. For a Eurovision gadget with a load of up to 300 requests per second, 5 cents were charged for the entire time. And even then only on the day of the final, when, of course, the interest of users jumped.
The main plus of billing (its inclusion allows App Engine to charge for overspending limits) is that free resources still remain. But the resources for which you can not pay, will increase their limits by 50 times! I accidentally noticed that after switching on billing for a Eurovision gadget, the limit on the number of requests per day increased from a million to 50 million :)
4. Do not store user data in the application.
If you save user settings and profiles in the database, then with large 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 is not built 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 servers and does not affect our application in terms of social networks (frending, comments, ratings, etc.). In general, FriendConnect is a terrific service that makes it easy to connect powerful social features to almost any site. Of the minuses - gives an additional load on the browser (due to the use of JavaScipt) and slightly increases the traffic during the initial load. However, in the future, all scripts are cached.
On the App Engine, you can do almost anything if you know how to cook it :)
At the same time, even for a loaded site, it is quite difficult to exceed free limits (if you work with it correctly), and even when 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 must be sufficiently brutally optimized, which increases the development time, unfortunately. In principle, this requirement is true for any sites, but in the case of App Engine optimization is doubly needed! .. Of course, this very much depends on the type of project. If there is a bit of interactivity on the site, then the situation with the speed of work will be saved by caching at the topmost level (return generated html). However, not always the problem of performance can be solved so simply.
PS We have posted on Habré a copy of this article by Eugene Demchenko, because we think that it may be interesting not only to readers of GoogleApps.ru .
Weak sides:
1. CPU_ms limit per request and page
If with each request you do a lot of calculations on the server, then the page will quickly use up its limit and become inaccessible.
2. Limit on total requests per day
')
About one million requests to the service are allowed per day, including requests for pictures and other resources. With heavy loads this number is very easy to reach. The main difficulty is that this resource cannot be bought! Even with billing enabled, such requests will not be counted as paid, and if all the same million are reached, the application will stop working. To avoid this, we had to transfer files for banners to the Amazon S3 file storage service.
3. Limit on requests per second
When the intensity is more than 500 requests per second, the application stops working. In normal situations, to achieve such a high load is not easy. In the case of the Eurovision gadget, it turned out because of the banner ads. 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. We cache EVERYTHING!
Everything that is given to user requests should be taken directly from memcache. To completely avoid problems, it is better to create crones that will update the cache on a schedule. Then even rare user requests will not require access to the database and make additional calculations. So we close the weak side number 1.
2. At maximum, we transfer 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 the rest requests will no longer load it. By this we close the second and third weak side.
3. Turn on billing, even if it is not needed.
As already mentioned, there are enough free limits for App Engine if the application is well optimized. For a Eurovision gadget with a load of up to 300 requests per second, 5 cents were charged for the entire time. And even then only on the day of the final, when, of course, the interest of users jumped.
The main plus of billing (its inclusion allows App Engine to charge for overspending limits) is that free resources still remain. But the resources for which you can not pay, will increase their limits by 50 times! I accidentally noticed that after switching on billing for a Eurovision gadget, the limit on the number of requests per day increased from a million to 50 million :)
4. Do not store user data in the application.
If you save user settings and profiles in the database, then with large 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 is not built 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 servers and does not affect our application in terms of social networks (frending, comments, ratings, etc.). In general, FriendConnect is a terrific service that makes it easy to connect powerful social features to almost any site. Of the minuses - gives an additional load on the browser (due to the use of JavaScipt) and slightly increases the traffic during the initial load. However, in the future, all scripts are cached.
Summary:
On the App Engine, you can do almost anything if you know how to cook it :)
At the same time, even for a loaded site, it is quite difficult to exceed free limits (if you work with it correctly), and even when 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 must be sufficiently brutally optimized, which increases the development time, unfortunately. In principle, this requirement is true for any sites, but in the case of App Engine optimization is doubly needed! .. Of course, this very much depends on the type of project. If there is a bit of interactivity on the site, then the situation with the speed of work will be saved by caching at the topmost level (return generated html). However, not always the problem of performance can be solved so simply.
PS We have posted on Habré a copy of this article by Eugene Demchenko, because we think that it may be interesting not only to readers of GoogleApps.ru .
Source: https://habr.com/ru/post/62927/
All Articles