Профилирование медленной настройки Zend Framework MVC

Question

Я борюсь с низкой производительностью в Zend MVC.

Я установил один контроллер, который выполняет только die(), и включил xdebug, и поднял webgrind по моей просьбе, которая говорит мне:

789 different functions called in 2150 milliseconds (1 runs, 137 shown)

У меня проблемы с точным определением того, что занимает так много времени:

[procedural]      {main}    O   1   9   2150
[class]       Zend_Application_Bootstrap_BootstrapAbstract->_bootstrap  O   5   7   1203
[class]       Zend_Config_Ini->_processKey  O   622     451     1191
[class]       Zend_Config_Ini->_processSection  O   2   49  1023
[class]       Zend_Application_Bootstrap_BootstrapAbstract->_executeResource    O   16  11  1017

(Вышесказанное в значительной степени говорит мне, что это классы загрузки, определенные в моем application.ini -Я понятия не имею, какие из них медленные)

Какой хороший способ точно определить, какой именно шаг в коде занимает большую часть времени обработки?

Answer 1

Вы должны иметь возможность расширить вывод webgrind, чтобы определить, что является вашим более медленным вызовом функции. В качестве альтернативы вы можете использовать функцию трассировки функции из Xdebug во время сеанса профилирования, чтобы получить больше информации о вызовах функций.

Вообще говоря, вы должны использовать кэш везде, где это возможно. Memcache работает быстрее, чем APC, в качестве Zend_Cache бэкэнда, но вам все еще нужно установить расширение APC (даже в режиме разработки), чтобы значительно ускорить ваш код. Я оценил его влияние на Zend Framework Quick Start в моем блоге (это сообщение на итальянском языке, но данные тестов на английском языке), и результат довольно впечатляющий, 3-кратное ускорение для домашней страницы.

Я применил идею кеширования также для файла конфигурации Zend_Application (который в вашем примере занимает половину времени профилирования). Я обсуждал это здесь с Мэтью Вейером О'Финни, руководителем проекта Zend Framework. Что я сделал, так это переопределил метод по умолчанию Zend_Application _loadConfig с помощью пользовательского метода, который кэширует результат проанализированного файла. Вы можете найти мой класс, который реализует эту стратегию здесь, на github .

Answer 2

После удаления require_once библиотеки, как описано в официальном руководстве по производительности, вы должны установить кэш кода операции, такой как Zend Server CE, APC или eAccelerator, даже на вашем компьютере разработчика.

Кроме того, для некоторых плагинов ресурсов, которые вы можете настроить в application.ini, может потребоваться кэширование данных, чтобы обеспечить хорошую работу, например, Zend_Db, Zend_Loader и т. Д. (Я не буду объяснять разницу с кэшированием кода операции здесь)

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

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

И тогда вы можете начать беспокоиться о своих "реальных" узких местах.

Хорошо, это было о производительности начальной загрузки ZF,Но ваш вопрос был о профилировании кода.Я использую несвободные инструменты для этого, но Xdebug в сочетании с Kcachegrind тоже неплохо справляется: http://xdebug.org/docs/profiler