Is memcached really faster than MySQL on very simple query?
pault12345 at yahoo.com
Fri Jul 14 02:24:14 UTC 2006
> > 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
> > considerable portion of your script business logic
> Not really sure what you meant by the beta component
There is a C++ application server (20-40K hps e t.c.)
inspired by memcached (and apache modules, and
S-expressions, and some other things)
The server is work in progress, currently it is in
beta and supposed to go open source (most likely -
LGPL) by the end of this summer. The legal issues are
being worked out and today I purchased the domain for
If you want early access to the source code of a beta
(early August, I think) - please email me offlist.
> 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.
<aside> Perhaps what you actually want is a smart load
balancing component in front of several dumb (but
ultra fast - think TUX) 'image serving nodes' ?
In any case - if your scenario implies agressive
marshalling of small values to/from memcached from/to
scripting language - the benchmarks of the app server
that I'm pitching show that it can serve small values
to PHP as fast as it is serving them to plain C client
- 20-40K hps via TCP.
>From what I saw on this list, Facebook had to patch
memcached to switch to UDP to handle 20K hps (but I
dunno what are their 'values'. I assume they are
marshalling the 'typical' memcached payload 10-50K(?)
My 20-40K are for tiny payload < 512 bytes. ( It is
also funny to talk in this kind of numbers ignoring
the hardware and the OS version, but still ... better
than having no numbers at all, I guess. )
I think that Facebook did 'the righ thing' going UDP ,
but there are some other reasons to stay with TCP ...
I would prefer to jam this thread to stay on topic.
> The rest of
> our cases for
> memcached are usually caching very slow queries for
> long periods of time.
In case the result sets that you store in memcached
are 'average' 5-50K - it is hard to beat memcached
numbers, the network will eat up all the savings.
(But again, there are many other factors to consider -
centralized versus distributed e t.c. e t.c.)
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
More information about the memcached