ПРОЕКТЫ 


  АРХИВ 


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



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

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

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

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

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.