В ср, 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'е его поддержка со стороны
браузеров не изменилась (та же Опера + Файрвокс, выключенный по дефолту).
Про какой ИИ идет речь? Пришол запрос - отпроксировался, ответ держится в
буффере, пока до его отдачи не дойдет очередь, а бекенд, если запрос
отработал полностью - освобождается, иначе ждет пока его спросят об
остатке ответа, который не поместился в буффер.
А по поводу схемы балансировки по времени ответа очень хорошо сказал
на РИТе Олег Оболенский из Яндекса - "пятисотки отдаются офигенно быстро".
Не присутсвовал, из контекса не понимаю про какие пятисотки идет речь. И
не понимаю что за "балансировка по времени ответа" - я вообще-то имел
ввиду балансировку по текущей загруженности бекендов - по текущему
кол-ву запросов в обработке бекендом. А не балансировать по кол-ву
запросов вообще, как сейчас.
