least_conn not working for me

[Phil Winfield]

Unsubscribe

On Wed, 23 Dec 2020, 21:43 Kenneth Brooks, <kenneth.s.brooks at gmail.com>
wrote:

> Thanks for the detailed response and taking the time to show some test
> examples.
>
> We did think that perhaps it was buffering.
> However, in our case, the "large" request is gigs in size, so there is no
> way that it is buffering that whole thing. I think our buffers are pretty
> small.
> Unless there is some absolute black magic that will buffer what it can,
> close the upstream, then open it again to ask for more of that file. :)
>
> I'm going to try what Peter suggested and check the netstat to at least
> confirm whether it is actually connected to the upstream still.
> Worst case I'll then simulate the same on our end with the limit_rate.
>
>
> On Wed, Dec 23, 2020 at 4:26 PM Maxim Dounin <mdounin at mdounin.ru> wrote:
>
>> Hello!
>>
>> On Wed, Dec 23, 2020 at 12:36:16PM -0500, kenneth.s.brooks wrote:
>>
>> > Thanks for the response.
>> >
>> > I understand what you are saying about the worker processes. We have
>> only a
>> > single worker process.
>> >
>> > I have 2 upstream servers.
>> >
>> > To validate:
>> > I am sending a request for a LARGE file. I see it hit server1. Server1
>> is
>> > now serving that request for the next couple of minutes.
>>
>> Note that the fact that server1 is actually serving the request
>> needs some additional verification.  As a web accelerator nginx
>> normally ensures that upstream servers are free to serve additional
>> requests as soon as possible, so if the limiting factor is the
>> client speed rather than connection between nginx and the upstream
>> server, nginx will happily buffer the response and will serve it
>> to the client itself.  And there will be no active connections to
>> server1, so least_conn will behave much like round-robin.
>>
>> > I send a request for a very tiny file. I see it hit server2. It finishes
>> > (server1 is still processing request #1)
>> > I send a request for a very tiny file. I see it hit server1 (even tho
>> it is
>> > still serving request #1 and server2 is not serving anything)
>> >
>> > I repeat that over and over, and I'll see all the subsequent requests
>> being
>> > routed to server1, then 2, then 1 then 2.
>> > If I submit another LARGE file request, if the last request went to
>> server2,
>> > then now I have 2 LARGE file requests being served by server1.
>> >
>> > If I submit more requests, they all continue to be equally distributed
>> to
>> > server1 and server2 (even though server1 has 2 active things it is
>> > serving).
>>
>> This behaviour corresponds to no active connections to server1, as
>> might happen if the file is not large enough and instead buffered
>> by nginx.
>>
>> > Is there some sort of a 'fudge factor' or threshold? That there has to
>> be n
>> > number of requests that one server is handling more than another
>> server?  I
>> > wouldn't think so, but I'm at a loss.
>>
>> No, nothing like this.
>>
>> Just in case, here is a simple configuration which demonstrates
>> how least_conn works (by using limit_rate to slow down responses
>> of one of the upstream servers):
>>
>>     upstream u {
>>         server 127.0.0.1:8081;
>>         server 127.0.0.1:8082;
>>         least_conn;
>>     }
>>
>>     server {
>>         listen 8080;
>>
>>         location / {
>>             proxy_pass http://u;
>>         }
>>     }
>>
>>     server {
>>         listen 8081;
>>         limit_rate 10;
>>         return 200 "slow\n";
>>     }
>>
>>     server {
>>         listen 8082;
>>         return 200 "fast\n";
>>     }
>>
>> And a test:
>>
>> $ for i in 1 2 3 4; do curl -q http://127.0.0.1:8080/ & sleep 0.1; done;
>> sleep 15
>> fast
>> fast
>> fast
>> slow
>> [1]   Done                    curl -q http://127.0.0.1:8080/
>> [2]   Done                    curl -q http://127.0.0.1:8080/
>> [3]   Done                    curl -q http://127.0.0.1:8080/
>> [4]   Done                    curl -q http://127.0.0.1:8080/
>>
>> Note that requests are started with some delay ("sleep 0.1") to
>> make sure fast backend will be able to respond before the next
>> request starts.  Note that only one of the requests is routed to
>> the slow backed - all other requests are routed to the fast
>> one.  That is, least_conn works as expected.
>>
>> --
>> Maxim Dounin
>> http://mdounin.ru/
>> _______________________________________________
>> nginx mailing list
>> nginx at nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx
>>
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20201223/02ada46c/attachment.htm>