Подтвердить что ты не робот

Как уменьшить задержку хранилища данных Google App Engine?

Через appstats я вижу, что мои запросы к хранилищу данных занимают около 125 мс (вместе с api и cpu), но часто перед выполнением запросов часто возникают длительные задержки (например, до 12000 мс).

Я вижу, что моя задержка из хранилища данных не связана с моим запросом (например, один и тот же запрос/данные имеют значительно разные задержки), поэтому я предполагаю, что это проблема планирования с движком приложения.

Другие люди видят эту проблему?

Есть ли способ уменьшить задержку (например, настройки консоли администратора)?

Вот скриншот из appstats. У этого сервлета очень мало обработки процессора. Он выполняет getObjectByID, а затем выполняет запрос хранилища данных. Запрос имеет оператор OR, поэтому он преобразуется в 3 запроса с помощью механизма приложения.

appstats screenshot , Как вы можете видеть, он занимает 6000 мс до того, как будет запущен первый getObjectByID. Перед операцией get нет обработки (кроме получения pm). Я думал, что эта задержка в 6000 мс может быть вызвана разминкой экземпляра, поэтому я увеличил количество незанятых экземпляров до 2, чтобы предотвратить разминки.

Затем возникает вторая латентность вокруг 1000 мс между getObjectByID и запросом. Там нулевые строки кода между get и запросом. Код просто берет результат getObjectByID и использует данные как часть запроса.

Общая сумма составляет 8097 мс, но мои операции с хранилищем данных (и 99,99% сервлета) составляют всего 514 мс (45 мс api), хотя числа меняются каждый раз, когда я запускаю сервлет. Вот еще один скриншот appstats, который был запущен на том же сервлете, что и те же данные. enter image description here

Вот основы моего кода Java. Мне пришлось удалить некоторые детали в целях безопасности.

user = pm.getObjectById(User.class, userKey);           
//build queryBuilder.append(...
final Query query = pm.newQuery(UserAccount.class,queryBuilder.toString());
query.setOrdering("rating descending");
query.executeWithArray(args); 

Отредактировано: Используя Pingdom, я вижу, что задержка GAE варьируется от 450 мс до 7,399 мс, или от 1,644%! Это с двумя незанятыми экземплярами и без пользователей на сайте. enter image description here

4b9b3361

Ответ 1

В некоторых моих приложениях наблюдались очень похожие задержки (в диапазоне 7000-10000мс). Я не думаю, что основная часть проблемы (эти 6000 мс) лежит в вашем коде.

В моих наблюдениях проблема связана с тем, что AppEngine запускает новый экземпляр. Установка минимальных экземпляров бездействия может помочь уменьшить, но он не решит его (я пробовал до двух экземпляров бездействия), потому что в основном, даже если у вас есть N случайных экземпляров, движок приложения предпочитает создавать динамические, даже если приходит один запрос и будет "экономить" простаивающие в случае сумасшедших трафик. Это очень противоречиво, потому что вы ожидаете, что он будет использовать экземпляр, который уже существует, и подгонять динамические для будущих запросов.

В любом случае, по моему опыту, эта проблема (задержка в 10000 мс) очень редко происходит при любом ненулевом количестве нагрузки, и многие люди должны были вернуться к королю pinging (возможно, заданий cron) каждые пару минут (используется для работы с 5 минутами, но в последнее время экземпляры умирают быстрее, так что это больше похоже на ping каждые 2 минуты), чтобы поддерживать динамические экземпляры вокруг пользователей, которые попали на сайт, когда никто больше не включен. Это пинг не является идеальным, потому что он будет съедать вашу свободную квоту (пинг каждые 5 минут съедает больше половины ее), но я пока не нашел лучшей альтернативы.

В резюме, в общем, я обнаружил, что приложение движок является удивительным при загрузке, но не выдающимся, когда у вас только очень мало (1-3) пользователей на сайте.

Ответ 2

Appstats помогает только диагностировать проблемы с производительностью при вызове GAE API/RPC.

В случае вашей диаграммы "пустое" время тратится на выполнение вашего кода на вашем экземпляре. Это не будет время планирования.

Ваше предположение, что начальная задержка может быть вызвана разминкой экземпляра, весьма вероятна. Это может быть код рамки, который выполняется. Я не могу догадаться о задержке между Get и Query. Может быть, есть 0 строк кода, но вы вызвали некоторую функцию в запросе, которая требует времени для обработки.

Без знания языка, рамки или фактического кода никто не сможет вам помочь.

Чтобы диагностировать это, вам нужно будет добавить какую-то трассировку производительности. Самый простой (но не очень точный) способ сделать это - добавить таймеры и значения таймера журнала по мере выполнения кода.