maxconn 1 in nginx

[Ezra Zygmuntowicz]

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  
>>> difference
>>> 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.  
>> Instead
>> of returning an error, haproxy created a queue of requests.
>
> Thanks.
>
> @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
> upstream_fair?
>
> Best regards,
> Grzegorz Nosek
>

Grzegorz-

	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 .

Cheers-
-Ezra