Poor web serving performance

Cal Henderson calh at yahoo-inc.com
Thu Feb 1 20:49:58 UTC 2007

Brad Fitzpatrick <brad at danga.com> wrote:
: And the IO::AIO test suite passes?  (I assume, since you said the
: Linux::AIO one failed...)

yes - passes 100%

: Definitely looks like it's not working.  I wonder if the tests 
: aggressive enough... can you tell if they exercise the set_minimum()
: function at all and verify somehow that it works?  (counting
: threads/processes, or testing max outstanding AIOs... though the
: latter seems hard without being able to fake and slow down the
: filesystem...)

it uses it, but doesn't check for threads actually being spawned. when 
i run perlbal using linuxthreads i definately see multiple threads 
(even if not the correct count). the IO::AIO notes indicate that it no 
longer spawns the minimum number of threads at startup:

  IO::AIO starts threads only on demand, when an AIO request
  is queued and no free thread exists. Please note that
  queueing up a hundred requests can create demand for a
  hundred threads, even if it turns out that everything is in
  the cache and could have been processed faster by a single

but that shouldn't mean that it never reaches its peak 'min' number. 
not sure what's up with that.

using aio channels tells me that i definately have multiple tasks 
queued up:

chan-filer6 ctr_queued 0
chan-filer6 cur_running 312
chan-filer6 ctr_total 5554
chan-filer6 cur_queued 0
chan-filer7 ctr_queued 0
chan-filer7 cur_running 185
chan-filer7 ctr_total 3530
chan-filer7 cur_queued 0

but that doesn't say how many of them are being executed in parallel - 
just that alot are queued. i'm probably being dense, but i can't 
figure out a reasonable test to see if async stuff is really happening 
in parallel.

argh - i just noticed that perlbal is spiking to 99.9% CPU when i 
throw this traffic at it. is that to be expected if it's spinning 
waiting for aio requests to complete, or does that indicate that i'm 
spending all my time in aio callbacks? (running a plain vanilla 
web_server backend instead of my custom one gives the same results - 
so it doesn't appear to be time spent inside my plugin).

some strace's for comparisons - when i overload perlbal and requests 
start failing:

% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 39.91    0.638100          17     37852           futex
 16.59    0.265201           7     38693           epoll_ctl
  6.11    0.097642           9     11453      1753 close
  5.04    0.080565           4     19610           fcntl64
  4.44    0.070971          10      7385      1258 read

and when i send a lower request rate and nothing fails:

% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 50.33    1.041618          83     12622           epoll_wait
 21.76    0.450431          21     21690           futex
  5.04    0.104227           4     29300           time
  3.94    0.081629           4     18520           epoll_ctl
  3.45    0.071367          22      3232           sendfile


More information about the perlbal mailing list