In this chapter, we explain why optimizing PHP involves many factors which are not code related, and why tuning PHP requires an understanding of how PHP performs in relation to all the other subsystems on your server, and then identifying bottlenecks caused by these subsystems and fixing them. We also cover how to tune and optimize your PHP scripts so they run even faster.

The article talks about true high performance, some of the bottlenecks that can keep you from it, tuning your Apache/IIS web server, tips on caching and some ways you can benchmark your application to figure out the best configuration for you.

What is it? It's a daemon gathering information sent by PHP processes by UDP. In the same time Pinba acts as a read-only storage engine for MySQL, so you can use good ol' SQL to access the data. [...] There is no need to store that information for further analysis, therefore Pinba doesn't actually store the data - it keeps it only for 15 minutes (you can change that, of course), which is more than enough to update graphs.

You can find out more about the project on its (wiki) site including links to the latest downloads (version 0.0.3 at the time of this post).

Before we actually get started hacking on our code, let's make sure we've got the right questions asked and answered. We're going to need some resources, the help of others in our organization, and probably some understanding of the current system structure before we're successful in our goal. Some of these questions may seem mundane, and others will be extremely important. But we must ask and receive answers to all of them, so let's get started.

The questions touch on the topics of bottleneck sources, why scalability of the application is needed and what other services are out there that could do what I need without having to roll my own.

Now that collecting code coverage information is not slow anymore (as of Xdebug 2.0.1), PHPUnit's report generation code (PHPUnit_Util_Report_*) has become a bottleneck.

There are several images included in the post (output of KCachegrind):

• generation at revision 1473
• generation at revision 1475
• generation at 1486
• generation at 1488

In my experience, databases have had a long history of being the typical bottleneck in PHP applications. There are many reasons for that.

His reasons include the fact that web apps being heavily database driven, PHP developers would rather write PHP than SQL, and that there's a lack of good, cheap tools to help find these bottlenecks. What he focuses on most, though, is the overhead caused by the need for multi-process environments to force each process to manage their own connections to the databse.

He talks about some stats on average connections and application speed, about efforts IBM has made to help the situation, and how it's not necessarily just the server's fault for delegating out the database resources - why can't they all adapt?