On the Tideways.com blog there's a tutorial talking about the "unknown performance bottleneck" that can be caused by PHP's own session garbage collection. This garbage collection happens when sessions expire and they need to be removed from the current set/data source.

Here is one performance setting in your PHP configuration you probably haven't thought about much before: How often does PHP perform random garbage collection of outdated session data in your application? Did you know that because of the shared nothing architecture PHP randomly cleans old session data whenever session_start() is called? An operation that is not necessarily cheap.

It's his general advice to avoid PHP's random garbage collection (it happens one in every 1000 requests, randomly) and opt for a more consistent method using background scripts. He gives an example using the Laravel framework and it's modified session garbage collection happening every 50th request (making use of the Symfony Finder component). He points out the problem with its implementation and the negative impact it could have on large, highly used applications. They share some of their own statistics and how to change this default (modifying the lottery option and making a custom "cleanup" command).

On the QaFoo blog there's a post sharing some of what they've learned about the common bottlenecks in performance testing and some things you can to do determine the issues in your own tests.

Most developers by now internalized that we should not invest time in optimizations before we know what happens exactly. [...] This is true for optimizations in your PHP code but also for optimizations regarding your infrastructure. We should measure before we try to optimize and waste time. When it comes to the assumed performance problems in your system architecture most people guess the root cause will be the database. This might be true but in most projects we put under load it proved to be false.

So, how can we figure out where the problems are located in our stack?

They talk about some common testing practices using basic tools (like ab and siege) and having them perform common operations on the application. They then talk about testing for high load, monitoring the stack for the impact and a few tools you can use to gather statistics. They end the post with a quick mention that, despite popular opinion, the issue isn't always the database's fault. Sometimes other technology that's in play - like file locking issues or processing for server-side includes - and other things that may only show up under high load.

John Lim has updated his Optimizing PHP article with some new tips on caching data:

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.

Antony Dovgal has announced a tool that can help you find out where issues are in your code - specifically places where too much work is being done and gumming up the works. The Pinba statistics server for PHP that gathers UDP data from the PHP processes and makes it available for parsing/graphing.

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

In this new post to his (newly WordPress-ed) blog Brandon Savage looks at a consideration most developers think of too late and when their applications are already starting to bulge around the edges - scalability. It's the first part of this series.

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.

Sebastian Bergmann has posted about a bottle neck in the PHPUnit unit testing software for PHP:

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

Sebastian Bergmann has posted about a bottle neck in the PHPUnit unit testing software for PHP:

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

Hot on the heels of this announcement, Andi Gutmans has posted some of his thoughts on this new functionality and how it can help companies both large and small (he mentions specifically Yahoo! of course).

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?

Hot on the heels of this announcement, Andi Gutmans has posted some of his thoughts on this new functionality and how it can help companies both large and small (he mentions specifically Yahoo! of course).

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?