Is memcached really faster than MySQL on very simple query?

[Paul T]

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

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

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

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' ?
</aside>

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

Rgds.Paul.

> -Dormando
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com