APC & E-Accelerator et al, are great tools to increase performance practically instantly through Op-Code caching. Nowadays OpCode caching is actually built into PHP. But these systems have another common utility that is less frequently used which is the ability to store user variables. These variables are stored in a reserved segment of memory allocated by the extension when the Webserver starts up. Access to these variables is extremely fast since there is no disk or network overhead. Unlike a database, filesystem or network-based store like Memcache, variables created by APC et al in the Webserver SAPI are unavailable to the CLI SAPI.
More power – Sys5 Shared Memory
Unix Sys5 pronounced ‘System Five’, refers to an early version of Unix. Some of the core components of these early versions of the Unix OS have been preserved throughout the years and a subset of them have been bundled up into PHP under the System V IPC family of functions. These include:
Unlike lots of the functions available in PHP, these tools tap right into the operating system where the Webserver process is just one of many running in parallel. That means when we reserve a memory segment using the Sys5 API it will be available to multiple processes; that’s why it’s called Shared Memory! APC et al reserve memory which is bound to the process that reserves it, so any APC user variables from the CLI are invisible to the Webserver and vice-versa. Moreover, APCu and E-Accelerator user variables stored through a PHP CLI script don’t persist across script invocations.
What’s the use case?
You’re probably thinking, cool stuff, but does it really matter? Well think of anytime you normally use the filesystem or a database to share data in a PHP application between multiple processes, the most common of which is likely Apache and a Cron Job. Think of a drop-ship site that takes orders through an E-Commerce shopping cart, processes payments then queues orders in a local database. Another process runs via Cron which sends any pending orders to the manufacturer for production. Here orders are queued in a database by Apache then accessed and updated by a Cron.
Storage Mediums available to PHP
Ever study the basics of computer hardware? Knowing computer anatomy is valuable in practice because even though computers are fast, if you ask them to do a lot of things it can still take a lot of time. Taking advantage of storage performance can have dramatic implications on program performance. Imagine a simple program that has to frequently read and write from the hard drive. If the program could leverage main memory to read chunks of data in groups, hold results in memory and write them at once etc it could be much faster with the same semantics for the core objectives in either implementation.
PHP applications are no different conceptually, they just deal with a different set of mediums. Because PHP is a high level language, typically details of memory managment are far more coarse than they are with unmanaged languages like C. Have a look at the diagram below which illustrates a rough parallel between the memory devices a typical PC or server has access to, versus ones that are common fare to a PHP application. The idea is the same in both paradigms, as storage size increases so does access time (there is also a notion of persistence which usually is only available to the slower stores).
On the next page I’ll show you how we can write a class that uses the Sys5 extension in PHP to store persistent variables in the server’s main memory using PHP.