2012-04-29 2 views
6

Я улучшил свой код, и теперь весь API работает очень быстро, я также добавил memcache, и у меня отличное соотношение. Но иногда я получаю бессмысленные задержки.Google App Engine странная задержка

Я приложил сюда самый значительный скриншот appstats: более 20 секунд для запуска 90 мс RPC; как это возможно? Где я должен искать источник этих задержек?

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

Просто мысль: каждый HTTP-вызов обрабатывается одним и тем же экземпляром GAE, правильно? Потому что мои экземпляры занимали много времени для разминки. Но я не думаю, что это связано.

BTW: Я кодирую на Java.

appstats statistics

ответ

2

Обычно неучтенный «дыра» в середине appstats - это ваш код.
Appstats записывает каждую запись и выходы rpc, а области, которые он не может записать, - это ваш текущий код.

У вас есть журналы на время, в течение которого приложение находилось между этими двумя вызовами?

+0

спасибо shay .. да, я записываю много вещей с помощью log.fine (..), поэтому я должен просто включить уровень, а затем снова посмотрите. –

+0

Я не убежден, что 100% - это то, что HTTP-вызов обрабатывается разными экземплярами. Является ли это возможным? Потому что это может быть другой проблемой, из-за длительного времени, затраченного на разогревание нового экземпляра! –

+0

@MicheleOrsi вы не можете перетащить экземпляр во время выполнения обработчика –

2

Огромный, «необъяснимые» задержка почти всегда разминочных запросы уплетая ресурсы. Осмотрите свои журналы приложений, чтобы узнать, сколько api_ms и cpu_ms используются для разминки.

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

Чтобы помочь с запросами разминочных, убедитесь, что ваш AppEngine-web.xml имеет:

<warmup-requests-enabled>true</warmup-requests-enabled> 

Это приведет к Appengine диспетчеру превентивно запустить новые случаи, когда текущие из них перегружен {т.е. он начинает загрузку до того, как запрос перейдет в новый экземпляр}.

затем, в пострадавших медленных сервлетов, убедитесь, что вы положили груз-на-старте в вашем web.xml:

<servlet> 
    <servlet-name>my-servlet</servlet-name> 
    <servlet-class>com.company.MyServlet</servlet-class> 
    <load-on-startup>1</load-on-startup> 
</servlet> 

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

+0

Благодарим вас, но я уже делаю все ваши предложения: включен режим «разогрев», «нагрузка-на-запуск» и «Ожидающая задержка» установлены на 11,5 с - автоматически. –

+0

Можете ли вы снова запустить свой тест и посмотреть, как многие случаи запущены? Убедитесь, что вы загружаете запросы в журналы и сколько из них. Кроме того, вы стреляете во все ваши rpcs одновременно? Если в вашем браузере открыто более двух подключений, он заблокирует ожидающие, что может привести к блокировке ваших сервлетов. Наблюдайте за запросами в firebug, чтобы узнать, можете ли вы выбрать, какие запросы подталкивают вас к 20 секундам по 90 мс запросов. – Ajax

+0

Кроме того, ожидаемая латентность 11,5 секунд означает, что каждое соединение может иметь задержку в 10 с. Измерить ваши запросы на загрузку. Если один запрос на загрузку составляет 15 секунд, а максимальная ожидаемая латентность - 11 секунд, ваш первый запрос на загрузку будет ждать 10 секунд, а затем займет еще 15 секунд, чтобы запустить новый экземпляр.Возможно, вы захотите включить ожидающую задержку и просто укусить пулю в запросах на загрузку. – Ajax