PHP and Caching to Memory on /dev/shm – A Benchmarking Story

PHP and Caching to Memory on /dev/shm – A Benchmarking Story

Memory is fast and Disk is Dangerous. That is what webserver admins have beaten in to their fingertips. It is a message that is reinforced many times.  After your third disk failure on a MySQL server with InnoDB tables larger than memory.  The sweet silence of your blackberry after offloading your static files to a CDN.

When Anton was so kind as to post his article on caching Zend, it got me to thinking. Caching is awesome. I love caching things! I remember when a grizzled datacenter admin showed me how to configure Windows NT with a Ramdisk to use as the webroot for IIS. Putting important stuff in memory is always the right thing to do, right?

I had been playing with the various PHP accelerators taking note of their use of /dev/shm on modern Linux operating systems. After seeing how simple it was to set up memory based mounts the gears started turning.

I currently have a few PHP based sites that use a Mainifest file and pre-generated template files for startup and rendering. I bet I could increase the speed of loading/rebuilds by putting all that on /dev/shm/. I’m not the only crazy one out there! Once I found this article by the very sharp Gonzalo Ayuso, I was set to change all my production servers to use /dev/shm for all PHP’s temp directories.

One thing held me back; I wanted to know how much faster it was going to be. So ugggggggggh I was going to have to benchmark this. Fair enough, I need numbers if I’m going to brag about this later. So I refreshed an old laptop with an updated install of Archlinux and a stack of Apache 2.2 + PHP 5.3 + MySQL 5.1. I wanted bare metal for the test as VPSes and other Virtualized systems wouldn’t be a good indicator.

I then appropriated all calls to creating temp or cache files to a global var that pointed to a /dev/shm/ directory. This is going to be good. Now a quick bash script to run 1000 calls to rebuilding the cache/manifest. For good measure I ran a second test with 10,000 requests from apache bench with the compiled cache/manifest in memory to get a feel for real-world performance.

Enough jibber jabber. Where are the results?

  • Page Load (Disk) 78.812 ms
  • Page Load (SHM) 86.1456 ms
  • Cache Rebuild (Disk) 142.502 ms
  • Cache Rebuild (SHM) 141.187 ms

I was flabbergasted.  I ran 3 more trials of each test manually inspecting and clearing files between to ensure consistency.  Same results.  How could this be?  MEMORY IS FAST AND DISK IS DANGEROUS!

I do not have an answer for these results (Feel free to jump in with comments).  The moral of the story is that Good Admins don’t jump to conclusions.  Especially with exotic system changes.  So before you try that “new hot thing” someone touted on twitter…benchmark it first.

  • I’m agree with you. Exotic system changes must be taken carefully. Everything that goes out the standard generates an “extra”. And it’s a good practise to try to avoid them as long as it’s possible. Or at least test them within our servers

    The benchmark must be done thinking in what hardware we have. Disk can be different. IDE, SATA, a disk closure, a NAS, a SAN, and also we can add some kind of RAID. And the read/write speed can be totally different (we are balancing security and speed). With memory we can have similar situations depending on the type of RAM we have. You also must take into account if your apache/PHP is living together with another servers with a high usage of disk operations such as fileservers (Samba), Databases, … In this cases read/write performance could be definitely a bottleneck

    Obviously if with your architecture, the cache in disk and without the use of /dev/shm is better, go ahead. You will avoid to to rebuild all cache when memory flushes.

    The good point of moving cache to shm is that it’s pretty straight forward to implement. You can do it (and revert it) without changing any line of PHP code. Only playing with symbolic links in our filesystem (OK you need to create a script to rebuild the cache also). That’s because I like it. It’s another tool we have in our bag to use it (or not) according of our requirements.

    By the way I’m totally agree with your idea of taking exotic techniques carefully. Even mine 🙂

  • Very, very interesting. Did the Apache build have mod_cache or another cache turned on, that could explain the results?

  • dalesaurus

    Nope, mod_cache was not enabled. I think it just helps put things in to perspective on how much effort has been put in to these great Open Source projects to make them “just work well”. Worry less about apache internals and focus on figuring out why your code is slow 🙂

  • Dale, you were benchmarking Apache, not code, so commenting back about slow code is just silly.

  • Without knowing the exact details of your benchmark, it’s difficult to know… But it’s also worth considering that your OS would be caching the disk contents… In RAM.

    Caching in /dev/shm would behave pretty strangely… but it would make it possible to keep the cache entries in RAM for as long as you want, rather than being at the mercy of the lower levels…