[jifty-devel] Scaling up Net::Server::Prefork
Jesse Vincent
jesse at bestpractical.com
Wed Jul 4 15:14:07 EDT 2007
It might be interesting to scale up jifty's preforking standalone
server someday. I ran across this comment from Justin Mason today:
http://brad.livejournal.com/2329271.html?thread=13756599#t13756599
SA preforking
We actually moved to the model you described in SpamAssassin 3.1.0.
Previously we did the "preforked pool of servers all doing blocking
accept" thing, but that didn't allow scaling of the pool size to deal
with demand. So instead, I sat down with some of the Apache httpd
guys, went over how Apache 2 preforking and pool scaling works, and
came up with a pure-perl implementation. That's what we now use.
Here's the key bits:
* Parent shares the accept fd with kids, and socketpairs between
parent and each child, as you describe.
* Parent process maintains pool size to always include N idle
children, scales up/down children as the number of idle kids
increases/decreases with load (Apache-style preforking).
* Parent selects on the accept socket.
* When a new incoming connection appears, it picks the lowest-
numbered idle child and orders it to accept.
* The children report back state ("idle", "busy") over the
socketpair as they become idle, or are about to accept a connection.
* The child waits for orders from the parent. If the parent
orders a child to accept, it reports itself as "busy", accepts the
conn, deals with it, then reports itself as "idle".
Note, btw, the use of lowest-numbered idle child; that's an easy way
to keep the same kid processes "hot". Apache httpd does the same
thing (iirc). Since the communication is therefore generally between
processes that are swapped in, and no swapping is required, this was
a key benefit that makes this a little faster than the traditional
"preforked blocking accept" style, at least for most casual users.
(Of course a well monitored setup where the admin is careful to
ensure swap is never hit would probably be more efficient using the
traditional "blocking accept" model, so we still offer that; but most
people aren't that careful.)
We had a nasty bug that went on for a while on some loaded servers,
but eventually we got it fixed (deleting an entry from a hash in a
SIGCHLD signal handler is unsafe, doh!). Nowadays it seems to be
quite stable.
The code's in our SVN: lib/Mail/SpamAssassin/SpamdForkScaling.pm and
lib/Mail/SpamAssassin/SubProcBackChannel.pm .
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.bestpractical.com/pipermail/jifty-devel/attachments/20070704/5cd16453/PGP.pgp
More information about the jifty-devel
mailing list