Zend Framework MVC Slow Configuration Profiling

Question

I try my best to work in Zend MVC.

I installed one controller that only die() does, and I turned on xdebug, and pulled out webgrind at my request, which tells me:

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

I am having trouble determining what has been going on for 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 that bootstrap runs the classes defined in my application.ini application, but I don't know which ones are slow)

What is a good way to determine exactly which step in the code takes up most of the processing time?

Answer 1

You should be able to extend the output of webgrind to determine what your slow function call is. Alternatively, you can use Xdebug during a profiling session to get more information about your function calls.

Generally speaking, you should use the cache wherever possible. Memcache is faster than APC as a Zend_Cache backend, but you still need to install the APC extension (even in development mode) to get great acceleration of your code. I compared its impact on the Zend Framework Quick Start on my blog (this post is in Italian, but the control data is in English), and the result is pretty impressive, 3x speedup for the homepage.

I applied the idea of ​​a cache to the Zend_Application configuration file (which in your example takes half the profiling time). I discussed this here with Matthew Weyer O'Finney, Zend Framework Project Leader. I made an override of the default Zend_Application _loadConfig method, which caches the result of the analyzed file. You can find my class that implements this strategy here on github .

Answer 2

After removing the require_once library, as described in the official performance guide, you must set the cache code of the operation, such as Zend Server CE, APC or eAccelerator, even on your development computer.

In addition, for some resource plugins that you can configure in your application.ini , you may need to cache data to work well, such as Zend_Db, Zend_Loader, etc. (I will not explain the difference with caching the opcode here)

Do not forget that in production you will (and I really hope) use caching of the operation code and memory, so you need to navigate in close conditions.

In development, you will certainly identify a cache that is invalid very quickly, so always refresh your page at least twice in a row before looking at ms.

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

Well, that was about ZF boot performance. But your question was about profiling code. I use proprietary tools for it, but Xdebug in combination with Kcachegrind is also nice: http://xdebug.org/docs/profiler