Steve Midgley wrote:
Hi,
I thought I'd chime in as a Windows developer. I'm running Windows in
development mode and deploying to Linux (Ezra's rig at EngineYard
actually).
If this idea actually works, it's super appealing for me as a simple
solution to the "slow returning mongrel" load balancing challenge.
(i.e. the problems where mongrels are loaded up with requests
irrespective of their availability, leaving some mongrels idle and some
overloaded.)
I found out why it works on Linux 2.6.20. In net/ipv4/tcp_ipv4.c
accept is mapped to inet_csk_accept in net/ipv4/inet_connection_sock.c.
That csk accept calls inet_csk_wait_for_connect to wait for a
connection. That wait for connect function locks the socket so that if
multiple processes are calling accept() on that socket, only one process
at a time will be awaken when a connection request arrives.
This wil require some change in Mongrel's request loop. Mongrel
currently reenters accept even if it's got a worker locking Rails. If
Mongrels in the pool are calling accept while still locking Rals then
we're right back to square one, request queing. Mongrel would need to
either poll for worker list length == 0 before calling accept, or have a
"single-worker" mode in which it joins a worker thread as soon as it's
started, and only calls accept() after returning from that join.
begin:vcard
fn:Robert Mela
n:Mela;Robert
email;internet:[EMAIL PROTECTED]
x-mozilla-html:FALSE
version:2.1
end:vcard
_______________________________________________
Mongrel-users mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/mongrel-users
