04:46 pm, 31 Jul 06
wikipedia -- did you know!
The wikipedia list is always both interesting and depressing to me. Recently, I've learned that:
- PHP reboots on each request; that is, there's apparently(?) no way to keep a long-running process around to process requests faster. This means that one way to improve per-request latency is to cut down on the total boot time of your application!
- Rendering a page (this is not including boot-up or fetching page content(?)) takes 800ms. That's almost a second! Now I sorta understand why they came up with that kooky memcache variant -- at those speeds, even loading data from disk is relatively quick.
- On the other hand, they're past 10khits per second.
Ah, now that I click the link I see Matt introduces him, too! He's famous!
Now that you know the ugly details, don't you wish you hadn't asked?
But, I highly recommend using such simply coprocess communication for solving such tough, real-world problems. I'm not saying it would scale well to a 10k+ requests/second environment, though, but it could probably be made to without too much more engineering.
One of the programmers at work started writing persistent PHP applications, and we're toying around with making a PHP application server. By writing our own framework similar to Mongrel we'd be able to get around the initialization crap and completely avoid the terrible "opcache accelerators".
Lucky for us PHP has thought of that ahead of time. Since barely anyone runs PHP outside of mod_php, and if then usually it's a cron, the thing has bizarre memory leaks out the ass. Even if you wanted to write a persistent program you have to work around all of the completely random cases where it'll leak memory. Then there's the really stupid crippling shit, like writing data over a unix domain socket is incredibly CPU intensive using PHP native commands (but libraries it uses do that all the time!?)
I know far more than I want to about making PHP performance suck less, having worked on a PHP CMS at work for just over a year now. It can be really depressing. In my early days I wasted a lot of time trying to find clever ways to avoid PHP's request-orientedness, but the language doesn't really lend itself well to running for long periods, since there are several kinds of in-memory data structure that don't get garbage collected, and many of PHP's "features" rely on the boot-per-request paradigm.
The best you can do is, as Dormando was describing, run a bytecode cache inside your PHP which keeps the compiled bytecodes in shared memory to save re-parsing the source files each time. How well this works depends on your application; we've got a handful of core modules that stay hot in the cache, so it helps us there, but we also have several hundred little self-contained modules that are demand-loaded, so on our less-powerful machines they tend to just chase each other in and out of the cache.
The aforementioned "less powerful machines" (where we host small sites that are pretty much just static content stuffed into a template) don't have that much RAM, so after you've got mySQL, Apache, PHP and a few other bits in memory there's not much left for the cache.
We don't actually employ bytecode caches on those machines in practice; I only really brought it up to raise the point that a bytecode cache doesn't guarantee that your code is going to stay resident in memory, unlike (say) mod_perl where keeping the right modules in memory is the job of the application, and you know that if you've loaded a module on server startup it's going to stay in memory until you explicitly remove it somehow.
I think the main thing that causes our caches to bloat isn't the shear amount of code but more how we have it set up on the server. We have the core CMS code/modules there just once, which is fine: it stays hot in the cache and we're golden. However, most of the "add-on" functionality doesn't go through formal release cycles so each site has its own copy of each of the packages it uses in order that they can be upgraded to arbitrary revisions (in the Subversion sense) without impacting one another.
The bytecode caches (quite rightly) see all of these versions, even if some of them are identical by coincidence, as a separate lump of code. Consequently, they don't stay hot in the cache and the different instances fight one another out over time.
This isn't ideal, but this was a trade-off we made in order that we can be more agile in development which down the line had unintended consequences when we began to use bytecode caching. Finding a better solution that allows us to share more "files on disk" between sites is something that's been on the "to-do" card for a while, but we've not had a chance to work on that yet.