On the Leaseweb Labs blog there's a recent post looking and some of the things you can do to optimize Zend Framework and Doctrine when used together for database access.

In principle, the combination of Zend Framework with Doctrine is not too difficult. But first let's talk about the preparations. According to the author of Zend Framework, the default file structure of project can be a bit more optimal.

They start by describing this optimized file structure (moving the models out of the modules and into the library) and what you'll need to change in Doctrine's configuration to make this work. The post also includes examples of what the larger config should look like when the changes are made. They show how to extend the default Doctrine CLI tool to make a custom "sandbox" instance and show some tuning you can do on the Zend Framework side so it can optimally work with the new models.

Brian Swan has a new post to his blog today showing you how to use caching for performance tuning on your Windows/IIS PHP application. He uses the IIS 7 output caching method instead of an external cacing tool or library.

The IIS output caching module allows you to configure IIS to cache dynamic pages generated by PHP. When a PHP page becomes "hot", the content of the page is cached so that is served without executing the script that generates it. [...] With the IIS Output Caching module you can cache all pages generated by PHP, vary what is cached by query string parameter value, or vary what is cached by header value.

He touches briefly on when he thinks you should use output caching for your applications since it can add extra overhead if it's not actually needed. He suggests turning it on when you have entire pages that don't change often and could benefit from just being displayed as-is. He shows how to enable the caching on IIS and includes some bits of code to show the results. There's a few other handy features he points out too like a file change notification and a configuration for a time interval caching rule.

In a new post to the Bollysite Blog there's a look at how to get better performance out of your Lighttpd web server with xcache.

A typical PHP application and most of the frameworks uses "The Loop"� method to code the website. Whenever request comes to website, It's typically sent to index page to handle every parameters. [...] We can use xcache variables to store entire web page and serve it from RAM.

They include some basic benchmarks showing the impact that caching an have on a site as well as code that you can use to integrate their xcache library into your site. The library uses the XCache functionality to store the rendered output of the page for a default of three hours time.

The Zend Developer Zone has posted their seventeenth episode in the ZendCon Sessions podcast series today. This time it's Jay Pipes' MySQL-centric talk The Legend of Drunken Query Master.

The ZendCon Sessions are live recordings of sessions that have been given at previous Zend Conferences. Combined with the slides, they can be the next best thing to having attended the conference itself. In this series we will be releasing regular sessions from ZendCon 2008 as we lead up to this year's ZendCon.

You can check out his slides as you listen to the episode either through the in-page player, downloading the mp3 directly or subscribing to the podcast's feed.

The Zend Developer Zone has a new article posted looking to help you squeeze the most performance you can out of the Zend Platform application from Zend on your IBM i machine.

Zend Platform on IBM I provides many benefits including monitoring and advanced debugging. One of the more confusing issues that customers face with Zend Platform on IBM i is the impact on development machines. Most will try out Zend Platform in a development environment or on a development LPAR.

There's three things they suggest to tweak to help you get the most out of Platform - code acceleration, dynamic content caching and code compression.

Mike Willbanks has posted an introduction he's written up giving some helpful hints at tuning your servers and PHP applications for performance.

The focus of this post is not to show performance related items to specific PHP frameworks since many bottlenecks actually apply before running the framework itself that should certainly be solved up front. Therefore in this posting I attempt to look at simple items that can be deployed in order to produce finer tuned systems.

He talks about a few different aspects:

• PHP Performance Tuning (opcode caching, apc file priming, includes, loops, etc)
• RDBMS Performance Tuning (indexes in queries, query caching, archiving)
• HTTP Performance Tuning (content compression, css sprites, limit modules, etc)

In a new post to his blog, Christopher Jones mentions some of the talks that he's going to give at the upcoming Zend/PHP Conference & Expo:

Oracle & PHP users: make sure you check out the Zend Conference. I'll be given a couple of sessions, "Connection Pooling & Other Features for Data Scaling" and "Performance Tuning for PHP with Oracle Databases". There are plenty of other great talks, too.

There's tons of other sessions happening during the conference including talks on:

• best practices
• enterprise PHP
• the Zend Framework
• API design

Check out the official conference page for information on location, other sessions and registration.

The Internet Super Hero blog has posted 59 statistics they've generated while they were sting the latest versions of the mysqlnd (native driver) in PHP:

59 - that is the number of statistics collected by mysqlnd. When I started writing this blog post, I hoped it would be easy going describing them. But it wasn't. Some ten days ago, we've had 51 statistics and near zero tests for them. Now we have 59 statistics. And, in a certain way, every figure is a tuning screw in the hand of one who knows what they do.

The list of stats presented include functionality for:

• buffered_sets, ps_buffered_sets
• rows_buffered_from_client_normal, rows_buffered_from_client_ps
• rows_fetched_from_client_ps_buffered
• unbuffered_sets, ps_unbuffered_sets
• rows_fetched_from_client_ps_unbuffered
• flushed_normal_sets, flushed_ps_sets

Check out the rest of the post for the numbers and results (as well as some images showing the difference between buffered and unbuffered results).

Even more good news for mysqlnd users out there - according to this new post on the Internet Super Hero blog, some of the tuning options it enables can help you save 40% of the memory you were using before.

mysqlnd saves memory. It consumes half as much memory as libmysql. This is what we have been convinced of. This is what we taught you. Then I tried to test it and made Andrey get nervous for a few hours'� Meanwhile he is fine again and we can announce: mysqlnd saves memory, not only in theory, we tested it - we can proof it, can we?

The proof comes in the form of a few "tricks" and some of the settings that the software can use to optimize buffer sizes. Benchmarks (and the code to run them) are also included to show what the differences are between mysqlnd and libmysql.

Stoyan Stefanov has posted some of his tips to his blog today. Specifically, they deal with the PEAR::DB class, demonstrating some of the optimization of the package he's discovered in his coding experience.

If you use PEAR::MDB2, you can set a custom debug handler and collect all the queries you execute for debugging and performance tunning purposes, as shown before. But what if you're using PEAR::DB? Well, since PEAR::DB doesn't allow you such a functionality out of the box, you can hack it a bit to get similar results.

He creates a simple app to help with the illustration - a number of select queries to grab zipcode information from the database. As it stands, the PEAR::DB package doesn't handle the debugging well, so he adds in a few more lines to buffer the connection and some reporting code to check the resulting output (as well as some of his sample reports).