In a case study posted to his blog, Toomas Romer wonders if a PHP script is embarrassingly slower than than its Java counterpart.

The problem. The PHP implementation [of the IP2C library] is a lot slower. Embarrassingly slower. Without any caching the Java version is able to do ~6000 queries per second. The PHP counterpart can push through ~850 queries. The implementations are the same. The stats provided by the author of the library are 8000 vs 1200. So about the same as my measurements.

He details the script, showing what parts the script is taking up the most time on. A large part of the execution is tied up in IO and the fseek/fread and readShort/readInt functions take up a good chunk.

He even tries removing the functions and making things a bit more streamlined. This helps, but still lags behind its Java brother. Check out the post for more statistics comparing the two.

In response to these stats that the Avent Labs blog published on PHP framework benchmarks, Akash Mehta has made a few of his own observations about the numbers they presented.

All of these frameworks provide levels of abstraction, taking care of many common tasks and moving the logic away from the developer's application. Each framework offers a varying level of this "hand holding", and it's generally accepted that CakePHP leads the race in this area. By making more assumptions and relying on more default behaviours, Cake will always have a far greater overhead.

He makes some interesting observations - things like "CodeIgniter, on the other hand, is far more efficient in what it does - but doesn't do as much [as compared to CakePHP]" and "With eAccelerator, CodeIgniter was serving over ten times as many requests per second than Cake."

The Avent Labs blog has done some basic benchmarking on some of the more popular PHP frameworks out there today. The post includes the tools they used and the full results.

In response to Wil's comment regarding the PHP framework performance comparisons I made in my previous post, I have decided to post the results I got. My decision not post them initially was due to the benchmarks not being done in complete isolation (a separate client and server machine) but the scores relative to each should still be accurate and that's what I am testing for.

He used a machine with a 1.8Ghz sempron chip (running Ubuntu) to run the tests through httperf. His method involved creating the same sort of "hello world" sort of controller to gauge the framework's performance and a baseline procedural version of the same as a guide. His full results are available as a tar file and as a zip archive.

In this new post to the SitePoint PHP blog Akash Mehta talks about a web application, PHPBench.com, that runs real-time benchmarks comparing some of PHP's own structures (like for versus foreach or echo versus print).

The benchmark suite covers all the usual bases, taking a simple task - like iterating over an array - and speed testing almost every possible way to achieve it. Most importantly, however, Chris takes raw numbers out of the spotlight and instead focuses on how the options compare with each other.

Since the results are generated live, they'll change a little bit each time the page is loaded. Each also includes a link to the code behind the benchmark so you can test it on your own system easily.

On his ThisLab blog, Fred Wu has posted some quick benchmarks comparing some of the popular frameworks out there - Ruby on Rails/Passenger versus CodeIgniter/Kohana.

Last few days I have been playing with Ruby and Rails, again. Today, when someone was asking on a forum about the efficiency of web frameworks, I thought I'd give the few frameworks I work with some more benchmark testing.

His benchmarking is based on basic "Hello World" page requests for each of the frameworks. His results were interesting with CodeIgniter coming out with the fewest number of requests responded to (per second) and Rails coming out on top by a margin of about eighty or ninety over CodeIgniter/Kohana.

On the PHP 10.0 blog, Stas does a little benchmarking of a big part of each request to a Zend Framework application - the Loader.

On Zend Framework lists there was a topic raised about performance impact of Zend_Loader component, which is used for - no surprise here! - loading classes, including autoloading, etc. Some folks thought that since Zend_Loader is executing some code before actual loading the required file, it must cost something. And it makes sense. However, how much does it cost?

He uses a set of scripts he developed to compare the bytecode caches of the requests both with and without the caching turned on. He ran the tests on a PHP 5.2 and PHP 5.3 installs with the lower (better) numbers coming from the latter in requests per second. He highly recommends turning this caching on on your system if you haven't already.

DevShed is wrapping up their series looking at benchmarking your PHP applications with the third part - a look at comparing execution times of scripts that can either pull from a database or from a flat file.

This large, complex subject offers numerous possibilities for experimentation, which means that you'll surely have tons of fun creating timing systems with PHP. [...] his article, then, will be focused on evaluating different scripts that fetch sets of records, first from a database, and then from flat files.

They use the Timer class they defined in a previous part of the series and wrap it around both a database class (pulling user information from a MySQL database) and a fetch to a flat file for similar information. General exceptions are handled as a part of the resource connection class.

DevShed has posted the second article in their series looking at benchmarking your PHP scripts. This time they look at the use of "timers" to check on script execution length.

Since you already know how to create timer functions and classes, in this tutorial, I'll create some concrete examples that show where these timing mechanisms can be applied in order to evaluate the performance of certain PHP applications.

They create a few classes that connect to a database and pull out rows (handing it off to a Result class). They use these classes in two examples - one with compression (output buffering) and one without using their Timer class to evaluate the differences.

Christopher Jones has pointed out a new whitepaper that's been published by oracle about the scalability the connection pooling affords for current versions of PHP.

The whitepaper talks about the changes in the PHP OCI8 1.3 extension, explains some of the concepts behind DRCP and FAN, and gives best practices and tuning tips. It includes a new PHP benchmark which shows up to 20,000 connections being handled by Oracle on commodity hardware using only 2G RAM.

The paper also talks about the FAN support that's built in - the ability for PHP to use the Oracle RAC cluster functionality to make for high availability (switching between nodes). The latest beta with all of this functionality in it can be grabbed from its page on the PECL site.

DevShed has posted the first part of a new series looking at benchmarking performance in your PHP applications.

If you're anything like me, you have had your head spinning with questions [...] these and other dilemmas (add your own to the list) sometimes make peace of mind a nearly impossible goal.

The tutorial talks about a few simple methods for running benchmark data including the use of microtime(), an OOP method and wrapping the call inside a method of their class.