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.
See the bottom of this post to read about alternatives to local in-memory caches – such as Content Delivery Networks.
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.
Process
- 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-cacheMy 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 -lNote 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-cachedrwxr-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-cacheMake 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-cacheIf 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-cacheNext, 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-cacheFinally, 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/fstabThis 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 0Press 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-cacheAlternatives to in-memory page cache
These days it may be far easier to take pressure off your server resources by using a Content Delivery Network (CDN). A CDN offers the ability to cache content closer to your users via an edge-network. Services like Cloudflare (free for basic accounts) can do this and way more. This can have a number of benefits:
- Speed up delivery of content,
- reduce the number of requests handled by your server,
- increasesresilience in case your server goes down for short periods*,
- reduce your network egress costs; and,
- reduce vulnerability to attack vectors like DDOS.
*depending on edge network cache configuration.
Cloudflare will also offer resource optimisation like minify, and image compression / optimisation.
If you have a static site then you could even configure Cloudflare to cache the html page as well as all the images and video – taking almost the entire load of your website. It’s pretty simple to configure too.
Also read: Make your wordpress server more secure by hardening headers
Leave a Reply