-- Paul M Jones <[EMAIL PROTECTED]> wrote (on Tuesday, 02 September 2008, 02:43 PM -0500): > > On Sep 2, 2008, at 11:55 , Matthew Weier O'Phinney wrote: > > > -- Michał Minicki <[EMAIL PROTECTED]> wrote > > (on Tuesday, 02 September 2008, 06:30 PM +0200): > > > Paul M Jones wrote: > > > > > Anyway, this only shows that some frameworks are better optimized > > > > > to > > > > > display "hello world" than others. > > > > This is **not** correct. Every line of application code added to the > > > > dispatch cycle will only reduce performance, so when you are > > > > attempting to improve the speed of your application, these results > > > > show exactly how much room for improvement you have. > > > > > > Let me just make everything clear. What Paul is getting at is that > > > you > > > can't get any better response times than the hello world > > > application. If > > > you're hitting those numbers you just can't go any faster. There is > > > nothing more you can do about it but to customize the framework code. > > > > Not entirely what he's getting at. What he's saying is that without > > caching, this is the baseline. You can definitely add caching to speed > > up the processing, and only if you still need additional performance > > should you start customizing the framework code. > > Matthew, that's pretty close, but not quite the whole thing. > > You can cache processing results (either data or views), but if that > caching happens at the action-method level (which I think is the most- > likely case), then you are not likely to see any increases past the > results I've posted. This is because the dispatch cycle has to pass > through the bootstrap, front controller, page controller, and action- > method to begin with; the only part that remains is the action-method > code and the view rendering.
This differs dramatically from full-page content caching, however, in which case you'll get substantially better throughput. A good caching strategy will do a mixture of full-page caching for the more dynamic areas of the site, and partial content caching. Admittedly, if you do partial-content caching, you will have more overhead than the hello world, however. > In my testing, there is no action-method code, and you can't get faster > than "do nothing" there. Similarly, the view rendering is only to > present a static text "hello world" and I don't expect a caching system > will be able to outperform that. So the results I show are the fastest a > dynamic dispatch can occur. > > Full-page caching will *definitely* speed things up, but that is only > because the framework is being sidestepped entirely; the web server is > sending a static (cached) page from disk at that point. Exactly. One thing to note as well is that there are ways to alter ZF without altering it... Most of the MVC, for instance, has interfaces, allowing you to substitute your own implementations. (Admittedly, this needs some work, as the interfaces have gone out-of-date with features currently in ZF.) Doing custom code like this is a great way to dramatically speed your application -- assuming you know exactly the needs of your applicaiton. > Hope that helps to illuminate the testing results more clearly. -- Matthew Weier O'Phinney Software Architect | [EMAIL PROTECTED] Zend Framework | http://framework.zend.com/
