Speed up your web server with memcached distributed caching

Swiss Cheese

To prevent RAM fragmentation, the daemon uses a slab allocator [6] for memory management. This method specializes in repeatedly reserving and releasing small chunks of memory. In the case of memcached, small means a maximum of 1MB; the daemon will not accept anything bigger than this. If you want to store more, you need to distribute the data over multiple keys or use a different caching system.

Anarchy

Memcached does not concern itself with security. Clients do not need to authenticate against the daemon. Anybody who can access the network can access the cache without reserve. An attacker who knows the usernames behind the keys can systematically ask all the daemons for these names. Cryptic keys can help provide some rudimentary protection. To generate them, you need to hash the usernames in the scope of your own application and then use the results as keys. All account data should be deleted from the cache after use. Also, it is a good idea to define a limited lifetime for the data and to add more layers of security, starting with a firewall to protect the server farm against outside attacks.

Conclusions

Memcached is easy to set up and integrate with existing applications, but this convenience comes at the price of a number of worrisome vulnerabilities. If you manage to address these issues, you get a very fast, distributed cache that will not fail you – even in extreme conditions. The system demonstrates its value day after day on LiveJournal and Slashdot. At the same time, the system is extremely frugal. Because memcached mainly generates hashes, CPU power is not at a premium, and you can even use older computers as cache providers.