Здравствуйте, 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
>
> вот оно как раз работает почти так как вы написали.
Ммм.. действительно. согласен. Прошу прощения. Я был введен в заблуждение
логами. В
них явно видно, как треды переплетаются. А я был уверен, что браузер
работает всегда на кип алайв с одним соединением. Это означает, что браузер,
посылал реквесты на разных соединениях... Т.е. схема была такая:
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@xxxxxxxxxx
