Google App экземпляр рециклинг приложения двигателя и время отклика

Question

Я отправил это на GAE для группы Java, но я надеюсь получить ответы на некоторые вопросы здесь быстрее :)

я решил сделать некоторые давно запустить тесты производительности в моем приложении. I создал небольшое приложение для работы с клиентом каждые 5-30 минут, и я запускаю 3-5 потоков с таким клиентом.

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

Uneven response time between connection to server to first byte sent

Application instances seem to be too aggressively recycled

Getting 'Request was aborted after waiting too long to attempt to service your request.' after application idle

Я использую Springframework, он TKES вокруг 18-20s начать приложение экземпляр, который вызывая время отклика от 1 с (когда запрашивает хиты, выполняемые приложением - очень редко) до 22 секунд, когда создано новое приложение .

Есть ли решение для этого? Я думал о создании самого базового сервлета, выполняющего критические задачи (вызов обслуживающего API) и оставляющий пользовательский интерфейс как есть. Но тогда я потеряю все преимущества Springframework.

Есть ли решение для этого?

После решения (взлом) многочисленных ограничений типа App Engine, который я ударил при разработке моего приложения, которое является один я думаю, что заставит меня выйти из App Engine ... это просто многие все время думать, как до выиграть с проблемами GAE, чем решить мои проблемы с приложением ...

Любая помощь?

С уважением Konrad

Answer 1

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

Это быстрый способ реализовать, но, похоже, идет вразрез с духом платформы. Сделайте свои номера и проверьте, стоит ли это.

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

Я не знаю, если у вас есть какой-либо другой вариант, кроме этого 2.

Answer 2

Это, безусловно, сложный вопрос с AppEngine приложениями. Пуристы расскажут вам, почему ваше приложение занимает так много времени, чтобы начать работу и отступить оттуда. В вашем случае ответ очевиден: вы используете Spring, и ему приходится загружать многие файлы классов и создавать множество объектов.

Прагматичный ответ, если вы можете жить без весны, заключается в том, чтобы убедиться, что экземпляр приложения остается теплым.Вы можете либо пинговать его из внешнего источника достаточно часто, чтобы AppEngine никогда не выгружал его, или вы могли бы использовать задание cron AppEngine, которое выполняется достаточно часто, чтобы поддерживать ваше приложение в памяти.

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

Вот related discussion

Answer 3

Используйте новую функцию precompilation.

<!-- appengine-web.xml --> 

<precompilation-enabled>true</precompilation-enabled> 

Answer 4

Что было бы хорошо, если мы могли бы сериализации DispatcherServlet в кэше, а затем десериализации его из кэша памяти на холодном старте, если она есть. Тогда создание Spring было бы очень коротким.

DispatcherServlet уже отмечен как Serializable, нам просто нужно найти способ сериализации WebApplicationContext объекта, что DispatcherServlet содержит.

Answer 5

в случае люди живут в AE-земле и хотят быстро и грязный Keep-Alive Pinger, это работает как шарм (окна):

http://www.coretechnologies.com/products/http-ping/

Answer 6

SDK 1.4.0 имеет эту новую функцию:

• Теперь разработчики могут активировать запросы на Warmup. Указав обработчик в appengine-web.xml приложения, приложение Двигатель попытается отправить запрос на подогрев , чтобы инициализировать новые экземпляры до того, как пользователь взаимодействует с . Это может уменьшить задержку, которую видит конечный пользователь для инициализации вашего приложения .