Question

I am struggling with poor performance in Zend MVC.

I set up a single controller, which only does die(), and I enabled xdebug, and pulled up webgrind on my request which tells me:

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

I am having problems determining exactly what is taking so long:

[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

(The above pretty much tells me it’s the bootstrap firing up classes defined in my application.ini – but I have no idea which ones are slow)

What’s a good way to pinpoint exactly what step in the code which is taking the bulk of the processing time?

Answer 1

You should be able to expand webgrind output to locate what is your slower function call. Alternatively you could use function trace feature of Xdebug during your profiling session to get more informations on your function calls.

Generally speaking you should use cache wherever is possible. Memcache is faster than APC as Zend_Cache backend, but you still need APC extension installed (even in development mode) to get a great speedup of your code. I’ve benchmarked its impact on Zend Framework Quick Start on my blog (that post is in Italian, but benchmark data are in English) and the result is pretty impressive, a 3x speedup for the home page.

I’ve applied the cache idea also for the Zend_Application config file (which in your example take half of the profiling time). I discussed it here with Matthew Weier O’Phinney, Zend Framework project leader. What I’ve done is to override the default Zend_Application _loadConfig method with a custom one which caches the result of the parsed file. You can find my class which implement this strategy here on github.