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.

On the PHP::Impact blog, there's a new post mentioning some of the problems that he (Federico) has run into when his Zend_Form forms got larger and larger - performance.

If you are using Zend_Form and your site increases in complexity and attracts more traffic, you are most likely to run into performance problems. Of course, bigger and more complex projects result in more load on your servers. [...] In this post I'll explain the problems I faced when using Zend_Form and how I managed to optimize it and improve the performance of my application.

He ran a few tests against his code and found out that one of the biggest causes of overhead was the many calls to other components in the framework to handle different parts of the output. His solution was to modify the Zend_Form_Elements component to check for dependencies before the form is executed. Pre-loading like this prevents the high-overhead (and repetitive) dynamic loading later on.

Mike Willbanks has posted another part in his "PHP performance" series today. In his previous article, he talked about caching techniques including things like opcode caching and database memory tables. This time he talks about getting the most out of your MySQL database.

Application level SQL performance is much different than the performance of the SQL query itself but rather how it has been designed to work in the application. Many of the items I will be addressing in this area is designing your application to make less queries thus improving scalability and likely performance. However, performance does not always equal scalability as the same with scalability does not always equal performance.

He looks at a few different topics like lazy connections, iterating queries, need-based selects, normalization and a few simple things that you can apply to every SQL your application uses to optimize it as much as possible.

According to this post on O'Reilly's ONLamp.com website, Microsoft has released a new five page PDF file titled "PHP on Windows: Community Involvement Improves Performance" discussing the relationship between the software giant and the language over recent years.

The first effort described is the partnership between Microsoft and Zend that resulted in the development of the FastCGI Extension that essentially allowed PHP to be a first-class citizen when used on a Windows Server with IIS. The second effort described is the Microsoft SQL Server 2005 Driver for PHP developed internally by the SQL Server team.

They also mention Phlanger and the PHP for Microsoft Ajax projects.

The Zend Developer Zone has posted their latest episode of the ZendCon Sessions podcast series - a talk from Christopher Jones on performance in Oracle.

Welcome to The ZendCon Sessions. This episode of The ZendCon Sessions was recorded live at ZendCon 2007 in Burlingame, CA. We hope you enjoy today's session as we listen to Christopher Jones present "Performance Tuning for PHP with Oracle Databases".

You can get at it three different ways - either through just downloading the mp3, using the in page player or by subscribing to their feed to get this and other great recorded sessions from last year's ZendCon.