Гаджет «Евровидение 2009», который мы, Sterno.ru, сделали для компании Google, оказался отличным опытом в тестировании App Engine и проверки того, на что способна эта технология. Теперь мы гораздо лучше понимаем, как работает «Движок приложений» при высоких нагрузках. Эта статья описывает сильные и слабые стороны Google App Engine, а также подводные камни, с которыми разработчики могут столкнуться в ходе ее использования.
1. Ограничение CPU_ms на запрос и на страницу
Если при каждом запросе делать много вычислений на сервере, то страница быстро израсходует свой лимит и станет недоступной.
2. Ограничение на общее количество запросов в день
В день разрешено около миллиона запросов к сервису, включая запросы к картинкам и другим ресурсам. При больших нагрузках достичь этого числа очень легко. Главная трудность состоит в том, что этот ресурс нельзя купить! Даже при включенном биллинге такие запросы не будут учитываться как платные, и при достижении все того же миллиона приложение перестанет работать. Чтобы избежать этого, нам пришлось переносить файлы для баннеров на сервис хранения файлов Amazon S3.
3. Ограничение на количество запросов в секунду
При интенсивности более 500 запросов в секунду приложение перестает работать. В обычных ситуациях достичь столь высокой нагрузки непросто. В случае с гаджетом Евровидения это получилось из-за рекламных баннеров. Такая проблема может появиться, если страница с вашим сервисом рекламируется на популярных сетевых ресурсах — главной странице Yahoo!, Slashdot или Digg.
1. Кешируем ВСЁ!
Все, что отдается на запросы пользователей, должно браться напрямую из memcache. Чтобы полностью избежать проблем, лучше создавать cron’ы, которые будут обновлять кеш по расписанию. Тогда даже редкие запросы пользователей не будут требовать обращения к базе данных и производить дополнительные вычисления. Так мы закрываем слабую сторону номер 1.
2. По максимум переносим статический контент на внешние сервера.
Все картинки, CSS, Javascript лучше залить на Google Code и отдавать пользователям непосредственно с него. От нашего приложения пользователи будут получать только закешированный html, а все остальное запросы уже не будут нагружать его. Этим мы закрываем вторую и третью слабую сторону.
3. Включаем биллинг, даже если он не нужен.
Как уже было сказано, бесплатных лимитов App Engine хватает, если приложение хорошо оптимизировать. Для гаджета Евровидения при нагрузке до 300 запросов в секунду за все время было снято 5 центов. Да и то лишь в день финала, когда, понятное дело, интерес пользователей подскочил.
Главный же плюс биллинга (его включение разрешает App Engine взимать деньги за перерасход лимитов) состоит в том, что бесплатные ресурсы все равно остаются. А вот ресурсы, за которые нельзя платить, увеличат свои лимиты в 50 раз! Я совершенно случайно заметил, что после включения биллинга для гаджета Евровидения лимит на количество запросов в день вырос с миллиона до 50 миллионов :)
4. Не храним пользовательские данные в приложении.
Если сохранять пользовательские настройки и профили в БД, то при больших нагрузках придется обновлять кеш слишком активно, поскольку пользователи будут очень часто сохранять свои данные в БД. Ясно, что социальную сеть таким образом не построить.
Для полноценной работы с пользователями и их данными необходимо использовать Google Friend Connect. Он очень просто подключается к любому сайту, дает полноценную авторизацию через Google Account, Yahoo! или OpenID. После этого все пользовательские данные хранятся непосредственно на серверах Google и не затрагивают наше приложение в части, касающейся социальных сетей (френдование, комментарии, рейтинги и т.д.). Вообще, FriendConnect – потрясающий сервис, который позволяет с легкостью подключать мощные социальные функции практически к любому сайту. Из минусов – дает дополнительную нагрузку на браузер (в связи с использованием JavaScipt) и слегка увеличивает трафик при начальной загрузке. Впрочем, в дальнейшем все скрипты кешируются.
На App Engine можно сделать практически что угодно, если уметь ее готовить :)
При этом даже для нагруженного сайта довольно сложно превзойти бесплатные лимиты (если правильно работать с ним), и даже при их превышении плата невысока. Это гораздо выгоднее, чем использовать аналогичные сервисы от Amazon, где за каждый день использования необходимо платить.
Любое приложение нужно достаточно жестоко оптимизировать, что увеличивает время разработки, к сожалению. В принципе, это требование справедливо для любых сайтов, но в случае с App Engine оптимизация необходима вдвойне!.. Конечно, это очень сильно зависит от вида проекта. Если интерактивности на сайте немного, то ситуацию со скоростью работы спасет кеширование на самом верхнем уровне (отдача сгенерированного html). Однако далеко не всегда проблему производительности можно решить так просто.
P.S. Мы разместили на Хабре копию вот этой заметки Евгения Демченко, так как думаем, что она может быть интересна не только читателям GoogleApps.ru.
Слабые стороны:
1. Ограничение CPU_ms на запрос и на страницу
Если при каждом запросе делать много вычислений на сервере, то страница быстро израсходует свой лимит и станет недоступной.
2. Ограничение на общее количество запросов в день
В день разрешено около миллиона запросов к сервису, включая запросы к картинкам и другим ресурсам. При больших нагрузках достичь этого числа очень легко. Главная трудность состоит в том, что этот ресурс нельзя купить! Даже при включенном биллинге такие запросы не будут учитываться как платные, и при достижении все того же миллиона приложение перестанет работать. Чтобы избежать этого, нам пришлось переносить файлы для баннеров на сервис хранения файлов Amazon S3.
3. Ограничение на количество запросов в секунду
При интенсивности более 500 запросов в секунду приложение перестает работать. В обычных ситуациях достичь столь высокой нагрузки непросто. В случае с гаджетом Евровидения это получилось из-за рекламных баннеров. Такая проблема может появиться, если страница с вашим сервисом рекламируется на популярных сетевых ресурсах — главной странице Yahoo!, Slashdot или Digg.
Tips & Tricks:
1. Кешируем ВСЁ!
Все, что отдается на запросы пользователей, должно браться напрямую из memcache. Чтобы полностью избежать проблем, лучше создавать cron’ы, которые будут обновлять кеш по расписанию. Тогда даже редкие запросы пользователей не будут требовать обращения к базе данных и производить дополнительные вычисления. Так мы закрываем слабую сторону номер 1.
2. По максимум переносим статический контент на внешние сервера.
Все картинки, CSS, Javascript лучше залить на Google Code и отдавать пользователям непосредственно с него. От нашего приложения пользователи будут получать только закешированный html, а все остальное запросы уже не будут нагружать его. Этим мы закрываем вторую и третью слабую сторону.
3. Включаем биллинг, даже если он не нужен.
Как уже было сказано, бесплатных лимитов App Engine хватает, если приложение хорошо оптимизировать. Для гаджета Евровидения при нагрузке до 300 запросов в секунду за все время было снято 5 центов. Да и то лишь в день финала, когда, понятное дело, интерес пользователей подскочил.
Главный же плюс биллинга (его включение разрешает App Engine взимать деньги за перерасход лимитов) состоит в том, что бесплатные ресурсы все равно остаются. А вот ресурсы, за которые нельзя платить, увеличат свои лимиты в 50 раз! Я совершенно случайно заметил, что после включения биллинга для гаджета Евровидения лимит на количество запросов в день вырос с миллиона до 50 миллионов :)
4. Не храним пользовательские данные в приложении.
Если сохранять пользовательские настройки и профили в БД, то при больших нагрузках придется обновлять кеш слишком активно, поскольку пользователи будут очень часто сохранять свои данные в БД. Ясно, что социальную сеть таким образом не построить.
Для полноценной работы с пользователями и их данными необходимо использовать Google Friend Connect. Он очень просто подключается к любому сайту, дает полноценную авторизацию через Google Account, Yahoo! или OpenID. После этого все пользовательские данные хранятся непосредственно на серверах Google и не затрагивают наше приложение в части, касающейся социальных сетей (френдование, комментарии, рейтинги и т.д.). Вообще, FriendConnect – потрясающий сервис, который позволяет с легкостью подключать мощные социальные функции практически к любому сайту. Из минусов – дает дополнительную нагрузку на браузер (в связи с использованием JavaScipt) и слегка увеличивает трафик при начальной загрузке. Впрочем, в дальнейшем все скрипты кешируются.
Резюме:
На App Engine можно сделать практически что угодно, если уметь ее готовить :)
При этом даже для нагруженного сайта довольно сложно превзойти бесплатные лимиты (если правильно работать с ним), и даже при их превышении плата невысока. Это гораздо выгоднее, чем использовать аналогичные сервисы от Amazon, где за каждый день использования необходимо платить.
Любое приложение нужно достаточно жестоко оптимизировать, что увеличивает время разработки, к сожалению. В принципе, это требование справедливо для любых сайтов, но в случае с App Engine оптимизация необходима вдвойне!.. Конечно, это очень сильно зависит от вида проекта. Если интерактивности на сайте немного, то ситуацию со скоростью работы спасет кеширование на самом верхнем уровне (отдача сгенерированного html). Однако далеко не всегда проблему производительности можно решить так просто.
P.S. Мы разместили на Хабре копию вот этой заметки Евгения Демченко, так как думаем, что она может быть интересна не только читателям GoogleApps.ru.
