memcache performance

Eric Hodel drbrain at segment7.net
Wed Jan 25 19:25:32 UTC 2006


On Jan 25, 2006, at 11:15 AM, Pavel Kolla wrote:

> Tuesday, January 24, 2006, 3:52:49 PM, you wrote:
>
>> How did you determine that memcached would really speed up your
>> processing?
> i assumed it should based on following concepts
> say test scenario is 200 encrypted requests per second
>
> In  case  if mysql is used:
>
> all  user  hit  same  table with 200 selects and 200 updates within  
> same
> second,  200 updates can not be executed concurrently with each  
> other or
> with  any  of  200  selects.  data  is not cache-able at mysql  
> level and
> probably going to sit in secondary level OS cache.

Maybe they cannot, but that doesn't mean they won't be fulfilled from  
the DB as fast as they could from memcached.

> In  case  if  memcache  is used updates and selects should be  
> running in
> parallel,  as  long  as  it's  not the same key, data stays in  
> memory at
> memcache level. (correct me if I'm wrong here)

I believe memcached uses libevent rather than threads.  MySQL uses  
threads, so takes advantage of multiple CPUs.

> I use mytop for monitoring while testing, it takes a snapshot of  
> queries
> run at some point of time. quite often i see multiple updates or  
> selects
> running  (meaning  waiting)  for  each  other  to finish  
> (authentication
> related  queries),  i consider that as sign, that authentication is  
> more
> or less of speedbump performance-wise.

Looking at mytop won't tell you that MySQL is your choke point, it  
will only tell you what MySQL is doing.

You should run a profiler on your code to determine where you spend  
most of your time.  If the database is your choke point you'll spend  
lots of time waiting for the database.  If it is not your choke point  
you'll spend your time elsewhere.

>> Was the DB really your choke point?  How long did the DB queries  
>> take?
> there  are  no  long  queries...  most  queries  are simple...  
> there are
> between  2  and 30 queries per request average is about 4, most  
> requests
> take between 10ms and 50ms, some rare ones go up to 200ms (real  
> numbers,
> averaged across day)

10 to 50 ms sounds like it is no slower than what you'd get from  
memcached.  It sounds like your choke point is not the database.

-- 
Eric Hodel - drbrain at segment7.net - http://segment7.net
This implementation is HODEL-HASH-9600 compliant

http://trackmap.robotcoop.com




More information about the memcached mailing list