# "first" load balancing

**URL:** <https://www.ruby-forum.com/t/first-load-balancing/229334>\
**Category:** NGINX\
**Created:** [January 4, 2013, 6:34pm UTC](https://www.ruby-forum.com/t/first-load-balancing/229334 "2013-01-04T18:34:03Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![KT\_Walrus](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/k/a87d85/32.png) [@KT\_Walrus](https://www.ruby-forum.com/u/KT_Walrus)\
**Post date:** [January 4, 2013, 6:34pm UTC](https://www.ruby-forum.com/t/first-load-balancing/229334/1 "2013-01-04T18:34:03Z")

</div>

The purpose of this message is to request a new feature be added to  
NGINX - “first” load balancing algorithm and MAXCONN setting for  
upstream servers.

I am setting up a new site that will require multiple upstream servers  
and load balancing. I plan to use ip\_hash load balancing on frontend  
servers to do simple load balancing to the backend servers. I would  
like to protect each backend server from becoming overloaded and  
possibly failing because of too many connections sent to it.

I plan on using haproxy to “guard” each backend server by using  
haproxy’s “first” load balancing and setting a MAXCONN for the localhost  
backend. If the maximum connections for the server is met, haproxy will  
send the request to the next server in the list. I also plan on using  
Amazon EC2 instances and this set up will not only protect each backend  
server from becoming overloaded, it allows me to “spin up” new backend  
servers if the last backend server is approaching MAXCONN. Similarly,  
if the last two backends in my server farm are not receiving any  
requests, I can “spin down” the last server (and save me money!!!).

Now, it seems to me I could remove haproxy from my server software stack  
if NGINX added support for “first” load balancing and MAXCONN setting  
for each upstream server. I think this should be relatively easy to  
support since I see NGINX already supports “least conn” load balancing.  
I guess this means that NGINX already knows how many connections it has  
open to an upstream server and could easily implement “first” and “max  
conn”.

Kevin