> Ideally we would run this in an event loop
Anyone is welcome to take over maintenance of http::server::singlethreaded
and add apache/mp features to it, then there would be big monolithic
perl web-servers. Blocking in the request handlers would remain a problem,
but not anything that couldn't be solved with Socket::PassAccessRights and
a pool of external worker processes that are responsible for setting up
a fd for the new request, passing the fd back to the main program, then
doing whatever is needed to service the request.
I have set something similar up at my job, but it is not releasable
and not directly applicable to rejiggering singlethreaded into a better
more scalable mod_perl.
So here's the "three tier asynchronous model" (3TAM):
Main Select Loop
handles all connections from remote clients, including
relaying data from worker processes. Very fast data
can be served directly, anything that might block is
passed to an available worker.
Worker Process Pool
these processes generate and pass file descriptors
and then become handlers, by forking, or by passing
the other side of a socketpair to a handler
Handler Processes
these do blocking things, like groveling through twenty million
nonindexed database records, and report their findings
to their STDOUT, which happens to be a socketpair
that is read by the MSL.
The middle layer is there to protect the main loop from ever having
to fork().
To make a 3TAM system work like mod_perl, never mind the hooks
into the various apache request service stages, every long-running
perl script could be interpreted into one of serveral mp_like interpreters
at the handler layer, or even every mp script could become its own
small pool of processes waiting for activation. Some benchmarking
would need to be done WRT the optimum amount of code to have
in a long-lived perl interpreter instance.
mod_perl:
each apache thread includes a perl interpreter which has loaded
into it the entire mod_perl feature set of the web server, each in
its own name space. Pool size is managed by apache threads.
proposed 3TAM:
each 3TAM_perl script would be wrapped into a long-lived program
that lives in its own process pool of size greater than or equal to two,
which is capable of forking when the script is used heavily and
exiting when there are too many free ones. Pool size is managed
with a finer granularity: the individual script.
Crazy enough for you?
--
David L Nicol
This is the dawning of the age of asparagus
