# Dynamic Upstream Provider List

**URL:** <https://www.ruby-forum.com/t/dynamic-upstream-provider-list/189417>\
**Category:** NGINX\
**Created:** [May 31, 2010, 5:35pm UTC](https://www.ruby-forum.com/t/dynamic-upstream-provider-list/189417 "2010-05-31T17:35:35Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![rovar](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/7cd45c/32.png) [@rovar](https://www.ruby-forum.com/u/rovar)\
**Post date:** [May 31, 2010, 5:35pm UTC](https://www.ruby-forum.com/t/dynamic-upstream-provider-list/189417/1 "2010-05-31T17:35:35Z")

</div>

I am working on a load balancing system where the upstream providers  
need to change at runtime. The available peer group will be routed  
either by a hash, or by round robin, but the size of the peer group  
might change between any request.

The easy way seems to be to bypass the upstream http functionality  
altogether and simply return the appropriate peer from the callback in  
r-\>upstream-\>peer.get

Will this work?  
Does something else already do this?  
If not, what is a more idiomatic way to write this module?

Posted at Nginx Forum:

> **[Dynamic Upstream Provider List](https://forum.nginx.org/read.php?2,92715,92715#msg-92715)**
>
> I am working on a load balancing system where the upstream providers need to change at runtime. The available peer group will be routed either by a hash, or by round robin, but the size of the peer group might change between any request. The easy way...

---

<div class="post-metadata">

**Author:** ![rovar](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/7cd45c/32.png) [@rovar](https://www.ruby-forum.com/u/rovar)\
**Post date:** [May 31, 2010, 6:11pm UTC](https://www.ruby-forum.com/t/dynamic-upstream-provider-list/189417/2 "2010-05-31T18:11:17Z")

</div>

I do this by overwriting a conf included file and gracefully restarting,  
how often are you expecting this to change?

---

<div class="post-metadata">

**Author:** ![rovar](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/7cd45c/32.png) [@rovar](https://www.ruby-forum.com/u/rovar)\
**Post date:** [May 31, 2010, 6:22pm UTC](https://www.ruby-forum.com/t/dynamic-upstream-provider-list/189417/3 "2010-05-31T18:22:24Z")

</div>

Hi,

> I am working on a load balancing system where the upstream providers need  
> to change at runtime. The available peer group will be routed either by a  
> hash, or by round robin, but the size of the peer group might change  
> between any request.

Do you really need this list to be dynamic? Maybe static list of  
backends  
that are dynamically marked as either “up” or “down” is good enough? If  
so,  
please take a look at ngx\_supervisord [1] (you will probably want to use  
it  
with “supervisord none;” setting). You can also use it together with  
health-check module to automatically mark failed backends as “down”.

[1] [FRiCKLE Labs / nginx / ngx\_supervisord](http://labs.frickle.com/nginx_ngx_supervisord/)  
[2] [GitHub - cep21/healthcheck\_nginx\_upstreams: Health checks upstreams for nginx · GitHub](http://github.com/cep21/healthcheck_nginx_upstreams)

Best regards,  
Piotr S. \< [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) \>

---

<div class="post-metadata">

**Author:** ![rovar](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/7cd45c/32.png) [@rovar](https://www.ruby-forum.com/u/rovar)\
**Post date:** [June 1, 2010, 4:41am UTC](https://www.ruby-forum.com/t/dynamic-upstream-provider-list/189417/4 "2010-06-01T04:41:44Z")

</div>

The list will be very dynamic, as in new, previous unknown items should  
be able to be added at runtime. I’ll thank you both for your suggestions  
and will investigate them. Supervisord looks neat for a number of  
reasons outside of the scope of this 🙂

Posted at Nginx Forum:

> **[Re: Dynamic Upstream Provider List](https://forum.nginx.org/read.php?2,92715,92949#msg-92949)**
>
> I am working on a load balancing system where the upstream providers need to change at runtime. The available peer group will be routed either by a hash, or by round robin, but the size of the peer group might change between any request. The easy way...
