maxconn 1 in nginx

[Benjamin]

It's definitly not the same thing. Nginx hasn't got yet the maxconn
parameter.

From haproxy documentation :
"It's a per-server 'maxconn', associated with a per-server and a per-proxy
queue. This transforms haproxy into a request buffer between the thousands
of clients and the few servers. On many circumstances, lowering the maxconn
value will increase the server's performance and decrease the overall
response times because the servers will be less congested."


On Thu, Oct 9, 2008 at 11:38 AM, Grzegorz Nosek <grzegorz.nosek at gmail.com>wrote:

> On Thu, Oct 09, 2008 at 11:28:54AM +0200, Michał Jaszczyk wrote:
> > Hey,
> >
> > I'm creating a pretty big HTTP RESTful API that is organized in the
> > following way: There are many different functionalities in the API.
> > Different functionalities are served by different backend machines and
> > each functionality is another smaller RESTful API. In front of all
> > that mess I'd like to put Nginx. The idea is that Nginx would check
> > the requested path and dispatch the request to proper backend, like
> > this:
> > - paths beginning with /some_path/... shoud be dispatched to
> > backend-1.mydomain.com,
> > - paths beginning with /other_path/.. shoud be dispatched do
> > backend-2.mydomain.com,
> > - etc.
> >
> > So far everything can be done in Nginx easily. But: backends are
> > written in Ruby on Rails and we all know how good HAProxy's "maxconn
> > 1" is for Rails. How can I achieve the same in Nginx?
>
> If I'm right about what maxconn=1 does, grab a fresh copy of upstream_fair
> and set it up like this:
>
> upstream foo {
>  server 10.0.0.1:80 weight=1;
>  server 10.0.0.2:80 weight=1;
>  # etc.
>
>  fair weight-mode=peak;
> }
>
> Weight=1 is the default but it's nice to make it explicit in this case.
>
> ...but give it a try with simple 'fair' (without parameters) too.
>
> Best regards,
>  Grzegorz Nosek
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nginx.org/pipermail/nginx/attachments/20081009/ea71912e/attachment.html>