On his site today Lukasz Kujawa has a post that compares some performance benchmarks of several popular PHP frameworks including Slim, CodeIgniter, Laravel, Symfony2 and Zend Framework 2.

There are many assumptions around performance of different PHP frameworks. I frequently hear strong opinions about superiority X over Y in this context. There are companies writing new PHP frameworks from scratch because available solutions are too slow for them. What does it really mean? Does the framework performance matters? Before answering this questions lets check how slow is your framework!

He took the "quick start" projects provided for each of the examples and ran some tests with the Apache Benchmark (ab) tool against EC2 instances, all configured the same way. The results weren't overly surprising with Slim beating the others hands down (it's a micro-framework after all) and Kohana and CodeIgniter coming in second and third. The frameworks with more overhead like Zend Framework and Symfony ranked some of the slowest.

On the Systems Architect blog there's a recent post from Lukasz Kujawa about comparing Apache2 and Nginx for PHP applications, specifically when using the PHP-FPM module. His tests are based on the results from three different application types - a large Zend Framework 1 app, a small PHP script and a WordPress installation.

If you've ever been trying to squeeze more out of hardware you must have come across Nginx (engine x). Nginx usually appears in context of PHP-FPM (FastCGI Process Manager) and APC (Alternative PHP Cache). This setup is often pitched to be the ultimate combo for a web server but what that really means? How much faster a PHP application is going to be on a different web server? I had to check it and the answer as often is - that depends.

He ran the tests on an Amazone EC2 instance and optimized the server to ensure that there was a little interference as possible. The used the Zend Optimizer Plus opcode cache and PHP 5.4 and set the logs to go to memory instead of disk. Graphs included in the post show the results of the benchmarking of each application, with the differences (in most cases) not being that wide of a gap.

There isn't big difference between Apache2 and Nginx in PHP context. Yes, Nginx can be much faster when delivering static content but it won't speed up PHP execution. Running a PHP script seams to be so CPU challenging task that it completely eclipse any gain from a web server.

Kevin Schroeder has a new post to his site today wondering about the "max_input_time" setting for PHP and why some recommend it being a large number despite the (usually) fast time PHP has accepting input.

I asked a question on Twitter on why some of the recommend max_input_time settings seem to be ridiculously large. Some of the defaults I've seen have been upwards of 60 seconds. However, after thinking about it I was a little confused as to why a C program (i.e. PHP) would take so long to process string input. The reason I was thinking about this was because I was thinking about ways to protect PHP from denial of service attacks.

So he ran some tests to see just how effective changes in this setting could be and how much time a typical PHP request would need to take in input. Using a Zend Framework 2 HTTP client, he simulated POSTS and tracked the start and end times for a file upload. He includes the timing results in the post based on both this setup and a change to only post regular text-based form data.

Over on Reddit.com there's a flamewar...er discussion happening about this set of benchmarks (from 2011) showing things like response time, system load average and a function execution map for several popular frameworks.

In the Reddit comments most people share the similar ideas about the results:

• "I don't put much stock in hello world bench marks for MVCs. If you just need "Hello world" then write it in html."
• "Asking which framework is the fastest is almost irrelevant in most cases. I always dislike benchmarks like this because the actual situation is so much more complicated than a handful of benchmarks can show."
• "Any decent framework can output a simple content page from cache, it should not even have to call any router or controller. That's why simple content benchmarks are useless."
• "Who cares? The speed of a language or framework does not translate over to the speed of your website. What matters is your architecture."

If you're looking for benchmarks that are more useful than these, I'd suggest checking out (and maybe contributing to) the ones Paul Jones has created over on Github.

Ariz Jacinto has pointed out some results from a recent benchmarking "game" that compares the performance of several languages against each other in overall speed.

Here's the link to the Computer Language Benchmark Game as of July 15, 2012. You'll see that the median speed of PHP is slightly faster than Python 3 and Ruby 1.9 on x64 Ubuntu/IntelQ6600 Quad-core machine.

