After hours struggling against an overwhelming traffic push by GlusterFS motivated by w3 total cache, I ended up splitting disk caches successfully. After some time monitoring, it seems it is all OK.
So, basically, /home/foro/public_html is a GlusterFS mount. /home/foro/public_html/wp-content/cache is part of that, but inside that directory, I created a local directory to host db, object, page_enhanced and tmp. So the config will be part of the Gluster share but all cache files will be saved locally.
Take a look at the listing so you can reproduce it:
# ls -lah /home/foro/public_html/wp-content/cache
drwxrwxrwx 3 apache apache 4.0K May 14 22:33 .
drwxrwxrwx 16 foro foro 4.0K May 14 22:29 ..
drwxr-xr-x 2 apache apache 4.0K May 14 22:11 config
lrwxrwxrwx 1 foro foro 29 May 14 22:33 db -> /home/foro/wordpress_cache/db
-rwxrwxrwx 1 foro foro 0 May 22 2015 index.html
lrwxrwxrwx 1 foro foro 33 May 14 22:33 object -> /home/foro/wordpress_cache/object
lrwxrwxrwx 1 foro foro 40 May 14 22:33 page_enhanced -> /home/foro/wordpress_cache/page_enhanced
lrwxrwxrwx 1 foro foro 30 May 14 22:33 tmp -> /home/foro/wordpress_cache/tmp
And good luck!
Side note: this hack will force you to manually purge the cached objects through cron jobs on each server.
Quick note. You should only use the page/minify from disk and try using object/database from memory. Because object caching can have in some sites 12k+ files (Even on small sites). Database caching can be smaller maybe 200 on a small site. But there are still a lot of files.
Actually, my idea didn’t work fine, specially because at some point users may inadvertently switching servers, having unexpected results and annoying white pages.
I needed to switch to memcached and setup a single server with a 1gb pool and a smaller TTL, and have all servers connecting to it. It is working fine though.
So no. It is a bad idea to split disk caches as I wanted.
Don’t do it.
