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. git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94672 13f79535-47bb-0310-9956-ffa450edef68
parent
89933fa9
Please register or sign in to comment