httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Holsman <>
Subject prefork Vs Threaded -- Updated -- and Other Performance Notes
Date Mon, 12 Mar 2001 17:53:43 GMT
A fortnight ago, I wrote saying that the threaded performance was
having problems with the malloc, and mutexes.

I re-ran the tests and found that problem goes away (and generates less
Brian also found some other areas which may be improved.


Ian Holsman wrote:

 > I just re-ran the threaded2.0, using the latest CVS release.
 > I am now getting simmilar results to the pre-fork (330/sec)
 > with a load avg of ~3.5 compared to ~5.5 with the fork.

Thanks for the good news!  I started up this threaded version
on web3 and measured a system call profile with truss while
stressing the httpd with a ab (20 concurrent requests for
index.html).  The full system call profile is at the end
of this message.  (Feel free to forward this on to the
Apache new-httpd list if you want.)

In the build that we looked at on Feb 28, 53% of the total
system call time was in thread synchronization operations.
In this latest build, the lwp_* calls comprise 36% of the
total system call time.  So the lock management has become
a lot more efficient, but there's still a lot of performance
to be gained if it can be reduced further.

Some other performance issues that I've noticed:
  0. It's using read rather than mmap to get the content
    from the files being delivered.  Is this just a config
  1. On a request that results in a 304, the httpd does a
    gratuitous open/close of the requested file after stat'ing it.
  2. There's also an extra read on the request socket just
    before the httpd sends the response, and another after
    the logger runs; both of these fail with EAGAIN.  (I saw
    this with an HTTP/1.1 client that supports keepalives, so
    the last failed read was followed by a poll to wait for
    the next request on the socket.)
  3. The amount of time spent reading/writing socket options
    after the accept is surprisingly large.  (This time shows
    up under getsockopt, setsockopt, getsockname, and fstat64
    in the system call profile.)


syscall      seconds   calls  errors
read           23.36   25675   3065
write          17.87   19379
open            3.12    3251
close           3.64    6464
brk              .02     120
stat            3.34    3232
fcntl          11.92   12942
poll            5.07    6296
sigaction        .00       1
mmap             .00      19
mprotect         .01      19
writev          2.93    3231
lwp_sema_wai    1.67    2172
lwp_sema_pos    1.89    2172
lwp_create       .00      38
lwp_continue     .08      19
lwp_mutex_un   29.22   32409
lwp_mutex_lo   22.69   23457
lwp_cond_wai     .00       1
lwp_cond_sig     .00       1
lwp_schedctl     .00      19
signotifywai     .06      19
lwp_sigredir     .00      19
fstat64         5.68    6470
accept          2.41    3237
shutdown        4.00    3228
getsockname     2.32    3236
getsockopt      5.27    6470
setsockopt      6.66    6471
               ----     ---    ---
sys totals:   153.23  170067   3065
usr time:      11.79
elapsed:       83.09

View raw message