maxconn 1 in nginx
ezmobius at gmail.com
Thu Oct 9 20:23:08 MSD 2008
On Oct 9, 2008, at 8:48 AM, Grzegorz Nosek wrote:
> On Thu, Oct 09, 2008 at 04:28:37PM +0200, Benjamin wrote:
>> upstream_fair (with weight-mode=peak) will only limit the number of
>>> requests, causing Nginx to return 502 errors. It could be hacked to
>>> never return a hard error (I think), so if that's the only
>>> and the OP is willing to do some testing, I can implement that.
>> I do not know the weight-mode option. But it's the same principle.
>> of returning an error, haproxy created a queue of requests.
> @Igor: Will keeping pc->tries above zero at all times achieve this
> effect without eating lots of CPU? (pc is the ngx_peer_connection_t*
> passed to ->peer.get())
> @Michał: If Igor confirms, would you have a way to test the patched
> Best regards,
> Grzegorz Nosek
Yeah the haproxy behavior is what we really want for proxying to
rails apps. I'd like nginx to only feed a request to mongrels that are
not currently processing a request and any other requests will queue
in nginx in the efficient event loop and only dole out the requests
once a backend comes available or a timeout is hit.
This is the ideal load balancer situation for rails apps. I;ve been
putting haproxy in between nginx and mongrels to do this but I would
much rather see the fair balancer support this use case so I have less
items in the chain .
More information about the nginx