In most cases, XCache is a really great choice. We’ve experienced very little problems with it (compared to APC, which has been proven to be somewhat unstable under Windows and has some pitfalls – see below). Plus, it’s fast and caches your opcodes.
When using Fast CGI, be aware that the PHP processes do not share the same cache and that their caches are thrown away when the PHP process is killed. For those setups, Memcached is a good choice. It doesn’t really matter what particular extension (php_memcache or php_memcached) you use.
Make sure that you have not only enabled XCache itself, but also the vardata cache. See the XCache configuration for a more complete list of available options. For a single developer machine, these settings work fine:
xcache.var_size = 32M xcache.var_count = 1 xcache.var_slots = 8K
For servers, you will want to tweak the var_size.
There is a rather strange configuration for APC which will forbid your scripts to set the same value twice. This makes it impossible to overwrite values. BabelCache tries to work around this by deleting a key before attempting to set it, but this strangely does not fully solve the problem.
You may want to take a look at the slam_defense option for APC (Google will help you here).
As long as there is no definite answer to this problem, we strongly discourage the usage of APC (as a caching system) and recommend XCache (see first question).
In most cases, you either disable caching completely (using the blackhole cache) or use a “real” caching system (like XCache). The memory cache will store every value only for the current request and is therefore only useful when you have to compute the same value over and over again during a single request and do not wish to cache it permanently.
We have yet to find a real usecase for it. So don’t worry when it’s useless to you – that’s normal. ;-)
We have found the normal filesystem cache to be overblown in nearly all cases. It creates sub-directories with the first two characters of the item hash, but for small systems this creates a lot of directories holding only one or two files.
The plain filesystem cache, added in version 1.2.7, avoids this overhead and stores the datafiles directly inside the namspace directory. It’s the better option for most websites, because really large pages will use memcached anyway.
So try to avoid the normal cache and always use the plain one. It will suffice. If it’s still to slow, you might want to take a look at the SQLite cache.