Is memcached really faster than MySQL on very simple query?

dormando dormando at
Thu Jul 13 20:44:04 UTC 2006

>  Absolutely. 
>  XS memcached client should (maybe significantly)
> improve the numbers for the case where:
>  1. cached values are tiny ( <2K )
>  2. you need to access the cache real fast from
> scripting language ( == memcached access consumes a
> considerable portion of your script business logic )
>  Seriosly, how many people use memcached with both 1
> and 2 in place? It would *not* be wise to use
> memcached for that case, actually. 

Not really sure what you meant by the beta component stuff?

We use 1+2 in part of our application. We run millions of images that 
get hit thousands of times per second (total, not each;), each load on 
the backend needs to check memcached for a set of mogstored paths (<2k), 
hit the tracker and cache if it does not exist, then jump back to perlbal.

We would get considerable latency benefits from having a *fast* 
asyncronous memcached client library that could be embedded directly 
into perlbal. Otherwise it's not that big a deal. In my current setup 
the backend is all PHP anyway...

For something like an image hosting service which needs some crazy 
distributed backend without paying a crazy licensing fee, 1+2 would be 
the bulk of their usage.

It's also a small percentage of the overall application, it just makes a 
difference when a user loads a page and the 15+ images on it load 
immediately instead of with visible lag. The rest of our cases for 
memcached are usually caching very slow queries for long periods of time.


More information about the memcached mailing list