Wouldn&#39;t setting your proxy timeouts low solve this scenario?&nbsp; If there is an application server with poor performance, it will be marked as failed and nginx will divert requests to your other 10/100/1000 servers.<br><br>
&gt;j.<br><br><div class="gmail_quote">On Tue, May 6, 2008 at 10:20 AM, BJ Clark &lt;<a href="mailto:bjclark@scidept.com">bjclark@scidept.com</a>&gt; wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Kiril,<br>
<br>
You would think that would be the case, but it&#39;s not.<br>
EC2 is actually only useful in a sense that you can bring online &quot;n&quot; number of servers at any time, and take them offline at any time. You can use 1 server one day, 100 servers the next day, 1000 servers 3 hours later, and be back down to 1 server an hour after that.<br>

<br>
The actual performance of said servers can definitely fluctuate.<br>
<br>
BJ Clark<br>
<br>
On May 6, 2008, at 11:01 AM, Kiril Angov wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Isn&#39;t the point of using Amazon EC2 exactly that you get guarantee<br>
that your virtual machine will not be affected by normal problems<br>
related to hosting it on a single machine. I mean they say that they<br>
have a copy of your virtual machine on more than on server on maybe<br>
more than one location. I may be wrong here but from what I have read,<br>
you should not worry about your instance shutting down or slowing down<br>
drastically because what happens if I only have one instance and I<br>
reply on that?<br>
<br>
Kiril<br>
<br>
On Tue, May 6, 2008 at 12:44 PM, Rt Ibmer &lt;<a href="mailto:rtibmx@yahoo.com" target="_blank">rtibmx@yahoo.com</a>&gt; wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Thank you. These are excellent points. In my case all upstream servers share the same responsibility for the types of requests that are served. I guess I am looking at &#39;fair&#39; more as a way to auto-tune the weighting based on the relative performance of each upstream.<br>

<br>
I am hosting within the Amazon EC2 network. Because of fluctuations in their virtualized environment and underlying systems, it is very possible to have &nbsp;some &nbsp; some backends performing poorly compared to others.<br>
<br>
For instance imagine a scenario where I have 3 virtualized servers running on EC2 that are running as my upstream boxes. &nbsp;These three servers may actually be (and are most likely) on different physical servers. Now assume one of the EC2 servers has a &nbsp;problem that affects performance of all virtualized servers that it is hosting (perhaps it is networking related or perhaps it affects the speed of the machine).<br>

<br>
Now my upstream server on that troubled box will be running at a lot lower level of performance than my other upstreams, and this will show itself on the bottom line by much higher average ms total response time (time it takes to connect to upstream and get its full response) compared to the others.<br>

<br>
So in my case, I would like to use &#39;fair&#39; almost as a way to maximize site performance based on the health of the systems. &nbsp;Under heavy load I think &#39;fair&#39; would likely do this as requests for the slower box would get backed up and get reflected in the weighting. &nbsp;But under a light load probably not. &nbsp;So in that case &#39;fair&#39; would still route requests to a server that may take 500ms longer to reply just because there is no backlog.<br>

<br>
Anyway I realize that you did not write &#39;fair&#39; to solve this but just wanted to provide you with this feedback in case it spurs some ideas for how to expand it to cover this usage scenario. &nbsp;Thank you for this opportunity to provide the feedback and for your great contributions to the nginx project!<br>

<br>
<br>
<br>
<br>
<br>
 &nbsp; &nbsp; ____________________________________________________________________________________<br>
Be a better friend, newshound, and<br>
know-it-all with Yahoo! Mobile. &nbsp;Try it now. &nbsp;<a href="http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ" target="_blank">http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ</a><br>
<br>
<br>
<br>
</blockquote>
<br>
</blockquote>
<br>
<br>
</blockquote></div><br>