4 ms·
you might as well just throw that RAM at the DB. With any sane DBMS this will result in the same performance improvement. That is obviously false. A memcache
by neilc 17y ago
you might as well just throw that RAM at the DB. With any sane DBMS this will result in the same performance improvement.
That is obviously false.
A memcache hit is much cheaper than a DBMS query, even if the DBMS query is accessing data that resides in the DB's buffer cache. If the DB query we're comparing against memcache is a trivial one (a single b-tree lookup), a memcache lookup is still faster; if the DB query is at all non-trivial, the memcache performance advantage is larger.
- russss 17y agoIn my experience, any differences between simple key/value lookups from Memcache and those from cache in a decent DB are easily lost in the network round-trip noise (i.e. solidly sub-millisecond). (of course more complex queries will be slower, but I covered that in my second point)
- vicaya 17y agoMemcached with UDP get can handle 400k gets per second (from a facebook engineering note earlier this year) on a single commodity server. Which "decent" DB can even approach this even for simple queries? A cache server and DB server simply have different performance priorities. Memcached makes a lot of sense for caching application specific fragments that has application specific expiration policies. Regarding your 2nd point, latency != 1/throughput when you have parallel queries.