You can visit the results page and turn on and off various languages to get the updated results in the chart. You can also limit it down to one of the many benchmarking test types as well.

In this quick post to her site, Lorna Mitchell shares some of the benchmark results she found when doing some tests with the latest version of PHP - 5.4.

Today I'm giving my first ever talk at OSCON - about PHP 5.4 (I'll also be giving my second ever talk at OSCON, about RESTful services; it's a busy day!). My talk includes some benchmarks which I thought I'd also share here. [...] This graph shows the performance of four versions of PHP (because the bench.php script that lives in the php source tree didn't appear until 5.1). The axis up the left is the time it took to run the benchmark script - so a smaller number is better news.

You can see a dramatic difference between even just the latest in the PHP 5.3.x series in the 5.4 results. There's also a table with the details of each of her 10 executions of the "bench.php" script showing the results of the time spent to run the script on four different PHP versions.

In this quick post to her blog, Lorna Mitchell shares an interesting bit of benchmarking she did between PHP versions 5.3 and 5.4, finding 5.4 twice as fast as it's previous version sibling.

So recently I was working on some benchmarks for different versions of PHP, because I heard that PHP 5.4 is "faster" and since I'm a data geek I want to know how much faster! Now, PHP 5.4 is, in general, faster than PHP 5.3 but not twice as fast* unless you pick a use case which has been particularly optimised. My first attempt at benchmarking the two versions produced this. This was a surprise to me; was PHP 5.4 really so much faster??

Her benchmark was a pretty simple one - looping and creating a new object, evaluating the timing of how long it took to execute. A commentor also points to some more official benchmarks that were done and posted to the php.internals mailing list.

In this new post to his blog Larry Garfield tries to dispel a common misconception in the PHP development world - that the readfile function should be considered harmful and can cause memory issues in your code.

If you're like me, you've probably read a dozen or two articles about PHP performance in your career. Many of them are quite good, but some are simply flat out wrong, or misinformed. One of the old truisms that has been repeated for as long as I can recall is "don't use readfile() if you have big files, because it reads the whole file into memory and your server will explode." [...] There's just one problem with that age-old truism: It's not true.

He created some benchmarks to illustrate the differences between several of the common methods for working with files via the fread, fpassthru, stream_copy_to_stream and of course readfile. He reports the results based on the runtime and the peak memory usage and noted, ironically, that while the times varied slightly, the memory consumption was exactly the same for all of the approaches. Since there's no real reason not to use "readfile", he looks at three reasons why there might be this stigma attached to it (including the issues that could come up with output buffering enabled).

Artur Ejsmont has a new post sharing some benchmarks he put together about the "messages per second" and "time to execute" when using PHP to pull from various messaging backends.

I have looked at the state of different messaging backends recently and i ran a little benchmark to see what is the rough comparison of message publishing throughput. Results that i got are quite surprising. What i wanted to achieve is some sort of reassurance before choosing a messaging bus for my PHP project.

Running both the PHP and the messaging test scripts on the same server, he pulled from a few different backend systems - RabbitMQ, MySQL, MongoDb, Memcached and ActiveMQ. The results were interesting, showing an interesting result in the time it took to execute versus the number of messages per second pushed in.

In this recent post to his blog, Konr Ness has benchmarked the components that the Zend Framework uses to read in different types of configuration files - JSON, native PHP arrays, INI, XML and YAML files.

If you application relies on parsing one or several config files each time it is bootstrapped it is important that you select a file format that is fast to parse. But you also want to select a config file format that is easy for a human to read and edit. In a recent application I am building I also had the need to write modifications to config files, so I also benchmarked the Zend_Config_Writer components.

He includes both the sample configuration INI file and the benchmarking script he used to measure the results (all configurations were read from external files, even the native PHP option). His results were pretty predictable (with the exception of YAML reading) with the standard INI file coming in second to the native PHP arrays, but having the advantage of being more readable.