-- Dennis Fogg <[EMAIL PROTECTED]> wrote
(on Thursday, 11 October 2007, 06:36 PM -0700):
>
> I completed the basic structure of my ZF infrastructure
> and noticed that it seemed quite slow.
> So, I did some performance profiling and used some
> performance tools only to find that ZF is pretty slow for me:
> a blank page takes 1.3 sec to load.
> I'm pretty new to performance tuning so I'm seeking advice.
>
> I'm testing the performance of a web page that just has a few
> words on it. It also does a Smarty include of a header page
> with a few words. The PHP script does connect to my db.
>
> Performance techniques I've already included:
> -postgres db uses persistent connections
> -postgres db has ssl connection turned off in postgresql.conf
> -use eAccelerator as opcode cache
First off, you may be interested in Paul M. Jones' excellent
benchmarking, which he last reported in the following blog entry:
http://paul-m-jones.com/blog/?p=258
In it, he tries very hard to compare apples to apples and oranges to
oranges.
I have a few comments on what you write, however.
First off, I've heard that eaccelerator and xcache's approaches to
opcode caching may not be terribly performant; switching to APC or Zend
Platform would likely help achieve better results.
Second, I see you're on Windows, but you don't indicate if you're using
Apache + PHP or IIS + PHP, nor if you're using mod_php or FastCGI. What
you use will definitely impact performance; the fastest solution for PHP
on Windows is IIS + FastCGI + PHP.
Finally, running XDebug to do profiling actually impacts performance in
and of itself; it's basically an illustration of the Heisenberg
Uncertainty Principle (i.e., observing a phenomena changes it). If you
want to do benchmarking, turn off XDebug and use a tool such as ab
(apache benchmark) to test under load.
Finally, now is not the time to benchmark. The time to benchmark is
after your application is written and working; any earlier, and you're
not focussing on the application but on minutiae. The operative phrase
here is "premature optimization".
I have to say, I have never experienced numbers as low as yours. I've
built a number of sites using framework, and particularly the MVC, and
find it scales well, particularly with an opcode cache sitting in front
of it. I'm very curious as to why you're experiencing the slowness you
are.
> My ZF infrastructure currently does the following:
> -sets up Zend_Loader
> -sets up registry, config_ini, Zend_translate, Zend_log
> -sets up db connection and does an actual connect
> -sets up zend front controller
> -sets up Smarty views
> -dispatches and displays blank page
>
>
> Over 20+ runs, I got the following data:
>
> .57 sec (44%) for db connection even though it's persistent connection
> .26 sec (20%) for Zend_Controller_Front::getInstance() call
> .23 sec (18%) for $f_ctl->dispatch() call
> .06 sec (5%) for $f_ctl->setControllerDirectory(<hard coded path>) call
>
> 1.30 sec (100%) for complete php script to run
>
> All of these times are wall clock times via xdebug_time_index().
>
> I also ran xdebug and generated a cachegrind profile and the
> times were very different:
> wincachegrind says the cummulative time is 147 ms
> (not 1300 ms which is the wall clock time).
> I'm not sure why there is so much difference between the times.
> (does the cachegrind file only measure the php time?)
> Some data from WinCacheGrind:
>
> 0 ms cumm time for Zend_Front_Controller::getInstance (5 calls)
> 23 ms cumm time for Zend_Front_Controller->dispatch (1 call)
> 5.2 ms cumm time for Zend_Front_Controller->setControllerDirectory (1 call)
>
>
> All of this was run on my laptop as the web server:
> 1.2 gb ram, 1.6 ghz single core, 7200 rpm disk,
> Windows XP, php 5.2.3, postgres 8.2,
> Zend Framework 1.0.2
> and I used a different PC as my browser client.
>
> My questions/concerns are:
> -the db connection time is as fast as I can get.
> I've come to accept that.
> See
> http://beach-blogger.blogspot.com/2007/09/zend-framework-postgres-vs-mysql.html
> -both instantiating the front controller and dispatching
> the page are taking a huge amount of time ... why??
> -even the single setControllerDirectory() method call
> is taking much more time than expected...
> -why do the wall clock time and the cachegrind time differ
> so much?
>
>
> --
> View this message in context:
> http://www.nabble.com/ZF-performance-advice-tf4610974s16154.html#a13167829
> Sent from the Zend Framework mailing list archive at Nabble.com.
>
--
Matthew Weier O'Phinney
PHP Developer | [EMAIL PROTECTED]
Zend - The PHP Company | http://www.zend.com/
