3 ms·

I refuse to believe in memcached. Apache, along with other web servers, has a built-in in-memory cache for static content. Decent SQL-servers have several cache

by tx 19y ago

I refuse to believe in memcached. Apache, along with other web servers, has a built-in in-memory cache for static content. Decent SQL-servers have several caches on different levels, in fact those caches in theory should be far more effective than a simple remote hashtable that memcached is. And all that - on top of OS level disk I/O caching. I suspect that memcached was born as a result of sloppy SQL querying multiplied by inefficient SQL schema and lack of RDBMS tuning skills. Moreover, anyone can have memcached with zero programming by either hosting DB on a RAM disk with replication, or using in-memory tables.

jbert 19y ago
My hunch is that it's down to cache invalidation logic. It's easier for the app to know when a single memcached entry needs to be invalidated than for the SQL engine, which perhaps tends to be conservative in what it can cache. (e.g. MySQL query cache is flushed if a single write happens to the table, so all your users will be dumped out of that cache whenever any row is updated.) Hence you get a better hit-rate with memcached. Perhaps it is also simply easier to tune memcached than most db memory caches. I benched "retrieve data and instantiate object" on a couple of different, unloaded, systems and a simple select-and-instantiate-from-mysql was a bit faster than the memcached equivalent. I didn't measure CPU usage server-side though, so under load things might be different.
- tx 19y ago
  I agree, in-memory hash table controlled manually by the application has a million ways to beat any SQL-server caching. What I am saying is that I suspect that memcached is way overused by people who don't know much about SQL. I am not posing like a DB snob, in fact my skills are fairly modest, but even I know that query caching is just one of the many caches SQL servers employ, and well designed servers easily service thousand+ of requests per second. And that's just one instnace. Very very very few web sites ever reach such loads. In theory memcached should be more like a very niche product for such rare sites, yet it appears that everybody is using it. I am against it because it increases the complexity. Memcached deployment and cache control become two more things to get right. That's all.
brianr 19y ago
The next time you're designing the backend for a high-traffic site, I think you should give it another look. As jbert pointed out, the MySQL query cache is emptied every time you make any change to the table, making it pretty useless unless you only ever do selects. And even for the selects, wouldn't you rather select by key from a hashtable in O(1) than select from a btree index in O(log n) at best?
nostrademons 19y ago
Brad Fitzpatrick addressed that when he released the initial memcached - LiveJournal had spent about 2-3 years fiddling with MySQL caches to get decent performance. They even took out one of those MySQL support contracts and had a MySQL engineer in to troubleshoot their performance problems. The bottom line was that yes, DBs should cache things - but they don't. The main issue was as someone else mentioned, the query cache is flushed whenever the table's written to, which makes it essentially useless on a multi-user website. Also, memcached distributes the cache itself across multiple machines, which makes a huge difference to cache hit rates. When you have a local query or app cache in a multi-server setup, you end up with each cache storing the same data, so the size of the cache is limited by the amount of RAM you have in the machine. If you distribute the whole cache, you're limited by the amount of RAM in all machines, which means almost every request can hit the cache. Hence you have architectures like FaceBook's 3 TB memcached setup.

by tx 19y ago

jbert 19y ago

My hunch is that it's down to cache invalidation logic. It's easier for the app to know when a single memcached entry needs to be invalidated than for the SQL engine, which perhaps tends to be conservative in what it can cache. (e.g. MySQL query cache is flushed if a single write happens to the table, so all your users will be dumped out of that cache whenever any row is updated.) Hence you get a better hit-rate with memcached. Perhaps it is also simply easier to tune memcached than most db memory caches. I benched "retrieve data and instantiate object" on a couple of different, unloaded, systems and a simple select-and-instantiate-from-mysql was a bit faster than the memcached equivalent. I didn't measure CPU usage server-side though, so under load things might be different.

tx 19y ago
I agree, in-memory hash table controlled manually by the application has a million ways to beat any SQL-server caching. What I am saying is that I suspect that memcached is way overused by people who don't know much about SQL. I am not posing like a DB snob, in fact my skills are fairly modest, but even I know that query caching is just one of the many caches SQL servers employ, and well designed servers easily service thousand+ of requests per second. And that's just one instnace. Very very very few web sites ever reach such loads. In theory memcached should be more like a very niche product for such rare sites, yet it appears that everybody is using it. I am against it because it increases the complexity. Memcached deployment and cache control become two more things to get right. That's all.

brianr 19y ago

The next time you're designing the backend for a high-traffic site, I think you should give it another look. As jbert pointed out, the MySQL query cache is emptied every time you make any change to the table, making it pretty useless unless you only ever do selects. And even for the selects, wouldn't you rather select by key from a hashtable in O(1) than select from a btree index in O(log n) at best?

nostrademons 19y ago

Brad Fitzpatrick addressed that when he released the initial memcached - LiveJournal had spent about 2-3 years fiddling with MySQL caches to get decent performance. They even took out one of those MySQL support contracts and had a MySQL engineer in to troubleshoot their performance problems. The bottom line was that yes, DBs should cache things - but they don't. The main issue was as someone else mentioned, the query cache is flushed whenever the table's written to, which makes it essentially useless on a multi-user website. Also, memcached distributes the cache itself across multiple machines, which makes a huge difference to cache hit rates. When you have a local query or app cache in a multi-server setup, you end up with each cache storing the same data, so the size of the cache is limited by the amount of RAM you have in the machine. If you distribute the whole cache, you're limited by the amount of RAM in all machines, which means almost every request can hit the cache. Hence you have architectures like FaceBook's 3 TB memcached setup.