The PHP Core Team is meeting this week to decide wether or not there should be some cacheing built into the next major release of PHP. (I guess that would be PHP 6).
I definitely hope the answer will be YES since this has been available on others platforms for ages (J2EE, ColdFusion, ASP…) and it’s really missing when you want your app/site/service to scale to large numbers of users.
Furthermore, once they decide to include cacheing, they still have to decide which cache technology they’ll build in.
There are many add-ons/plugins to PHP which do cacheing, but it’s important to keep in mind that there are actually 3 different kinds of cacheing involved here:
- Cacheing the .php files in memory, so you don't access the disk everytime you include _header.php!
- Cacheing the compiled opcode for those files, so you don't have to recompile them all at *each* request!
- Cacheing arbitrary data from inside the script, so you can reuse it on subsequent requests without recomputing everything
There is one PECL extension that manages all of these 3 cacheing forms: APC. (Note: precompiled for Windows here). I’ll bet on that one! Not only because I think it’s doing the job as it should be done (easy setup, clean function syntax and everything), but also because Rasmus is already involved on that one’s development team! ;)
Anyway, I think it’s really important for PHP to standardize on some cacheing mecanism so we can design our applications to take advantage of it, no matter what host you’ll be running it on.
The main reason we don’t yet use shared memory data cacheing in b2evolution, is precisely because there is no standard that will be broadly available on hosts. Of course, we could still have included our own PHP class writing cache files, but that’s bound to be less efficient than shared memory cacheing!
[Edit: the big ’no’ argument to including cacheing would be that because APC uses shared memory, it kind of breaks PHP’s “shared nothing” architecture. With shared memory it is so much more likely that a small error will corrupt something that might eventually cause a larger crash… So, be bottom line is that introducing a shred memory architecture introduces a potential weakness, do we want that?]