On his blog, till has posted the second part of his testing on the Zend Framework and its performance in general usage tasks.

A disclaimer which I should have added to my last article would include that most of my pseudo benchmarks are very subjective and also way too basic. For example, our server setup is pretty comprehensive but we have to take everything into account in order to provide real benchmark. And when I write everything I mean CPU (cores), RAM, motherboard, HDD and so on. Maybe even the throughput of the network card -- if it's different.

This second post is an attempt to correct some of the sore points from the previous one. Here's a list:

• require/include(_once) and __autoload, or "Why is __autoload() 'better'?"
• Zend_Loader ERRATA
• Caching database results
• Zend_Db
• Zend Framework (what it currently lacks)

The TechFounder blog has a few general tips you can use to help your web pages go a bit faster:

As it might be expected, there are several techniques to optimize the delivery of web pages. The Exceptional Performance guide by Yahoo is a great resource for a multitude of optimizations practices, including specifically two techniques which I will address in this article - script minifcation and concatenation.

Suggestions include reducing total request counts and minification of external libraries via the Minify tool.

Till has written up a nice (long) post about the performance steps he's taken to make his installations of the Zend Framework run even better than they already are.

The other day our servers were overwhelmed with the rising traffic and I started profiling my application through Xdebug.[...] On this project we currently run with 100,000 visitors per day on average, our peak is Sunday night where we get a ton more traffic than usually. [...] Here are a few things, that helped us. Suggestions are in no particular order and I should add that whatever is applicable for my situation, doesn't have to work for you.

His suggestions include using APC for caching, using __autoload, caching of DB queries, and some Apache tweaks to reduce what it has to load/use for each request.

In this new post to his blog Chris Jones looks at an option to increase the performance of your PHP/Oracle application even more - converting a REF CURSOR into a piped data set via the PDO_OCI extension.

REF CURSORs are common in Oracle's stored procedural language PL/SQL. They let you pass around a pointer to a set of query results. However in PHP, PDO_OCI doesn't yet allow fetching from them. [...] One workaround, when you can't rewrite the PL/SQL code to do a normal query, is to write a wrapper function that pipes the output.

He includes an example, creating an example myproc() that contains the query to select the last names of all employees in the table. This procedure is put inside of a package so it can be called directly in the SQL statement and the ref cursor can be automatically piped to output.

In this post to his PHPJack blog Richard Heyes comments on the trending he's seeing in the Zend Framework and where its future might lie.

I have been critical of ZF in the past because the performance has pretty much been going down every release and I am not the only one seeing this, there have been a number of benchmarks that show this trend. Having contributed to ZF in the past I brought this issue up multiple times both on the mailing list and even during the meetings the past zendcons and it the general response was they where focusing on features not performance.

He points out a few things that were brought up at this year's Zend/PHP Conference & Expo including the performance focus of future releases, a push to 2.0 after PHP 5.3's release and some of the changes that can cause breaks in backwards compatibility.

Be sure to also check out Matthew Weier O'Phinney's response to the post and some of the comments Richard made.

Benjamin Eberlei has posted some benchmarks he's put together as a part of his attempts to optimize his Zend Framework application.

I haven't changed great parts of the code or anything, I just benchmarked how different global include strategies affect the overall performance of my blog software written with help of the ZF. The following include strategies were tested (I've used the Zend Framework 1.6 RC2 package for all of them): Zend_Loader_Autoload (default and swapped include paths), ZF 1.6 RC2 stripped of require_onces and stripped of require_onces/no autoload and all files directly included.

He ran the tests both with and without APC enabled with a larger difference between the stats without it turned on for each of the four tests.

Paul Jones has taken a look at some performance statistics that Rasmus Lerdorf shared in a recent presentation from some of his tests.

It was with some interest, then, that I viewed Rasmus Lerdorf's slides on the subject of performance benchmarking. I'm beginning to think there's something unexpected or unexamined in his testing methodology.

Paul compares some of his statistics (gathered from his testing) to those of Rasmus and finds a few places where things don't quite match up - specifically in the default overhead that seems to be a part of Rasmus' stats. Paul goes on to look at EC2 as a cause to the problems but ends up without much of a confirmed answer.

In a recent blog post Zoe Slattery took a look at opcodes in PHP, specifically related to performance increases.

After one particularly frustrating day [looking at how the Zend engine works] I asked a colleague (Andy Wharmby) about the issue I was looking at. Then a miracle happened - he'd not only looked at it but had documented it (and many other things) in a set of charts.

She has linked to the charts (Open Office format) for the results of some tests her friend had already run. They're a bit out of date and some parts might be inaccurate, but they're still a good start.

The PHP::Impact blog has a quick performance tip posted today for all of the Zend Framework-ers out there that are seeing some poor performance with their Zend_Controllers.

Zend_Controller_Front gets an instance of Zend_Controller_Router_Rewrite, routes the request, iterates through all the provided routes and matches its definitions to the current request URI. The problem with this is that the more routes you add, the more time the router will take to find a positive match.

Federico includes a few benchmarking stats to back this up ranging from four routes up to forty. His solution is to place the routes in different files and set the location with a Zend_Config_Ini object. This makes the controller only load the ones that are needed instead of pulling all forty into memory to have to parse through.