Управление экземплярами Java в Google App Engine с довольно большой нагрузкой, чтобы избежать 500 ошибок

У нас есть Java-приложение Google App Engine с 50–120 запросами в секунду в зависимости от часа дня.

Наш интерфейс appengine-web.xml выглядит так:

<instance-class>F1</instance-class>
<automatic-scaling>
    <min-idle-instances>3</min-idle-instances>
    <max-idle-instances>3</max-idle-instances>
    <min-pending-latency>300ms</min-pending-latency>
    <max-pending-latency>1.0s</max-pending-latency>
    <max-concurrent-requests>100</max-concurrent-requests>
</automatic-scaling>

Обычно одному экземпляру внешнего интерфейса удается обработать около 20 запросов / с. Время запуска составляет около 15 с.

У меня есть несколько вопросов :

  • Когда я меняю версию интерфейса по умолчанию, я получаю тысячи ошибок 500 - Запрос был прерван после слишком долгого ожидания попытки обслуживания вашего запроса. Чтобы этого избежать, я переключаюсь с одной версии на другую. Используя функцию разделения трафика по IP-адресу, от 1 до 100% с шагом 5%, требуется около 5 минут, чтобы сделать это правильно и избежать 500 массовых ошибок. Более того, эта функция кажется доступной только для модуля внешнего интерфейса по умолчанию.

-> Есть ли лучший способ переключать версии?

  • Чтобы избежать тысяч ошибок 500 - Запрос был прерван после слишком долгого ожидания попытки обслуживания вашего запроса. Мы должны использовать как минимум 3 резидентных (минимальных) экземпляра. И по мере того, как наш трафик растет, даже с 3-мя, мы иногда все равно получаем огромную ошибку 500. Я должен идти к 4-м жителям? Я думал, что App Engine - это хорошо, потому что вы платите только за используемые экземпляры, поэтому, если для правильной работы нам понадобится хотя бы половина наших запущенных экземпляров в режиме ожидания, это же не здорово, не так ли? Это не совсем рентабельно, так как при низкой нагрузке 4 простаивающих экземпляра - большая трата :( Странно то, что они, кажется, ждут всего 10 секунд, прежде чем ответить 500: pending_ms = 10248

-> Есть ли у вас советы, чтобы этого избежать?

  • Довольно часто мы также получаем тысячи ошибок 500 - Возникла проблема с процессом, обработавшим этот запрос, что привело к его завершению. Это может привести к использованию нового процесса для следующего запроса к вашему приложению. Если вы часто видите это сообщение, возможно, во время инициализации вашего приложения возникают исключения. (Код ошибки 104). Я не понимаю, никаких исключений нет, и мы получаем их сотни за несколько секунд.

-> Есть ли у вас советы, чтобы этого избежать?

Заранее большое спасибо за вашу помощь! ;)


java google-app-engine instances
person Etienne    schedule 10.01.2014    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Эти сообщения об ошибках в основном связаны с запросами на загрузку, которые длятся слишком долго при загрузке и поэтому заканчиваются чем-то похожим на DeadlineExceededException, что, как вы, вероятно, уже знаете, существенно влияет на производительность и удобство работы пользователей.

Это очень частая проблема, особенно при использовании фреймворков DI с движком приложений Google, и до сих пор это неизбежная и серьезная нерешенная проблема при использовании автоматическое масштабирование, которое представляет собой политику масштабирования, которую App Engine предоставляет для обработки общедоступных запросов с момента своего создания.

Попробуйте изменить класс экземпляра Frontend на F2, особенно если потребление памяти превышает 128 МБ на экземпляр, и установите минимальную и максимальную задержку ожидания 15 с, чтобы ваши запросы получали больше шансов быть обработанным резидентным экземпляром. Тем не менее, время отклика на некоторые запросы будет продолжительным, поскольку Google App Engine может не выдавать запрос на прогрев каждый раз, когда вашему приложению требуется новый экземпляр, и я не понимаю, что F4 обанкротит вас.

person Joar    schedule 05.02.2014
comment
Фактически, я оптимизировал код с помощью профилирования. Мне удалось в основном улучшить 2 вещи, которые были большими узкими местами. Во-первых, я избавился от фреймворка java jackson для анализа JSON (80%) и улучшил управление memCache (20%). Теперь экземпляр F1 может обрабатывать до 80-90 запросов / с. Я не использую никаких фреймворков DI. Я пробовал инстансы F2, но это было не лучше (и стоило мне вдвое ^^). На данный момент с улучшенной производительностью мое число 500 действительно упало, и мне стало легче переключаться на версию. - person Etienne; 05.02.2014
comment
Теперь я могу использовать только 2 резидентных экземпляра (думаю, одного будет достаточно). Кроме того, у меня теперь только 50 одновременных запросов, поэтому, когда экземпляр умирает, будет выброшено менее 500, и у меня все равно будет та же производительность экземпляра. Мне не нравится ставить 15 с для минимальной и максимальной ожидаемой задержки, поскольку я хочу максимально снизить задержку для конечных пользователей. Мое потребление памяти обычно составляет 180-200mo на консоли движка приложения, но оно отлично работает с экземплярами F1. У меня нет исключений OutOfMemoryException - person Etienne; 05.02.2014