[Mongrel] random cpu spikes, EBADF errors
rob at robmela.com
Mon Oct 29 21:20:12 EDT 2007
Already covered in this thread:
Delaying the accept() would be more helpful for load balancers which,
after a timeout for connect, cycle to another load balancer in the
pool. Failing that, a 503 would be reasonable, and it offers a hint to
users as to what's really happening. The open/close does not.
According to the http/1.1 spec the 503 and refuse-to-accept are both
10.5.4. 503 Service Unavailable
The server is currently unable to handle the request due to a
temporary overloading or maintenance of the server. The implication
is that this is a temporary condition which will be alleviated after
some delay. If known, the length of the delay MAY be indicated in a
Retry-After header. If no Retry-After is given, the client SHOULD
handle the response as it would for a 500 response.
Note: The existence of the 503 status code does not imply that a
server must use it when becoming overloaded. Some servers may
wish to simply refuse the connection.
Anyhow, I suggested one means for doing that in a previous thread (
entitled num_threads or accept/close or sth like that )
Clifford Heath wrote:
> Surely it's preferable to just delay the accept() until there's a
> thread to
> assign it to? That way the client sees a slow connection-establishment
> and can draw their own conclusions, including deciding how long to
> wait or whether to retry.
> Clifford Heath, Data Constellation.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 116 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20071029/0d1dce2c/attachment.vcf
More information about the Mongrel-users