Успешное обновление производительности веб-приложения, но не знаю почему.Как узнать?

Question

это странное название, поэтому позвольте мне объяснить:

У нас есть веб-приложение (PHP, Zend Framework), которое довольно успешно. Со временем трафик рос и производительность снижалась (десятки запросов с запросами от 80 до десятков тысяч со средним> 600 мс). Мы не ожидали такого большого количества трафика при первой разработке приложения, так что нет ничего удивительного. Мы решили изучить многие вещи, которые могли бы улучшить производительность.

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

Но да, это было на производстве. Наши графики упали почти до нуля, и мы были полностью уничтожены, что обновление каким-то образом заставило весь трафик исчезнуть. Но когда мы посмотрели поближе, графики вернулись к 80 мсам и почти не были видны рядом с горами 600 мс;)

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

Как бы вы решили эту проблему?

Некоторый фон:

• PHP-приложение, использующее Zend Framework, MySQL в качестве базы данных, Memcache для кэширования.
• Мы получаем наши графики производительности и информацию о приложении от NewRelic.com, но я не могу найти причину повышения производительности там.
• Используя jMeter, мы можем воспроизвести плохую производительность на наших серверах разработчиков, а также более или менее лучшую производительность обновленной версии.

Единственная идея, которая у меня есть сейчас, - это начать со старой версии, загрузить ее, добавить один коммит, загрузить тест, добавить другую функцию, загрузить ее ... но это не звучит забавно или очень эффективно. 1023 *

---

Обновление: Мы нашли причину проблем с производительностью, позже я добавлю ответ, чтобы объяснить, что мы сделали и в чем причина. (Или как к таким вопросам относятся обновления и решения?)

---

Обновление 2: Добавит решение и способ найти его как ответ.

Answer 1

Так в чем была проблема? Два дополнительных 'в запросе MySQL. Числовое значение, входящее в метод, случайно было строкой, поэтому ORM использовался вокруг него. Обычно эти проблемы обнаруживаются оптимизатором, но в данном случае это была довольно сложная комбинация JOIN, возможно, поэтому она была пропущена. Поскольку это был также наиболее часто используемый запрос, каждое его выполнение было чуть-чуть медленнее, но в конечном итоге это имело все значение.

Answer 2

В идеале вам нужно профилировать старую версию приложения и новую версию приложения с теми же реалистичными данными, но я почему-то сомневаюсь, что у вас будет время или желание сделать это.

Что вы можете сделать, так это начать со сравнения эффективности запросов к БД, которые вы переписали, с предыдущими версиями, а также посмотреть, как часто они вызываются и т. Д., И какое влияние на это оказывает введенное вами кэширование.

Я бы также изменил процесс в будущем, чтобы вы представили изменения как поток (непрерывная интеграция / стиль развертывания), чтобы вы могли более четко видеть влияние отдельных изменений.

Answer 3

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

Запуск его через профилировщик покажет вам разбивку потока выполнения и всех вызванных методов, сколько времени они заняли и сколько памяти вы использовали. Профилировщик должен показать, вызывается ли какой-то блок кода много раз, или есть что-то, что иногда просто занимает много времени.

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

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

Я использую Zend Studio для профилирования, и это позволяет значительно сэкономить время. Профилировщик XDebug очень похож на AFIK.

Docs:
http://files.zend.com/help/Zend-Studio/profiling.htm
http://xdebug.org/docs/profiler

Answer 4

Если вы просто не можете больше оптимизировать и локально масштабировать, посмотрите здесь:

http://www.zend.com/en/products/php-cloud/