Re[5]: keepalive от nginx к бакэнду. запрос фичи.

[sjsoft at newmail.ru]

Здравствуйте, Andrew.

Вы писали 13 июня 2006 г., 17:18:42:
snr>> Я  с вами полностью и категорично не согласен. Боюсь вы все-же поверхностно ознакомились с моей
snr>> проблемой.
> на  nginx  запросы  от бровсера по одному keepalive соединению
> приходят ПОСЛЕДОВАТЕЛЬНО, он их также
> ПОСЛЕДОВАТЕЛЬНО  посылает на backend. если бы nginx умел говорить с backend по keepalive то всего на
> всего не было бы лишних open/close между nginx и backend.

snr>> Юзеры посылают по 3 запроса, на одном keep-alive соединении
snr>> USER1<-ka-> NGINX <-cc-> BACKEND thread 1 (wrk with table 1)
snr>>      <-req->      <-cc-> BACKEND thread 2 (blocked on mutex table 1)
> это не правильно. req не пойдет (его бровсер не пошлет) пока не
> отработает первый и USER1 не получит
> свой  ответ.  то  что бровсер МОЖЕТ открывать несколько соединений (в том числе и keepalive) это уже
> другая  история.  то  что  вы  хотите  keepalive между nginx и
> backend не решает, а решает busy lock
> (которые есть в mod_accel) и которых пока нету в nginx.

> P.S. еще есть HTTP Pipelining
> http://www.mozilla.org/projects/netlib/http/pipelining-faq.html
> вот оно как раз работает почти так как вы написали.


Ммм.. действительно. согласен. Прошу прощения. Я был введен в заблуждение логами. В
них явно видно, как треды переплетаются. А я был уверен, что браузер
работает всегда на кип алайв с одним соединением. Это означает, что браузер,
посылал реквесты на разных соединениях... Т.е. схема была такая:
USER1<-cc-> NGINX <-cc-> BACKEND thread 1 (wrk with table 1)
USER1<-cc-> NGINX <-cc-> BACKEND thread 2 (wrk with table 1)
USER1<-cc-> NGINX <-cc-> BACKEND thread 3 (wrk with table 1)

Спасибо что разьяснили. Хм. однако.

Pipelined это не то, как я правильно понял, суть его в том, чтобы
не закрывать соединение и выдывать содержимое по степено, на основе
чего сделаны потоковые чаты.

Насчет Busy'lock. это совсем не то. Как я понял, он ставится на
конкретный URI. Чтобы скрипты, долго работающие не тормозили проц,
одновременно выполняясь.
  А мне требуется, запросы групировать по ip или
куку(лучше и то и то) и посылать их в очередь на keep-alive
соединение, которое было бы открыто для этого фронтендом до бакэнда
при получении первого запроса в групе. Получается, как будто,
запросы одно юзера, ставятся в очередь(и выполняются поочередно), в то
время как остальные соединения свободны для других юзеров.

вот. возможно это интересная идея?






-- 
С уважением,
 sjsoft                          mailto:sjsoft at newmail.ru