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 .

Attachment: PGP.sig
Description: This is a digitally signed message part

_______________________________________________
jifty-devel mailing list
jifty-devel@lists.jifty.org
http://lists.jifty.org/cgi-bin/mailman/listinfo/jifty-devel

Reply via email to