согласование разницы между AppStats Grand Total и Apache Bench

Я использую appstats для проверки некоторых вызовов. У меня есть простое представление, которое вызывает memcache и возвращает результат. Appstats сообщает мне, что общее время (общий итог) составляет около 15 мс. Однако то, что я наблюдаю в браузере, больше похоже на 242 мс или около того. И на самом деле, я также получаю тот же результат, используя apache Bench. Я попробовал другую сеть (используя экземпляр ec2), чтобы увидеть, увижу ли я другое время прохождения туда и обратно, и также получил примерно такой же результат. Пинг до сервера занимает около 13 или 14 мс.

Я определенно что-то здесь упускаю. Задержка около 180-200 мс, которую я не могу объяснить. Основываясь на опыте работы с движком приложения и статистикой приложений, я надеюсь, что кто-то поможет мне открыть глаза на то, что мне не хватает.

Некоторые подробности среды, если интересно... python 2.7; использовал в тестах и ​​webapp2, и Flask; все мои стендовые тесты Apache были однопоточными, срабатывающими 100 раз.

Спасибо за любое понимание.


google-app-engine appstats
person Jay    schedule 23.10.2012    source источник

Ответы (1)


arrow_upward
1
arrow_downward

По моему опыту, вы всегда будете видеть разницу между статистикой приложений и общим временем. Это можно увидеть в логах. Где указана общая задержка. Appstats дает вам время, которое потребовалось вашему коду для обработки запроса, но в журналах указано общее время ввода-вывода. Из того, что я могу потренировать, увеличение времени связано с балансировкой нагрузки и тем, как движок приложения внутренне ставит запросы в очередь и оценивает, нужно ли его масштабировать или нет. Кроме того, если вы отправляете пакет из 100 запросов, вы можете сделать разницу более заметной, потому что в зависимости от настроек вашего приложения он, скорее всего, будет обслуживать эти запросы на минимальных экземплярах до запуска нового экземпляра.

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

Был бы заинтересован в официальной версии, но мне так кажется после 3 лет работы с движком приложения.

person Justin Grayston    schedule 24.10.2012
comment
Я думаю, ты прав, Джастин. Меня приводит в замешательство количество задержки. Чтобы проверить это дальше, я развернул простое приложение hello world. App Engine обслуживал это около 63 мс. То же самое приложение (по сути), развернутое на героку, работало со скоростью 18 мс. Конечно, приложение heroku очень похоже на один экземпляр ec2, который сидит там — без автоматического масштабирования. Тестирование сейчас, в другое время суток, и экземпляр ядра приложения отвечает через 130 мс. Это ноль вызовов rpc. Таким образом, задержка меняется в зависимости от того, что происходит. Я хотел бы, чтобы это было меньше, но эй. - person Jay; 24.10.2012
comment
Да, на странице состояния appengine вы можете увидеть переменную задержку, и я также видел дни, когда обработка запросов занимала в два раза больше времени. Вот где на помощь приходят ползунки настроек приложения для ожидаемой задержки. - person Justin Grayston; 24.10.2012