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).