Я наблюдаю резкие спады и всплески количества экземпляров каждые 30 минут, хотя частота запросов была стабильной в течение 2 часов при 2,4 тыс. Запросов в секунду. Периодически после того, как многие экземпляры выключаются одновременно, возникает множество запросов на прогрев. Это также увеличивает наши эксплуатационные расходы из-за большого количества простаивающих экземпляров.
Параметры производительности приложения по-прежнему установлены по умолчанию (экземпляры F1, минимальная / максимальная задержка ожидания и минимальные / максимальные бездействующие экземпляры по-прежнему находятся в автоматическом режиме).
Вскоре я повторно проведу тот же тест на экземплярах F2. В это время:
количество экземпляров [F1] RPS [F1] общее использование памяти в МБ [F1]
Обновление после запуска теста на экземплярах F2
В течение первых 2 часов тестирования отток экземпляров был значительно сокращен. Количество экземпляров было значительно более стабильным. За последние 2 часа теста количество экземпляров увеличилось с 250 до 600, хотя скорость запросов оставалась стабильной на уровне 2,4 тыс. Запросов в секунду.
количество экземпляров [F1 vs F2] RPS [F1 против F2] общее использование памяти в МБ [F1 vs F2] миллисекунд на запрос [F1 vs F2]
Эта информация частично получена из разговоров с Google и из моего собственного опыта, я не сотрудник Google.
Я обнаружил, что требования к памяти внешнего интерфейса Google являются нечеткими целями и, как правило, не жесткими ограничениями, которые вызывают постоянные сборщики мусора для большинства пользователей, поскольку большинство приложений, вероятно, превысят их. Я считаю, что их фактический предел составляет около 170 МБ, прежде чем экземпляр обычно рискует незаметно завершить работу (я заметил, что время от времени может достигать около 200 МБ, поэтому я предполагаю, что у них есть периодический поток фонового экземпляра, который выполняет эту работу - это гипотетически У меня нет доказательств того, что это делается). Если у экземпляра, похоже, не хватает памяти, а сервер у меня был, я знаю, что подумал бы об убийстве процесса.
Я бы проверил, сколько памяти на самом деле использует большинство ваших экземпляров, поскольку это может быть причиной массового уничтожения экземпляров.
При использовании F2 ваш сервер может запускаться и обрабатывать запросы в два раза быстрее, чем F1, что приводит к меньшему количеству экземпляров и из-за более высокого потолка памяти меньше шансов быть убитым (опять же, мое мнение, которое, похоже, совпадает с моим опытом запуска ряда приложения корпоративного класса).
Также обратите внимание, что Google в настоящее время развертывает (или тестирует RC? !!) обновление для своих серверов с GAE 1.8.1 до 1.8.2, и это может повлиять на такие приложения, как наше, и это причина, по которой я нашел ваш пост, мы мы наблюдаем случайный кэш памяти и задержку ответа 5-20 секунд, возвращающую полностью кэшированные ответы внешнего интерфейса, что обычно выполняется за <10 миллисекунд (<80 мс с задержкой в сети). Во время этого развертывания не забывайте, что каждая запущенная виртуальная машина / машина также должны будут выполнять обновления, а также обслуживать другие приложения.
Если это будет продолжаться более нескольких часов, мы будем собирать доказательства и требовать возмещения затрат - я предлагаю другим сделать то же самое, помните ... Google гордится надежностью системы это главный приоритет.