Pull to refresh

Comments 26

Статья конечно интересная, но не пробовал ли Александр публиковать ее в Песочницу?
Ждём появления Александра на Хабре с более подробными статьями. Инвайта к сожалению нету.
Я так понимаю эти ограничения действительны только для бесплатного апп енджина? Или для платного тоже?
Задайте себе вопрос: а есть ли разница между платным и бесплатным, кроме накладываемых ограничений не количество запросов, объёмов БД и др.?
Да, как-то криво я задал вопрос. Был сонный :)
Между платным и бесплатным app engine разница только количественная (да и то не всегда), а принципиальной разницы нет.
Квоты в минуту у платного повыше, ну и не относящийся к статье Blobstore недоступен пока оплата не включена.

В целом же, в описании квот довольно ясно описаны ограничения, и путём нехитрых вычислений можно прикинуть, что 500 запросов в секунду могут быть обработаны при среднем времени CPU на запрос, составляющем 0,144с для платной версии, что довольно далеко от заявленной секунды.

В бесплатном варианте число запросов ограничено 123-мя в секунду и для его достижения среднее время запроса должно составлять 0,121с.
Спасибо. Я плохо задал вопрос, а получил хороший ответ )
От Александра: Под заголовком «одна секунда» речь идет о фактическом времени выполнения запроса, а не о затраченном процессорном времени. Как и многие вы введены в заблуждение русской версией документации, которая неактуальна. Одновременно с выходом SDK 1.3.3 поменялась система учета параллельных динамических запросов: code.google.com/intl/en/appengine/docs/java/runtime.html#Quotas_and_Limits

Приложение может обслуживать 500 (и даже больше) запросов при среднем фактическом времени выполнения каждого запроса не более секунды. Сколько при этом процессорного времени будет затрачено — роли не играет.
В английской версии те же самые 15 и 72 минуты CPU в минуту, поэтому русская версия была приведена в пример как актуальная, но более удобочитаемая. В приведённой Вами ссылке речь о том, что долгие запросы имеют меньший приоритет в самой системе, что может сказать на поведении приложения при большой нагрузке на соседние.

И если длинный запрос довольно просто разбить на несколько коротких с помощью task queue (да и Dashboard красноречиво сигналит обо всех долгих запросах), то под ожидаемую нагрузку в 500 запросов надо серьёзно оптимизировать код. И, на мой взгляд, достижение квот придёт быстрее — на многих запросах время CPU может превышать время запроса.
Я вас неправильно понял, вы говорите о квотах CPU в минуту. К счастью, их больше нет. Об этом Nick Johnson (из команды App Engine в Google) писал не раз, например, вот тут. А документация опять отстает.
От Александра: Для обоих. В статье приведены цифры для приложений с включенным биллингом.
В статье не хватает: 1. ссылок на документацию, где о фактах, изложеных в статье, можно почитать подробнее; 2. картинок, демонстрирующих control flow; 3. примеров кода.
От Александра: С ссылками на документацию, увы, есть проблемы. Система развивается, выходят новые версии SDK, но документация имеет всего одну версию, которая по-тихому (без каких-либо анонсов) меняется. Например, одновременно с выходом GAE SDK 1.3.3 была изменена система
масштабирования приложений (1 секунда на обработку запроса). В Change Log об этом не было сказано ни слова, так же как и о том, что изменения кратко изложены в документации.

Кроме того, часто информация в документации размазана и неполна — знания буквально приходится собирать по крупинкам, регулярно выходя далеко за её рамки. Что-то узнаешь через google groups, что-то приходится проверять с помощью кода. В основном статься собрана как раз из таких знаний. Собрана без картинок и примеров кода. Ну что ж. Учту на будущее.
UFO just landed and posted this here
Принимайте лекарства от расстройства пищеварения.
Слишком часто в статье встречается слово «ошибка», «Exception», слишком много «но». Хотелось бы реальных примеров от уважаемого Александра.

Напишите в личку если нужен инвайт для него.
Что-то меня смущает фраза «Для объектов, являющихся частью одной группы, поддерживается не более 10 операций записи в секунду». Вопрос — в группу объединяются объекты или классы? Как работает механизм объединения в группы? Автоматически?

И поподробнее про sharding в контексте GAE, если есть возможность.
Большое спасибо за ссылку
От Александра: В группы объединяются именно объекты. Обычно они объединяются автоматически, когда между ними появляется отношение зависимости (owned relationship). Про отношения очень хорошо написано в документации: code.google.com/appengine/docs/java/datastore/relationships.html
Спасибо за ссылки. Получил свой ответ, прочитав статью по ссылке выше. Получается что для того, чтобы увеличить количество операций записи можно использовать sharding, memcache или и то и другое. Но при их использовании сильно разрастается код (раз в 10 судя по примеру «sharding counters»). Хочется какой-нибудь стандартной библиотеки, которая помогла бы прикрутить sharding в виде «аспекта» (без влезания кода DAO в бизнес-объекты).
В принципе, оптимальное решение — зеркало хранилища данных в memcache, при котором само приложение работает с данными в memcache, а актуальность базы поддерживается работающим отдельно демоном. Правда, у этого решения есть ещё ряд недостатков: task queue ещё в стадии обкатки (практически не проблема), во время техобслуживания memcache не работает и приложение резко начнёт потреблять в разы больше ресурсов (правда, в эти страшные моменты подобные проблемы будут практически у всех приложений), и в виде универсальной библиотеки сделать это проблематично — всё равно придётся допиливать под конкретные модели данных
это parent модели. например- если комментарий будет иметь родителем «пост», то в одной транзакции можно будет и коммент добавить и, например, обновить счетчик комментариев у поста (денормализация)

Sign up to leave a comment.

Articles