ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 


  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА












     АРХИВ :: nginx-ru
Nginx-ru mailing list archive (nginx-ru@sysoev.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Persistent HTTP connections && Pipelining



Kostya Alexandrov wrote:
Совершенно верно ты понял, это надстройка над кип алайв.

Pipelining имеет смысл только в том случае если
1. ты шлеш (лигика приложения требует/позволяет, броузеры так делают и т.п.) новые запросы не дождавшись ответа
2. тебе не критичен порядок ответов.

Отсюда он НЕ сможет сильно разгрузить бекенд сам по себе, если поддержка его формальна.
Например в случае с апачем как бекендом толку особого небудет.

А я как раз пытаюсь разгрузить количество соединений (из-за проблемы с моим брандмауером, в основном) - не разгрузить бекенд. Для разгрузки бекенда у меня сейчас squid сидит.
Сервер, кстати, не Apache.


В случае проксирующего софта, иметь pipelined конекшен с бекендом и НЕ pipelined с клиентом нельзя. т.к. без спецальных подкидываний, и поддержки чего то типа реквест айди на бекенде определить какой ответ кому отдать невозможно. Т.е. можно только если каждое кипаливное соединение клиента с ngnix проксируется в одно кипаливное соединение с бекендом.Однако имеет полный смысл если клиент устанавливает киип алайв
соединение, и шлет следующий запрос послать его бекенду в том же сокете.

Если думать о прокси как клиент/сервер (со стороны клиента, сервер; со стороны сервера, клиент), то кажется что должно быть возможно. Другое дело что будет тяжело держать id каждого запроса.. А если клиент устанавливает keep-alive, использует ли nginx keep-alive к обращению к серверу? Или всё-таки делает отдельные запросы? Если уже поддерживает, то мне клиент надо лупасить :)


Konstantin Svist wrote:
Anton Yuzhaninov wrote:

Pipelining - это способ еще больше ускорить обработку
запросов, потому что клиент может отправить несколько
запросов "пачкой" не дожидаясь завершения обработки
предыдущего запроса перед отправкой следующего,
тогда backend вообще не будет простаивать
в ожидании нового запроса от frontend`а
после обработки предыдущего.


Как это выглядит с точки зрения фронтенда:

сейчас как только получен запрос от клиента, посылается запрос на бэкенд

если делать pipelining то фронтенд должен будет подождать еще один запрос (немного увелилчивая response time для первого), потом послать оба зпроса разом.

Ничего подобного. Насколько я понимаю:
* pipelining только имеет смысл когда используется keep-alive.
* Без keep-alive: каждый запрос приходит в отдельном соединении (параллельно). * С keep-alive, без pipelining: новый запрос приходит только когда предыдущий запрос вернулся (поочерёдно). * С keep-alive, с pipelining: новый запрос может быть послан по уже-существующему соединению. Побочный эффект: несколько запросов можно послать в одном пакете - но не обязательно.

Или может я что-то не так понял..?










 




Copyright © Lexa Software, 1996-2009.