В ср, 14/11/2007 в 13:48 +0300, Igor Sysoev пишет: > On Wed, Nov 14, 2007 at 12:09:31PM +0200, MZ wrote: > > > В ср, 14/11/2007 в 10:12 +0300, Igor Sysoev пишет: > > > Persistent соединения с бэкендом планируются, но реализовать их на данный
> > > момент сложно, так как необходимо обрабатывать chunked ответы бэкенда. > > > Большого прироста производительности ожидать от этого не стоит, > > > за исключением случаев, когда бэкенд на виндах или джаве.
> > Не сказал бы что не стоит. Оверхед не только на установку и accept > > соединения (а чем больше очередь входящих соединений тем надо больше > > ресурсов на её обработку). Но и на поиск или инициализацию свободного
> > воркера куда можно было бы пробросить соединение, освобождение воркера > > после отдачи контента, ... - это все тоже работа, причем большая чем > > просто установка соединения. > > Это где происходит "поиск или инициализацию свободного воркера" ?
> В стандартном Апаче свободный воркер сам accept()ит соединение. > О какой работе по инициализации и освобожению идёт речь ? Ну ладно, с поиском воркера проблем нет - accept-ит тот кто первый забрал мютекс, но
инициализацию для нового соединения все равно какую-то провести надо, самому воркеру.
> > > Поддержка pipelined запросов к бэкенду существенно усложнит проксирование > > > и бессмысленна на данный момент - по умолчанию pipelining использует
> > > только Опера. Firefox нужно специально настраивать, а MSIE, по-моему, > > > не поддерживает вообще. > > А при чем тут использование pipeline браузером ? Мы ж pipeline к бекенду > > обсуждаем. Хотя обсуждать тут особо нечего - Anton Yuzhaninov
> > <citrin@xxxxxxxxx> привел пример, когда использование pipeline > > увеличивает задержку при неудачном стечении обстоятельств. > > А при том что,
> --------- > В случае пайплайнинга, ngnix будет проксировать каждый реквест в новом > соединении к бекенду? > --------- И что? Где-то требуется чтобы бекенд начинал обработку запроса строго после
обработки предыдущих в pipeline? Nginx постал запрос, бекенд обработал - где проблема? Единственная проблема что ответ придется придержать пока не отдадутся все ответы на предыдущие запросы. Зато не надо ждать пока
обработается первый запрос, чтобы приступить к обработке последующих запросов.
> > А вот если Опера присылает пачку pipelined-запросов, nginx их > > раскидывает по разным бекендам - это нормальная схема, только придется
> > держать в буфере ответы на более поздные запросы, пока не уйдут в > > pipeline ответы на все предыдущие запросы - fifo. Задо задержка > > получения ответов может значительно снизиться, за счет паралельной
> > генерации контента, но никогда не увеличится (разве что какой-то бекенд > > окажется перегружен, но тут надо менять текущю схему балансировки, я уже > > когда-то писал). > > nginx обрабатывает pipelining последовательно. И я не вижу никакого
> смысла добавлять в обработку pipelining'а искусственный интеллект - > за четыре года его существования в nginx'е его поддержка со стороны > браузеров не изменилась (та же Опера + Файрвокс, выключенный по дефолту).
Про какой ИИ идет речь? Пришол запрос - отпроксировался, ответ держится в буффере, пока до его отдачи не дойдет очередь, а бекенд, если запрос отработал полностью - освобождается, иначе ждет пока его спросят об
остатке ответа, который не поместился в буффер.
> А по поводу схемы балансировки по времени ответа очень хорошо сказал > на РИТе Олег Оболенский из Яндекса - "пятисотки отдаются офигенно быстро".
ошибки 5ХХ наверно
Не присутсвовал, из контекса не понимаю про какие пятисотки идет речь. И
не понимаю что за "балансировка по времени ответа" - я вообще-то имел ввиду балансировку по текущей загруженности бекендов - по текущему
как Вы узнаете загруженность бекенда? Cisco CSS в нгинх вкрячить?
кол-ву запросов в обработке бекендом. А не балансировать по кол-ву запросов вообще, как сейчас.
если только косвенно определить, сколько отдали запросов, сколько получили, разница и будет показателем примерной загруженности
