Benjamin Eberlei wrote:
> 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?
Yes APC is install and heavily use :-)
I've ( due to ZendStudio ) the zend_debugger installed and also the xdebug.
Did you have a quick way to generate a trace I can use with KCachegrind ?
It would help me to confirm or infirm what the ZendStudio Profiler give me.
>
> 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 ...
>
>
>
--
Bruno Friedmann
Ioda-Net Sàrl
2830 Vellerat - Switzerland
Tél : ++41 32 435 7171
Fax : ++41 32 435 7172
gsm : ++41 78 802 6760
www.ioda-net.ch
Centre de Formation et de Coaching En Ligne
www.cfcel.com
