Re: cvs commit: httpd-2.0/server/mpm/experimental/threadpool config5.m4 Makefile.in mpm_default.h mpm.h pod.c pod.h threadpool.c

[Brian Pane <bp...@pacbell.net>]

This threadpool MPM code seems to work reasonably well on Linux
and Solaris.  For anybody who has time to contribute, here are
the areas where I could use some help:

  * Performance testing on other multiprocessor platforms

  * General testing and code review (especially of the
    shutdown/restart code)

  * Testing/debugging of the restart code

Thanks,
--Brian

P.S.: While we're on the subject of next-generation MPMs,
is anyone seriously thinking about (or already developing)
an event-loop MPM?


brianp@apache.org wrote:

>brianp      02/04/16 16:37:06
>
>  Added:       server/mpm/experimental/threadpool config5.m4 Makefile.in
>                        mpm_default.h mpm.h pod.c pod.h threadpool.c
>  Log:
>  Another experimental MPM derived from worker:
>  
>  The threadpool MPM implements Aaron Bannert's "time-space tradeoff"
>  design managing idle workers.  Rather than putting accepted connections
>  into a queue, the threadpool MPM keeps idle worker threads in a stack.
>  Its dedicated listener thread retrieves an idle worker from the stack
>  before accepting a connection.  If there are no idle workers, the
>  listener blocks until a worker becomes available before doing an accept.
>  
>  In many ways, threadpool is also a variant of leader/follower.  They
>  both maintain a stack of idle threads.  The difference is that threadpool
>  has a dedicated listener thread, and leader/follower rotates the listening
>  responsibility among its worker threads.  In my initial testing, the
>  leader/follower MPM performs very well on multiprocessor Solaris 8 when
>  listening on a single port, but poorly when listening on multiple ports.
>  (I don't know why this is happening.  What I've found so far is that
>  when you add a poll on the listen socket(s) before the accept in the
>  leader/follower MPM, all the socket-related syscalls in the httpd get
>  slower.  My hypothesis is that the thread scheduler is making an optimal
>  decision about where (on what CPU) to run the newly awakened thread if
>  its first syscall is an accept, and a nonoptimal decision if its first
>  syscall is a poll.)  The threadpool MPM performs better with multiple
>  listener ports, and in my testing so far it looks competitive with
>  leader/follower when running with a single listener.
>