[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:


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