There have been many suggestions on improving Drupal performance, some of them recommend the use of APC module, data caching, or even compilation of the entire system through HipHop for PHP. While the first two solutions have been successfully implemented, no one was able to perform the build process. After many battles with the the compiler and the Drupal code, I present you results of the first successful translation of Drupal 7 to C++ language

He introduces the methods he used and the statistics of the platform (hardware) he tested with. He also includes the software used and compile commands used to create the compiled Drupal version. Included in the post are graphs showing CPU usage comparing the two types of testing (HipHop and APC) versus a normal PHP-based installation. It also briefly touches on concurrency levels and the different optimizations that could be made with the gcc compiler.

Benchmarks such as the PHP / GCC / ICC Benchmark I posted quite a while ago on this blog are synthetic. They test "raw bytecode execution" speed that cannot be translated into real-world situations per se. Flickr recently migrated from PHP 4 to PHP 5. And here are their real world numbers.

The graph shows a dramatic drop in processing needed (CPU usage) at the moment they made the switch over from PHP4 to PHP5.The system processing usage stayed about the same (system processes like logging and memory handling) but the user CPU usage (like what the web server would use) saw an immediate change by almost twenty percent.

Recently the PHP project has been receiving an increasing number of rather silly reports, these vary from simply not reading the manual, searching the internet or a fundamental lack of understanding how the internet works.

He points out three in particular (from the same person, no less) about things that shown an almost complete lack of understand of what PHP does. One was a request to make PHP use less CPU and another asking to make PHP censorship free and, finally, a request to make PHP more secure...by doing away with support for cookies.

Scott also suggests a few constructive things you can do before submitting a good (useful) bug report:

• Gather together as much relevant information as you can (generalizations are bad)
• Run performance checks against older PHP versions to try to pin down when the bug was added
• And, finally: "don't get aggressive or be an asshole when your bug reports get closed".

While I was at php|works I heard a lot of people say how bad of a release 5.2.1 was and that I should stay away from it. Well I didn't take it to seriously at this point, but when I checked what version of PHP we are running on my client project recently it turns out it was 5.2.1.

They were seeing performance issues (database related) so they upgraded to the latest version, 5.2.4, and immediately saw a performance jump of forty to sixty percent and a much lower amount of CPU usage. Upon some further research, he found a certain bug in 5.2.1 that could have been the culprit.