For some reason, nobody seems to acknowledge there is a bug with
flush() in PHP 5.4.
In any previous version of PHP, you could just do:
and the PHP output buffer would be sent to Apache which would in turn send it to your web browser.
We are not talking about any side effects due to compression or charset sniffing here. We are talking about: flush() was working just fine.
And then compes PHP 5.4 and it doesn't work any more. And you revert to PHP 5.3 and it works again. PHP 5.4, broken again. And you can reproduce that to infinity but still, nobody wants to acknowledge it.
So we had to find a workaround. Here it is: just replace your flush() calls with a custom call like flush54() defined like this:
This will restore the initial behaviour...
You may have noticed that PHP scripts that echo a lot of content appear to be running with poor performance…
Well, the operative word here is “appear". It is a common misconception that “echo is the slowest PHP command"! :p
The problem is actually just a bandwidth issue! When you try to pump a lot of content though the Internet, at some point you experience “load time"… and at some point PHP actually experiences “send time"!
You may measure the execution time between the begining and the end of your script, and, on a slow connection, it may show you that it took 500 ms to execute. You may even narrow it down to a single echo statement that takes 480 ms to execute. But that time actually includes wait time where PHP cannot send any more data back to apache!
There is a common trick that consists of starting output befering before echoing, like this:
This will allow PHP to move on and appear to terminate fast. But the truth is, all the content is now in PHP’s output buffer, and although your script is done, PHP is still working in the background to send all that data to your web server (apache for instance).
The APC cache can significantly improve your PHP script performance, just by installing it, which basically takes 5 minutes! (Plus, it’s actually supported by the core PHP developers and will probably be integrated into PHP6…)
Here’s what I did on my Debian Lenny box…
First you may want to have a reference benchmark to see if it actually improves:
Now install the APC package:
Now, restart apache:
Now, you can run your benchmark again and see the difference! Tada! :)
It's been 3 years since PHP 5 has been released. Yet PHP 4 still rules on the vast majority of web hosting platforms.
This is annoying for PHP open source developers who cannot leverage the potential of PHP 5 as long as they need to support PHP 4. This is also annoying for the PHP development group since they still need to support PHP 4 instead of focusing on PHP 6.
In a way it is also annoying for the web hosts themselves, since they too need to deal with clients who want PHP4 compatibility and others who want PHP5 features.
What strikes me is that the solution seems obvious, and yet the PHP team fails to recognize it.
The only reason webhosting providers haven't massively upgraded to PHP 5 yet is because it would break applications running on their current client's site. It may also prevent new clients from installing well known applications (phpBB...) which may fail on PHP5.
Of course, that would not have been such an issue if PHP5 was indeed upward compatible with PHP4. But it isn't! (object references,
clone keyword, etc.) So what do we do now?
Web hosts install PHP5 next to PHP4, but you need to rename your scripts to script.php5 instead of script.php ... which breaks existing URLs... so no-one uses that either.
The real simple solution would be for the PHP team to release some PHP 5.x version which would actually behave like PHP 4 (completely!) with a simple config switch. It could then be installed in place of PHP 4 without breaking anything.
Once that is done, any PHP application that is PHP5 aware would just include something like this:
and everything would be fine.
Maybe PHP5 should have 2 separate php.ini files. Maybe that
ini_set() call should be required to come at the very top of the script. Maybe it should be a different function. But all in all, the solution seems so simple you have to wonder why anyone would want to support the older version for 3 years instead...
At the PHP Forum in Paris this year, Rasmus Lerdorf (the creator of PHP) wittily explained that SOAP was "intrinsically broken" because it's too complex... "just as anything that takes more than 20 minutes to understand".
I liked the way he put that! ;)
When it comes to webservices, I myself tend to prefer XML-RPC (which goes by the motto: "Does distributed computing have to be any harder than this? I don't think so.")... Sometimes, I also wonder if REST would be a nice alternative...