hello,
you might want to install pecl-xdebug extension to PHP and enable profiling.
You can then use Webgrind or KCachegrind to show you which functions and
classes use the most processing power in your appliaction.
Have you installed APC or eAccelerator?
On Thursday 23 October 2008 22:04:40 Bruno Friedmann wrote:
> Follow at the end
>
> Matthew Weier O'Phinney wrote:
> > -- Bruno Friedmann <[EMAIL PROTECTED]> wrote
> >
> > (on Tuesday, 21 October 2008, 09:45 PM +0200):
> >> Matthew Weier O'Phinney wrote:
> >>> -- Bruno Friedmann <[EMAIL PROTECTED]> wrote
> >>>
> >>> (on Tuesday, 21 October 2008, 06:56 AM +0200):
> >>>> Matthew Weier O'Phinney wrote:
> >>>>> -- Bruno Friedmann <[EMAIL PROTECTED]> wrote
> >>>>>
> >>>>> (on Monday, 20 October 2008, 07:00 AM +0200):
> >>>>>> Matthew Weier O'Phinney wrote:
> >>>>>>> -- Bruno Friedmann <[EMAIL PROTECTED]> wrote
> >>>>>>>
> >>>>>>> (on Sunday, 19 October 2008, 07:30 PM +0200):
> >>>>>>>> With the help of ZendStudio, I'm trying to understand why on one
> >>>>>>>> application I've got 25/30 req/s and on the second one I've only a
> >>>>>>>> 5/5.50 req (1.6.2) or a 7/8.2rqs ( 1.7.0 notice the little change
> >>>>>>>> ) ( a simple html file is giving a 385rqs and a 404 error page
> >>>>>>>> give around a 280/320rqs )
> >>>>>>>>
> >>>>>>>> The profile result give me a 59% time consume by Layout ( which I
> >>>>>>>> doesn't have on the speed app ) and another 12.5% to Translate
> >>>>>>>> ( ok I'm using tmx which is not the most speedy thing )
> >>>>>>>
> >>>>>>> You can save me a little time and effort here by attaching the
> >>>>>>> layout script you use, as well as a count of the number of times
> >>>>>>> calls are made to translate items. With that information, I can add
> >>>>>>> some information to our performance and profiling test suite.
> >>>>>>
> >>>>>> Quickly I'm calling the index controlleur / index view with layout.
> >>>>>> html/index.php
> >>>>>> -> ZFApplication ( which is the real bootstrap )
> >>>>>> -> app/Module/Default
> >>>>>> -> /Controller/indexController
> >>>>>> -> Action indexAction
> >>>>>> -> Scripts/index/index.phtml
> >>>>>>
> >>>>>> Layout contain
> >>>>>>
> >>>>>> |-- common
> >>>>>> |
> >>>>>> | |-- footer.phtml
> >>>>>> | |-- header.phtml
> >>>>>> | |-- help.phtml
> >>>>>> |
> >>>>>> | `-- menu.phtml
> >>>>>>
> >>>>>> `-- main.phtml
> >>>>>>
> >>>>>> For the index view there's a test
> >>>>>> if ( !Zend_Auth::getInstance()-> hasIdentity() ):
> >>>>>> // Render login form or logged
> >>>>>> echo $this-> action(null, 'login');
> >>>>>> // If we are anonymous
> >>>>>>
> >>>>>> ----------------------------------------------
> >>>>>> For translation I've a global function __($str) which translate
> >>>>>> strings.
> >>>>>>
> >>>>>> For the whole projet there's a 945 call to it.
> >>>>>>
> >>>>>> For the index call profiled it's about 24 calls.
> >>>>>
> >>>>> The above may very well be the culprit, but I'll write a test just to
> >>>>> see.
> >>>>>
> >>>>> Can you give the contents of your layout files? I'm curious to see
> >>>>> how you're pulling in content -- if you're using partial(), action(),
> >>>>> or simply render(). I've already identified a bottleneck in partial()
> >>>>> that I'll be working on. Additionally, I typically recommend against
> >>>>> action() because I know already that internally it's expensive; it's
> >>>>> cheaper to create a helper that pulls from the model directly.
> >>>>
> >>>> If what you say is correct, I'm in trouble :-)
> >>>>
> >>>> You will see why in the source attached ...
> >>>>
> >>>> So I'm waiting your confirmation, and eventually other
> >>>> recommandations. There's some refactoring/rewritting in the air
> >>>> tonight :-)
> >>>
> >>> The only reason to use partial() instead of render() is when you
> >>> absolutely need a clean variable scope for the rendered view script. In
> >>> your case, I'd recommend simply substituting render() for each time you
> >>> use partial(); this will definitely improve speed.
> >>
> >> Ok this remark make sense ... I think it should find it's place as
> >> remark in docs.
> >>
> >>> I see you're using action() to pull in a login form. Since you won't be
> >>> worried about pre-populated values or validation, it may make more
> >>> sense here to either instantiate the form object directly and display
> >>> it, or create a view helper that does this.
> >>
> >> To be honest, I'm actually in a process to limits the number of view
> >> helper to a quantic's number.
> >> I feel I'm on the wrong way. Too strict perhaps in the logic approach
> >> There a login controller in which the login form & logic reside so I'm
> >> calling it because layout permit this,
> >> leaving all login to it's own controller/model/form/view system.
> >
> > Makes sense. Just remember that this is an expensive operation. You may
> > want to consider a view helper that calls the action() helper, but
> > caches the results.
> >
> >>> See if the above changes help your performance. If not, the next
> >>> thing I'd suggest trying to move to gettext for your translations to
> >>> see if that speeds things up. If so, you may be able to develop
> >>> using TMX, and write a build script that converts to gettext later.
> >>
> >> I will give them a try on Thursday and Friday and keep you inform of
> >> the result.
> >>
> >> In your Guru's opinion, shall I try the svn version of 1.7 or could I
> >> stay with the PR release ?
> >
> > I'd go with trunk; there are changes going in daily improving the
> > release, and we'll be doing at least one bug hunting event before the
> > release. (1.7 will be branched from trunk prior to the first RC)
>
> Ok I've upgrade the 1.7 to svn checkout.
>
> I've transform all my main.phtml layout to not use this->partial / action
> or render In the tested page I also kill the $this->action('login');
>
> With the same condition I obtain a 8 rqs
> and a when only this->action login a 6.5 rqs
>
> This disappoint me a bit ...
> The server could respond a 434 rqs for a phpinfo :-)
> I know this absolutely not the same ...
>
> The old version ( php4 without oo & pdo ) answer at 427 rqs
>
> A ZF application which doesn't use layout & translate & acl
> give me a 13.80rqs ....
>
> [some fondue later ... :-) ]
> This is frustating ... I've made some new profiling which indicate clearly
> that one of the bad guy are Logger. (I've installed and use FirePhpBug
> which is initialize by
> private function initializeLogger()
> {
> // TODO : should only be present in dev env
> $logger = new Zend_Log();
> $writer = new Zend_Log_Writer_Firebug();
> $logger->addWriter($writer);
> Zend_Registry::set('logger',$logger);
> $writer->setEnabled(true);
>
> }
>
> When I comment this one in bootstrap the rate rise to a 12.01rqs which is
> fine compared to the other application which have many less component
> activated.
> ( even with this->action() enabled and all $this->render enabled in
> main.phtml
>
> So the lesson : never try to log or monitor an application or use non
> official plugin :-))) (at least for the momemt)
>
> If performance are concern for the 1.7.x release someone should take a look
> at Zend_Log(),Zend_Log_Writer_Firebug() plugin I will try to report all of
> this on Jira for this plugin.
>
> So what can we do next to obtain the near phpinfo() 400rqs rate ? :-))))))
>
>
> Thanks for you help, One time again I've learned many things ...
--
Benjamin Eberlei
http://www.beberlei.de
