Last time I looked at the memached code, it was clearly single threaded, relying on libevent to deliver kick-ass polling performance. This is all well and good, but there is still only a single thread to handle the requests (quick sidebar, never ever cross the beams and cause memcached to swap.) So I would suspect that you would get a performance boost on your way up to running 20 concurrent threads pulling data out, but that it will cap at some point and stay there.

MySQL on the other hand is multi-threaded (duh!) and so will handle running 20 concurrent threads pulling data out in a more graceful fashion.

At its most basic if the data in already in memory on the machine, pulling it out using memcached or MySQL should not make one whit of difference. Where things will diverge (broadly) is with disc access (a well tuned RDBMS should be CPU bound anyway) and with concurrency.

I also ran some psycho tests on memcached such as putting lots and lots of small 8-16 byte objects in there and found that I could only use about 10% of the memory I allocated to memcached before stuff started being aged out, something to do with slab allocation.

I think the type of situation where memcached is best is exactly what it was designed for: when the database design is not clean, and complex queries (or sets of queries) are require as part of page load. In that case, with data that can be somewhat stale, you can off-load the servers a bit by caching the final results of those queries in memcached.

In defense of memcached, it was designed before massive sharding across many commodity servers became available to the masses ;)