Persistent HTTP connections && Pipelining

[Anton Yuzhaninov]

On 14.11.2007 2:52, Konstantin Svist wrote:
> * С keep-alive, с pipelining: новый запрос может быть послан по 
> уже-существующему соединению. Побочный эффект: несколько запросов можно 
> послать в одном пакете - но не обязательно.
> 

Утрированный пример.
На бэкенде апач с MaxClients 2

Фронтен держит две Keep-Alive коннекции до бэкенда.

На фронтенд приоходит почти одновременно три запроса A, B, C

Фронтент с A послает через одну коннекцию, а два запроса B и C pipelin-ит через вторую коннекцию.

A запрос окзался "легким" и быстро освободил первый процесс.
Запрос B оказался "тяжелыми" и надолого занял 2-й процесс.

В результате запрос C ждет пока до него доберятся занятый второй процесс. хотя 1-й в это время простаивает и 
мог бы его обработать, если бы фонтенд не использовал pipelining.

Когда бэкенд имеет запас производительности то заметную часть времени процессы апача спят в ожидании accept()
в этом случае отпрака двух запросов одному процессу через pipelining только увеличит время ответа. Второй 
запрос лучше послать одному из незанятых процессов.

Если же все процессы заняты (вообще это говорит о том, что сервер перегружен), то выгоднее не послыать этот 
запрос через pipelining (поскольку мы не знаем какому процессу его лучше послать), а немного подождать и 
послать запрос тому, кто первый освободится.

Когда фронтенд для подключения к бэкенду не использует Keep-Alive то падание запроса к первому освободившемуся 
процессу произойдет атоматически (он сделает accept и заберет коннекцию из listen queue). В случае если 
фонтенд использует Keep-Alive он сам должен организровать очередь запросов и отпрвить запрос из очереди тому 
процессу, который перым пришлет ответ и таким образом сообщит, что он освободился.

-- 
WBR,
  Anton Yuzhaninov