On Reddit.com there's a new post from someone relatively new to PHP wondering what the relevance of benchmarks is in a time when most performant sites use caching (full page or data) to increase their speed.

I was speaking to another PHP developer today who is a lot smarter than me. I was curious about Static Site Generators taking over the future of the web. [He] told me that most of the time, big sites have a cache that people hit. So people don't even have to wait for PHP to be interpreted. This begs the question . . . How are performance metrics relevant for different frameworks, when these sites are being cached anyway?

There's several comments on the post now with a few different opinions like:

• "Most of the benchmarks you'll see are dishonest and/or skewed as they don't paint an accurate picture of what's going on, or how they would be used in the real world."
• "As soon as you start taking too much time to return a page to a user you have a knock-on effect where you develop a queue of other users waiting for their page to be returned as well."
• "So far as performance benchmarks go, the framework and language used in your application becomes redundant once you add a caching layer as the page performance is then limited by what caching layer you use."
• "as a rule of thumb "logged out users see cached content" "logged in users see uncached content""

On the Java DZone.com section today there's a "which is faster" post comparing PHP, Java and Python. No, it's not quite what you're expecting - I'd suggest reading on.

Sigh. What a difficult question. There are numerous incarnations on StackOverflow. All nearly unanswerable. The worst part is questions where they add the "in general" qualifier. Which is "faster in general" is essentially impossible to answer. And yet, the question persists. There are three rules for figuring out which is faster. And there are three significant problems that make these rules inescapable.

His three rules are:

• Languages don't have speeds. Implementations have speeds.
• Statistics Aren't a Panacea.
• Benchmarking Is Hard.

He seems to hit most of the issues with these sort of "faster" posts up front and notes that, while benchmarks can be run on a lot of different aspects about the languages, the results depend on how you slice it. His suggestion is, instead, to not try to compare the languages in a grand sense. Take each of them and compare them on specific tasks and let those results stand alone. Each of the three languages is going to be better at something than the other two.

On the ThinkPHP blog today there's a new article looking at some of the best practices they seen when it comes to profiling and benchmarking your PHP-based applications.

Over the years, PHP has evolved from a script language to a programming language used in big applications with high-level architectures. As the most popular language for web applications, PHP is very fast, robust and stable by default. Coming from tiny scripts, PHP is used in large-scale web applications nowadays. In terms of business context, we need to focus on these three key factors: Scalability, Responsiveness and Resource misusage. All three factors have a high impact on hardware costs, customer loyalty and - indirectly - sales.

They mention a few ways that you can use to optimize your application's code including evaluating resource limitations, Firebug caching results and finding bottlenecks with something like XDebug.

php|architect magazine has released their latest issue - the August 2007 edition. The cover story for this month is a piece by Dirk Merkel covering the automation and benchmarking/code profiling of your application to find potential issues before your customers/users do.

Other great articles in this issue include:

• a look at Flex and the Zend Framework
• part one of a series on normalization (Chinese)
• using cURL to extract pages and their data
• "The Job Interview" - an insiders guide.

There's two ways to get this issue - you can either subscribe to the magazine for a year (the PDF edition is only $40 USD) or you can buy the single issue for about $5 USD.

php|architect magazine has released their latest issue - the August 2007 edition. The cover story for this month is a piece by Dirk Merkel covering the automation and benchmarking/code profiling of your application to find potential issues before your customers/users do.

Other great articles in this issue include:

• a look at Flex and the Zend Framework
• part one of a series on normalization (Chinese)
• using cURL to extract pages and their data
• "The Job Interview" - an insiders guide.

There's two ways to get this issue - you can either subscribe to the magazine for a year (the PDF edition is only $40 USD) or you can buy the single issue for about $5 USD.

Paul Jones has information in this new post on his blog with a how-to on doing some benchmarking inside of the Solar application framework.

Comparative benchmarking is tedious work. It's not hard to do, it's just no fun to set up the same scaffold every time you want to figure out how long it takes different pieces of code to execute.

To do a benchmark, essentially you need only four things: a timing mechanism, a loop to run the first case, a loop to run the second case, and a way to show the time taken by each loop.

To illustrate, he gives example code of a simple loop and the output of its timing results. But, since this is a boring example, he demonstrates something a bit more complex - something using Solar_Test_Bench and Solar_Test. The example of using these two components pits require_once and Solar's own loadClass against each other. He also includes another similar test, one comparing fopen and exploding the include path to check for a file's existence.

Paul Jones has information in this new post on his blog with a how-to on doing some benchmarking inside of the Solar application framework.

Comparative benchmarking is tedious work. It's not hard to do, it's just no fun to set up the same scaffold every time you want to figure out how long it takes different pieces of code to execute.

To do a benchmark, essentially you need only four things: a timing mechanism, a loop to run the first case, a loop to run the second case, and a way to show the time taken by each loop.

To illustrate, he gives example code of a simple loop and the output of its timing results. But, since this is a boring example, he demonstrates something a bit more complex - something using Solar_Test_Bench and Solar_Test. The example of using these two components pits require_once and Solar's own loadClass against each other. He also includes another similar test, one comparing fopen and exploding the include path to check for a file's existence.

Jean-François Bustarret talks about a topic in his new post the entire PHP community could definitely benefit from - PHP accelerators.

In the article, he looks at what accelerators are, how they work, and some of the ones that are currently out there in the market:

• APC
• eAccelerator
• Zend Platform

With the ground rules established, he breaks out the analysis into a few different rounds/categories including: support/maintenance, the accelerator's actual performance (including the code they used) and the results he discovered (all graphed out), and, finally, how they handle file updates made to the system.

In the end, there just isn't one that's a clear winner. What it really boils down to is what kind of situation you're in - Zend's option is good if you can pay for everything, otherwise, you'd do well to go with eAccelerator.

Jean-François Bustarret talks about a topic in his new post the entire PHP community could definitely benefit from - PHP accelerators.

In the article, he looks at what accelerators are, how they work, and some of the ones that are currently out there in the market:

• APC
• eAccelerator
• Zend Platform

With the ground rules established, he breaks out the analysis into a few different rounds/categories including: support/maintenance, the accelerator's actual performance (including the code they used) and the results he discovered (all graphed out), and, finally, how they handle file updates made to the system.

In the end, there just isn't one that's a clear winner. What it really boils down to is what kind of situation you're in - Zend's option is good if you can pay for everything, otherwise, you'd do well to go with eAccelerator.