Re: [fw-general] ZF performances / profiling the culprit
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
Re: [fw-general] ZF performances / profiling the culprit
Forget all what I've said in previous message.
There was an error not shown and the mvc complete dispatch was broke so the
result are faster.
Accept my apologize to Component writer's.
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
Re: [fw-general] ZF performances / profiling the culprit
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
Re: [fw-general] ZF performances / profiling the culprit
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
Re: [fw-general] ZF performances / profiling the culprit
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Yeah you have a huge bottleneck there by using the partial helper four times. Try to replace the partial calls with simple include ''; calls and measure the time again. Ben ... : ___ _ ___ ___ ___ _ ___: : | \ /_\ / __| _ \ _ (_) \ : : | |) / _ \\__ \ _/ / | |) | : : |___/_/:\_\___/_| |_|_\_|___/ : ::: : Web: http://www.dasprids.de : : E-mail : [EMAIL PROTECTED] : : Jabber : [EMAIL PROTECTED] : : ICQ: 105677955 : ::: Bruno Friedmann schrieb: 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 :-) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFI/YXV0HfT5Ws789ARAiAkAJ9Obn0B3fKc+tqnYtfEUR9zSgQv8wCcCsYN gdXVfAYSxWb06MgAEmgYcic= =ol9k -END PGP SIGNATURE-
Re: [fw-general] ZF performances / profiling the culprit
-- 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. 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. 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. -- Matthew Weier O'Phinney Software Architect | [EMAIL PROTECTED] Zend Framework | http://framework.zend.com/
Re: [fw-general] ZF performances / profiling the culprit
- Original Message - From: Matthew Weier O'Phinney [EMAIL PROTECTED] To: fw-general@lists.zend.com Sent: Tuesday, October 21, 2008 3:00 PM Subject: Re: [fw-general] ZF performances / profiling the culprit 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. There is one eminent thing to remember... Performance problems will only occur when no caching is used. After the first load into cache, ALL adapters have the same performance !!! The only difference is the first loading time. Greetings Thomas Weidner, I18N Team Leader, Zend Framework http://www.thomasweidner.com
Re: [fw-general] ZF performances / profiling the culprit
Thomas Weidner wrote: - Original Message - From: Matthew Weier O'Phinney [EMAIL PROTECTED] To: fw-general@lists.zend.com Sent: Tuesday, October 21, 2008 3:00 PM Subject: Re: [fw-general] ZF performances / profiling the culprit 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. Sure but tmx have some nice feature ( human and xml ) and doesn't need compilation. and extraction. There is one eminent thing to remember... Performance problems will only occur when no caching is used. After the first load into cache, ALL adapters have the same performance !!! The only difference is the first loading time. Thanks about That Thomas, tmx work correctly only from 1.7 with cache ( locale and translate ) before 1.7 inside cache only the first call to translate are in ( If first user call is en then there's only en string retrieved , if fr is first call, all user get the french ) Now with the 1.7 all is working as expected. -- 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
Re: [fw-general] ZF performances / profiling the culprit
There is one eminent thing to remember... Performance problems will only occur when no caching is used. After the first load into cache, ALL adapters have the same performance !!! The only difference is the first loading time. Thanks about That Thomas, tmx work correctly only from 1.7 with cache ( locale and translate ) before 1.7 inside cache only the first call to translate are in ( If first user call is en then there's only en string retrieved , if fr is first call, all user get the french ) Now with the 1.7 all is working as expected. That was one of the reasons why I reworked I18N. Greetings Thomas Weidner, I18N Team Leader, Zend Framework http://www.thomasweidner.com
Re: [fw-general] ZF performances / profiling the culprit
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. 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 ? Thanks all for you great advise, help each of us making php/ZF better and better, also in developer mind and how to approach realize great things with. -- Bruno Friedmann Ioda-Net Sàrl 2830 Vellerat - Switzerland
Re: [fw-general] ZF performances / profiling the culprit
-- 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) -- Matthew Weier O'Phinney Software Architect | [EMAIL PROTECTED] Zend Framework | http://framework.zend.com/
Re: [fw-general] ZF performances / profiling the culprit
-- 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. -- Matthew Weier O'Phinney Software Architect | [EMAIL PROTECTED] Zend Framework | http://framework.zend.com/
Re: [fw-general] ZF performances / profiling the culprit
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 :-) -- Bruno Friedmann Ioda-Net Sàrl 2830 Vellerat - Switzerland layouts.tar.gz Description: GNU Zip compressed data
Re: [fw-general] ZF performances / profiling the culprit
Bruno Friedmann wrote: Hi All. 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 ) In the attach file you will find the export html and xml format. Perharps some Guru's can help me to confirm or not what I'm thinking. And give the opportunities to ZF maintainers give their attention to the struggle component of our prefered PhP Framework. My big Apologizes for the attach. I'm pretty sure It's too big for a majority of you. Next time I will post it on my server. Time to take some break week-end hours :-) -- Bruno Friedmann
Re: [fw-general] ZF performances / profiling the culprit
-- 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. -- Matthew Weier O'Phinney Software Architect | [EMAIL PROTECTED] Zend Framework | http://framework.zend.com/
Re: [fw-general] ZF performances / profiling the culprit
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. I hope this is what you need. Don't Hesitate to ask if you need something. -- Bruno Friedmann Ioda-Net Sàrl 2830 Vellerat - Switzerland
