memcached
Spent a while looking at memcached as its simplicity and cross platform nature is very appealing. It’s something you just make a socket to and dump some data into, and it just keeps it in memory. Problem is that memcached itself doesn’t do much other than that – put stuff in memory and define a protocol.
Some of the work you’d expect of a cacheing solution is left to the client implementation. Talking of which I tried out the perl and the java versions. The java client is bigger than you might think as it contains non-blocking code with quite complicated thread queues. Not sure I’d want that bloat in my application, but sensibly the default getInstance returns a blocking instance by default. The java client is not the worst code I’ve ever seen but it’s not exactly great either. There’s quite a lot of repetition, especially the code which sends each call type over the network. No big deal, I or anyone else could easily tidy it up and optimize it.
From previous experience I expect the overhead of all the non-blocking client code is actually not worth it, and that was confirmed by a (very simple) test class I wrote.
The perl test application I wrote performed better than the Java one in general. I expect this is due to some bloat in the Java client. In particular the Java client performed very poorly for large cache values, whilst the perl client scaled O(1).
For PHP, perl and so on, memcached could be useful just running on the same box as a semi persistent store for cross request data sharing, but you need to keep a very close eye on the client code, and probably write your own wrapper to implement all the other cache stuff you need in practice.
For Java, there are great cacheing solutions that run in-process of course, like ehcache, which I have had good results with (although I haven’t benchmarked them much yet), and several Java distributed cache solutions.