I have been doing some experimenting with caching performance using loader.io and have been left with some puzzling results.
I was originally on a shared host that used a LAMP stack. Even with caching enabled it would fall over after 200 visitors in 1 minute.
I setup a basic LEMP (Nginx 1.9.12 + PHP-FPM7.0) 1GB Ubuntu droplet on Digital Ocean and copied my site across (subdomian multisite).
To get a baseline I setup the automattic wp-super-cache plugin using the PHP caching option for simplicity and ran a test. It worked extremely well so I ran the maximum I could on the free plan (10,000 in 1 min) and here are the results.
This is amazingly good compared to my shared host that would never get below 300ms on a single request and would experience timeouts under any sort of load.
Everything I have read says that by using PHP caching in wp-super-cache I will get worse caching performance than using webserver caching as there is an overhead caused by the static pages being served via PHP.
Excited to see how quick I could get my responses I configured the fastcgi_cache to cache PHP files and then deactivated the wp-super-cache plugin.
I ran the load test again and here are the results:
The results are pretty much the same. The the first request is taking a little longer but it is the cached response I am interested in as that could most likely be optimised with some tweaking.
From this result I can’t see any advantage to using fastcgi_cache over letting wp-super-cache handle the caching using PHP. Using the PHP caching is certainly a lot simpler when dealing with user generated subdomains and mapped domains.
I am only on the freeplan so I can’t push the load test any higher but my needs don’t exceed 10k in 1 min.
This has left me confused as every single article I have read on this says that there are significant performance benefits to using a caching rule in the webserver instead of serving a static file with PHP but with this setup that doesn’t appear to be the case.
The fastcgi_cache is served directly from ram. Wp-super-cache uses php to read a static file from the SSD so I see why it should be faster so why isn’t it?
This of course isn’t an actual problem, I am just confused why my results are like they are and seem to contradict all the guides I have read.
Can anyone shed any light on why I am getting these results?
1
Nginx is really good at concurrency (PHP not so much) so you should try a bit more than 180 requests per second. Maybe 500, or 1000 depending on your server resources and network throughput.
The fastcgi_cache is served directly from ram. Wp-super-cache uses php
to read a static file from the SSD so I see why it should be faster so
why isn’t it?
It depends. First of all, whether fastcgi_cache is served from memory or not depends on your fastcgi_cache_path. If it’s set to a tmpfs mount, then yes, it will be in memory. If it’s set to a regular non-tmpfs directory, then it will be served from disk.
But disk doesn’t always mean the actual disk 🙂
When you access a file from disk, Linux will cache it in memory, so the next time you access the same file, it will be served from memory. This is why most tests with loader.io, apache-bench and other tools that “hammer” the same page are flawed. They all cause your stack to access and serve the same files available in memory. This is why your WP-Super-Cache PHP option is likely not causing significantly more disk IO than Nginx and thus seems just as fast with low concurrency.