<br><br><div><span class="gmail_quote">14.11.07, <b class="gmail_sendername">MZ</b> &lt;<a href="mailto:zuborg@advancedhosters.com">zuborg@advancedhosters.com</a>&gt; написал(а):</span><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
В ср, 14/11/2007 в 13:48 +0300, Igor Sysoev пишет:<br>&gt; On Wed, Nov 14, 2007 at 12:09:31PM +0200, MZ wrote:<br>&gt;<br>&gt; &gt; В ср, 14/11/2007 в 10:12 +0300, Igor Sysoev пишет:<br>&gt; &gt; &gt; Persistent соединения с бэкендом планируются, но реализовать их на данный
<br>&gt; &gt; &gt; момент сложно, так как необходимо обрабатывать chunked ответы бэкенда.<br>&gt; &gt; &gt; Большого прироста производительности ожидать от этого не стоит,<br>&gt; &gt; &gt; за исключением случаев, когда бэкенд на виндах или джаве.
<br>&gt; &gt; Не сказал бы что не стоит. Оверхед не только на установку и accept<br>&gt; &gt; соединения (а чем больше очередь входящих соединений тем надо больше<br>&gt; &gt; ресурсов на её обработку). Но и на поиск или инициализацию свободного
<br>&gt; &gt; воркера куда можно было бы пробросить соединение, освобождение воркера<br>&gt; &gt; после отдачи контента, ... - это все тоже работа, причем большая чем<br>&gt; &gt; просто установка соединения.<br>&gt;<br>&gt; Это где происходит &quot;поиск или инициализацию свободного воркера&quot; ?
<br>&gt; В стандартном Апаче свободный воркер сам accept()ит соединение.<br>&gt; О какой работе по инициализации и освобожению идёт речь ?<br>Ну ладно, с поиском воркера проблем нет - accept-ит тот кто первый забрал мютекс, но
<br>инициализацию для нового соединения все равно какую-то провести надо, самому воркеру.<br><br>&gt; &gt; &gt; Поддержка pipelined запросов к бэкенду существенно усложнит проксирование<br>&gt; &gt; &gt; и бессмысленна на данный момент - по умолчанию pipelining использует
<br>&gt; &gt; &gt; только Опера. Firefox нужно специально настраивать, а MSIE, по-моему,<br>&gt; &gt; &gt; не поддерживает вообще.<br>&gt; &gt; А при чем тут использование pipeline браузером ? Мы ж pipeline к бекенду<br>&gt; &gt; обсуждаем. Хотя обсуждать тут особо нечего - Anton Yuzhaninov
<br>&gt; &gt; &lt;<a href="mailto:citrin@citrin.ru">citrin@citrin.ru</a>&gt; привел пример, когда использование pipeline<br>&gt; &gt; увеличивает задержку при неудачном стечении обстоятельств.<br>&gt;<br>&gt; А при том что,
<br>&gt; ---------<br>&gt; В случае пайплайнинга, ngnix будет проксировать каждый реквест в новом<br>&gt; соединении к бекенду?<br>&gt; ---------<br>И что? Где-то требуется чтобы бекенд начинал обработку запроса строго после
<br>обработки предыдущих в pipeline? Nginx постал запрос, бекенд обработал -<br>где проблема? Единственная проблема что ответ придется придержать пока<br>не отдадутся все ответы на предыдущие запросы. Зато не надо ждать пока
<br>обработается первый запрос, чтобы приступить к обработке последующих<br>запросов.<br><br>&gt; &gt; А вот если Опера присылает пачку pipelined-запросов, nginx их<br>&gt; &gt; раскидывает по разным бекендам - это нормальная схема, только придется
<br>&gt; &gt; держать в буфере ответы на более поздные запросы, пока не уйдут в<br>&gt; &gt; pipeline ответы на все предыдущие запросы - fifo. Задо задержка<br>&gt; &gt; получения ответов может значительно снизиться, за счет паралельной
<br>&gt; &gt; генерации контента, но никогда не увеличится (разве что какой-то бекенд<br>&gt; &gt; окажется перегружен, но тут надо менять текущю схему балансировки, я уже<br>&gt; &gt; когда-то писал).<br>&gt;<br>&gt; nginx обрабатывает pipelining последовательно. И я не вижу никакого
<br>&gt; смысла добавлять в обработку pipelining&#39;а искусственный интеллект -<br>&gt; за четыре года его существования в nginx&#39;е его поддержка со стороны<br>&gt; браузеров не изменилась (та же Опера + Файрвокс, выключенный по дефолту).
<br>Про какой ИИ идет речь? Пришол запрос - отпроксировался, ответ держится в<br>буффере, пока до его отдачи не дойдет очередь, а бекенд, если запрос<br>отработал полностью - освобождается, иначе ждет пока его спросят об<br>
остатке ответа, который не поместился в буффер.<br><br>&gt; А по поводу схемы балансировки по времени ответа очень хорошо сказал<br>&gt; на РИТе Олег Оболенский из Яндекса - &quot;пятисотки отдаются офигенно быстро&quot;.
</blockquote><div><br class="webkit-block-placeholder"></div><div>ошибки 5ХХ наверно &nbsp;</div><br><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">Не присутсвовал, из контекса не понимаю про какие пятисотки идет речь. И
<br>не понимаю что за &quot;балансировка по времени ответа&quot; - я вообще-то имел<br>ввиду балансировку по текущей загруженности бекендов - по текущему</blockquote><div><br class="webkit-block-placeholder"></div><div>как Вы узнаете загруженность бекенда? Cisco CSS в нгинх вкрячить? &nbsp;
</div><br><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">кол-ву запросов в обработке бекендом. А не балансировать по кол-ву<br>запросов вообще, как сейчас.</blockquote>
<div><br class="webkit-block-placeholder"></div><div>если только косвенно определить, сколько отдали запросов, сколько получили, разница и будет показателем примерной загруженности&nbsp;</div>если чего на бекенде не случится&nbsp;</div>
<br>