Is memcached really faster than MySQL on very simple query?

[dormando]

>  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.

-Dormando