memcache performance

[Eric Hodel]

On Jan 25, 2006, at 2:13 PM, Pavel Kolla wrote:

> Wednesday, January 25, 2006, 2:25:32 PM, you wrote:
>
>> On Jan 25, 2006, at 11:15 AM, Pavel Kolla wrote:
>>
>>> 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.
>
> well  if i see queries that are hanging are the ones that use same  
> table as  authentication  data is stored in - it tells me that it  
> might be the one with the problem.

Right, "might".

It might also be no problem at all.  In order to be most effective at  
increasing the speed of your app you should know exactly where it is  
slow.

>> 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.
> any good tools you can recommend (which can profile something  
> preferably
> in real conditions on production or test server)

For PHP?  No idea.

For Rails (Ruby) I wrote action_profiler.

>>>> 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.
>
> my  point is if it's 50ms and it does updated somewhere in it there  
> is a
> good chance that if i have more that 20 of these - some might wait  
> up to
> close to a 1 sec because updates/select. Idea to use memcache was  
> mostly
> due  to  desire  to remove most frequent update/selects so they  
> dont run
> into locking issues.

"there is a good chance" "might wait"

A good optimization plan is grounded on real data rather than  
possibilities that may or may not be true.  I'm sure you want to  
spend as little time as possible making your application as fast as  
possible, that way you can spend more time at the bar (or wherever  
you go after work is over).

How often do you get 19 additional requests within the 50 ms the  
first request takes?

When you do get 20 operations does it really end up taking 1000 ms to  
complete all the operations, or does the DB do magic tricks and only  
give a minor performance degradation?

If you average 30ms of DB work for a request, but it takes your app  
250ms total from the time it receives a request to the time it  
completes it, then memcached reducing your average DB work times from  
30ms to 5ms won't make a noticeable difference on processing times.

This is where a profiler or other benchmarking comes in, instead of  
guessing your way to speed you can find out exactly where to focus  
your efforts.

This way you can spend more time relaxing at the bar with a beer in  
hand rather than chasing after things you hope will solve the problem.

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

http://trackmap.robotcoop.com