Home » Php » php – Profiling slow Zend Framework MVC setup

php – Profiling slow Zend Framework MVC setup

Posted by: admin July 12, 2020 Leave a comment

Questions:

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?

How to&Answers:

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.

Answer:

After having stripped the require_once of the library as explained in the official performance guide, you should install an opcode cache, like Zend Server CE, APC, or eAccelerator, even on your dev machine.

Also, some resource plugins you may configure in your application.ini may require data caching in order to perform well, like Zend_Db, Zend_Loader, etc. (i won’t explain the difference with opcode caching here)

Don’t forget that in production you will (and i really hope so) use opcode and memory caching, so you need to benchmark in close conditions.

In development you will certainly define a cache the invalidates very fast, so always refresh your page at least two times in a row before looking at the ms.

And then you can start to worry about your “real” bottlenecks.

Ok that was about ZF bootstrap performance. But your question was about profiling code. I use non-free tools for it, but Xdebug combined with Kcachegrind does it also quite well: http://xdebug.org/docs/profiler