3 ms·
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 e
by 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 agoI 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.