Move your WordPress page cache in-memory for faster performance

Using a RAM disk or ‘in-memory cache’ enables you to benefit from the significantly faster speeds of reading data from memory instead of disk. It also removes disk I/O pressure as well as reducing the CPU utilisation of processing your php scripts. It’s fairly easy to configure too. I successfully moved the cache folder for the Hummingbird WordPress plugin, but you can do it for any other plugin or cache folder, such as wp-cache folder or W3 Total Cache plugin etc. The following commands were used on a debian server so the process should be similar for Ubuntu but may vary for other Linux distros.

Why set up a RAM disk for your page cache?

WordPress already uses database caching (object cache) which saves data from the database in-memory to reduce the burden on your database. By also using an in-memory page cache to store copies of your pages in system memory (instead of on your server storage media) you can further increase performance. Retrieving and serving pages to visitors can be sped up. It can also help reduce CPU utilisation and Disk I/O pressure and may help you avoid upgrading to a more expensive server.

How does it work?

This process uses a tmpfs, which is a temporary file storage area that is a feature of Unix-like systems. It will look like another mounted file system (e.g. a disk), but data is stored in RAM (system memory) instead of on a disk. Because tmpfs is a ‘volatile’ storage device the data will be lost when you reboot your server – but this is typically fine for storing temporary information or using as a cache on a web server as these machines / instances are rarely shut down or restarted.


  • First set up your cache or cache plugin as normal and check it is working
  • Review cache location, permissions and file ownership
  • Temporarily stop caching
  • Setup and mount the in-memory cache storage using tmpfs
  • Re-enable caching
  • Check operation
  • Make the ram disk persistent so it mounts after a system restart

Set up your in-memory page cache

If you haven’t already done so, setup a service or WordPress plugin that can cache your website files like hummingbird or W3 total cache. It is important to check the cache system is working – a quick way to do this is by querying the size of the cache file. If the cache folder is empty, then nothing is being cached. Otherwise it should be working.

You will need to know where your cache is located in your file system. On my server the humminbird cache folder is located at /opt/bitnami/apache2/htdocs/wp-content/wphb-cache. Most other wordpress plugins will store the cache in the wp-content folder. With this info you can use the du command in terminal to query the size of your cache:

du -sh /opt/bitnami/apache2/htdocs/wp-content/wphb-cache

My cache folder (named wphb-cache, but yours may be different if you are using a different plugin) is over 40M and I know it is working properly. Next, query your cache folder for ownership and permissions by moving to the wp-content folder (or the folder that contains your cache folder location):

cd /opt/bitnami/apache2/htdocs/wp-content
ls -l

Note down the output of ls -l for your cache folder as you will need these later, which in my case looked something like this:

drwxrwxr-x  4 user  user    80 Dec 23 08:29 wphb-cache

drwxr-xr-x is the permissions and equates to 755. If you have drwxrwxr-x that would be 775. The “user user” is the user ID (uid) and group ID (gid).

Next disable your page cache in your wordpress plugin to prevent errors whilst we setup the in-memory page cache:

Now mount the ram (tmpfs) disk to the location of your wordpress cache / page cache:

sudo mount -t tmpfs -o size=128M,mode=0775,gid=USER,uid=USER tmpfs /opt/bitnami/apache2/htdocs/wp-content/wphb-cache

Make sure you change ‘USER’ for the correct User and Group ID as well as setting the correct permissions as you noted down earlier – likely 0755 or 0775.

I specified a 128M ram disk with this command, which should be fine. You can increase it as long as you have enough space on your server. You can find out how much free space you have and how memory is currently being used by running free -h. If you are using a virtual machine or an instance hosted on a cloud provider like AMS then you may have a web portal or dashboard to tell you your memory utilisation.

Lets just check that it mounted correctly by running ls -l again and checking that the output is similar to what we saw before:

drwxr-xr-x  4 user  user    80 Dec 23 08:35 wphb-cache

If the listed ownership or permissions are different then you can correct these by running either of the following commands for changing ownership or permissions respectively:

sudo chown USER:USER wphb-cache
sudo chmod 0755 wphb-cache

Next, re-enable caching in the wordpress admin area and watch for any errors there, or in your web server error_log file. All being well wordpress should now start writing cache files into memory. You can see evidence of this by testing the size of the folder as we did earlier.

Alternatively run the df -h command to query disk space (which includes in-memory tmpfs storage ‘devices’). You should see something like this amongst the output:

tmpfs           128M  2.1M  126M   2% /opt/bitnami/apache2/htdocs/wp-content/wphb-cache

Finally, in order to make sure that our wordpress cache RAM disk is available after a potential reboot of the server we need to add it to /etc/fstab:

sudo nano /etc/fstab

This command will open up the fstab file in a file editor. Add this line below the last entry in the file:

tmpfs /opt/bitnami/apache2/htdocs/wp-content/wphb-cache tmpfs size=128M,mode=0755,uid=USER,gid=USER 0 0

Press ctrl + x to exit the editors and follow the prompts pressing ‘y‘ and enter to save the file and you are done. Monitor your error-log for any issues.

It’s worth noting that a possible downside to any type of caching is that the process of clearing and rebuilding the cache will add extra pressure on your web server appliance / instance. If you have minimal spare capacity on your server then you could minimise the impact of this by making sure the cache is only cleared in off-peak times.

If you need to change the size of your cache, then you can use the mount command with -o flag with the remount option. For example, this command would double the size of our in memory cache to 256M:

sudo mount -o remount,size=256M /opt/bitnami/apache2/htdocs/wp-content/wphb-cache

Also read: Make your wordpress server more secure by hardening headers

Questions or comments? Let me know!