drbrain at segment7.net
Wed Jan 25 22:29:08 UTC 2006
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
>> 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.
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
>> 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
> 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
>>> 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
> 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
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
More information about the memcached