I was about to post about my experience on this matter. Here it goes, but first, a quick definition. The cache is a term that refers to a fast and temporary memory. The logic is simple: those things that you require the most, get them closer to you so that they are easy and fast to reach.
In Q2A, this means that, instead of going to the database and execute queries that might be costly in terms of resources, Q2A can store the results of those queries in a cache. Although this sounds great, in practice, it is less efficient than it seems.
One of the reasons for this to happen, is that the cache is not used by every database query but rather to queries that are fired by users not logged in. Also not all of the queries are cached.
I have done some tests in a site with 3.5 million visits per month. I tested the site without the cache, with the filesystem cache and the memcached cache. In terms of perceived performance, I noticed no change in either of them. Here are some additional details for each of them.
Filesystem cache
- After setting up a tool that helped in measuring performance I could confirm an obvious thing: the filesystem cache hits the filesystem really hard.As I have a fast SSD this was not really a bottle neck. However, that might not be the case for everyone. In these cases maybe overall performance will decrease.
- As this cache is not automatically cleaned, a CRON job has to be setup to automatically clean it. If not, the cache will get too big and become slower than not using it. Note the CRON job has to bootstrap Q2A and clean the cache using its internal functions. Clearly, this is not for beginners.
- Installation is relatively simple, as a directory with generous privileges has to be setup and stuff has to be stored in there.
- You will have to manage security on the cached data (which I think is not a big deal unless you are part of the NASA).
memcached cache
- After setting up a tool to measure performance, I was surprised it was not that fast. I can't confirm in detail why but I think I have configured MySQL pretty well to my needs so the most used parts of the database were already in memory. This, in conjunction with the (controversial) MySQL Query Cache resulted in almost no difference. I haven't tested this in a not-so-polished MySQL instance or in MySQL 8, which lacks the query cache.
- In order to configure memcached you will need SSH access to the server or the host company will have to provide a simple-to-manage memcached instance. This is probably "less for beginners" then the filesystem method.
- This method is more secure than the filesystem approach, unless the memcached instance is shared with other applications, of course.
In short, if you have a well-setup MySQL instance, up to Q2A 1.8.6, at least, I would recommend not using any cache or, at most, use the memcached. If you are in MySQL 8, I would recommend using memcached rather than no cache at all. However, don't expect huge changes.
PS: Funny fact. I can confirm first hand that NASA uses Q2A! Yay!
