"If it does not scale, it is broken by design"

Today a server of a customer with fantastic uptime suddenly lost its MySQL process while the customer was in the middle of a minor tweak of the WordPress platform.

Investigation revealed that the InnoDB storage engine was not able to allocate memory pages for a routine operation and in its most bizarre way of handling errors did a safe crash of the MySQL server ( No, there is no such thing as a "safe" crash, so please dear MySQL folks add sane error handling or stop pretending you are an "industrial" strength SQL server!)

Further conversation with the customer revealed that the developer, following an example in PHP Manual, decided it was a good idea to do this:


header("Content-type: application/force-download");
//header('Content-type: video/x-ms-wmv');
header("Content-Transfer-Encoding: Binary");
//header("Content-length: ".filesize($file));
header("Content-disposition: attachment; filename=\"".basename($file)."\"");
readfile($file);


And since some of the files could be nearly 500M in size, the developer changed the PHP memory limit to accommodate.

Add a few thousand Apache processes on a server busily serving hundreds of video files using such a code path and you are virtually guaranteed to use all available RAM in minutes, if not seconds. But of course it worked on a test system with one web browser.

Why? Because embedded PHP is designed not to exit, its garbage collector is totally stupid, and probably 90% of the examples in the PHP manual are written by people who do not understand the concept of scalability.

And that's why 90% of PHP applications are broken by design. That's the cause of performance collapse over time for CMS-systems written in PHP.