The PHP Core Team is meeting this week to decide wether or not there should be some caching 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 caching, they still have to decide which cache technology they’ll build in.

There are many add-ons/plugins to PHP which do caching, but it’s important to keep in mind that there are actually 3 different kinds of caching involved here:

  • Caching the .php files in memory, so you don't access the disk everytime you include _header.php!
  • Caching the compiled opcode for those files, so you don't have to recompile them all at *each* request!
  • Caching 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 caching 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 caching 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 caching 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 caching!

Edit: the big ’no’ argument to including caching 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?