PHP is easy… as programming languages go, that is. You can build sites in a real hurry.
With frameworks like Symfony, you can build them faster still, and follow modern programming practices at the same time.
And Apostrophe strips away yet another layer of effort if your site calls for a content management system.
Yes, Java has more raw speed, all else being equal (which it never is). But as the LISP programmers used to say, “a moment of regret, a lifetime of convenience.”
Still, sooner or later success catches up with you and you want your site to cope with Serious Traffic… or cope with moderate traffic on a cheap virtual machine… or at the very least, not be dog-slow with just a handful of users on the system.
There’s a lot of advice out there about optimizing PHP code, some of it well worth your while. And there’s excitement about HipHop, Facebook’s new native code compiler for PHP. But these are drastic steps that require you to rewrite your code or adopt less proven and more awkward ways of delivering your code.
Justified? Sure, sometimes, on the biggest projects in the world (like Facebook) (*). But as Donald Knuth says, “premature optimization is the root of all evil.” That’s because tweaking your code for speed’s sake usually makes it harder to maintain and less adaptable to new requirements.
What most developers don’t realize is that there are three major factors that typically slow down PHP projects based on frameworks (like Symfony or, sigh, Drupal) so much that code profiling and database query redesign don’t even have a chance to become relevant factors. Fix these things first before you worry about other issues:
1. Compiling code over and over and over. Would you wait for your Mac to recompile MacOS X from source code every time you boot it up? Of course not. How about every time you fill out a dialog box? That’s pretty much what you’re doing every time you access a PHP-driven website that doesn’t use a bytecode cache.
2. Waiting and waiting and waiting for web browsers to make another request, pinning down web server processes that your other users need. By default Apache usually lets browsers hold on to a connection for up to 15 seconds just in case they ask for more. This is a good thing in many ways, but 15 seconds is far too long. Which leads us to #3:
3. Tying up a “fat” web server process with PHP on board for every request, even requests for the zillions of little static PNGs that probably make up your page design. (**) A typical Apache web server configuration with mod_php suffers from this flaw, fatally limiting the number of simultaneous users you can handle.
So what can we do about these problems? Quite a bit as it turns out. I’ll start with the low-hanging fruit and move on to the tougher stuff. The fascinating common thread with all of these suggestions: no changes at all to your PHP code.
(more…)
