Brion Vibber wrote:
On Sun, 2003-09-21 at 18:29, E23 wrote:
>Example: n processes arrive at the same time. If the necessary CPU time
>for every process is t seconds, all processes will finish after t*n
>seconds in a concurrent system.
>
>If, on the other hand, the processes run completely serialized, one
>after another, the first process will finish after t seconds, the second
>one after 2*t seconds and so on up to n*t seconds for the n:th process.
>This gives an average running time of t*n/2 seconds, with a worst case
>time of t*n.
Your formulas work as long as the processes are not waiting for hardware
at any stage. The apache processes don't, significantly, so that's okay.
You wouldn't want to try this with the DB though.
My very naive quick testing shows that while there is
an improvement in
the median time when locking kicks in, there is no significant
difference in average (mean) response time; the shorter times for some
are paid for by a significant increase in the length and proportion of
slow responses for others.
See benchmark:
http://meta.wikipedia.org/wiki/Lock_response_times
http://meta.wikipedia.org/upload/1/1d/Lock-times.png
Of course, I could be doing something wrong, and this benchmark is very
very naive, making no attempt to work with different types of requests.
Could we mitigate the effect of slow queries blocking the server, by
allowing other threads to run once the lock times out? I'm thinking
something like this:
for ( $semIdx=0;
!wait_for_semaphore($semIdx) && $semIdx < 10;
$semIdx++ );
if ( $sem == 10 ) {
print "Sorry too much traffic\n";
} else {
do query
release_semaphore($semIdx);
}
-- Tim Starling
