ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 

  СТАТЬИ 


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


  ПРОГРАММЫ 



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














     АРХИВ :: Apache-Talk
Apache-Talk mailing list archive (apache-talk@lists.lexa.ru)

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

Re: [apache-talk] =?koi8-r?B?UmU6IFthcGFjaGUtdGFsa10gbW9kX2FjY2VsIC0g18/Q0s/T2SDLIA==?==?koi8-r?B?0sHa0sHCz9TeycvVIMkgyyDUxc0sIMvUzyDFx88gydPQz8zY2tXF1A==?=



On Sun, 10 Feb 2002, Alexey Zvyagin wrote:

> >  А причем здесь размер буфера? И с какой стати сквид при _малом буфере_
> >  должен ждать, пока клиент будет вытягивать документ? Объясните.
> 
> Че то не понимаю я вас. При малом буфере он и будет ждать медленного
> клиента, разумеется, обслуживая также других. А что он, сокет с ним должен
> отрубить и отдать ему битый документ? И держать при этом backend сервер -
> mod_perl скрипты, например, пока медленный клиент не вытянет от фронтенда
> хотя бы до остатка в размере TCP приемного буфера между фронтендом и
> бекендом? IMHO вы сами запутались или что-то не так понимаете.

Малый размер буфера - это не помеха. mod_accel может принимать
от бэкенда хоть по 2К (это, по-моему, минимальный размер, который
я тестировал) и, тем не менее, обслуживает бэкенда максимально быстро,
поскольку сохраняет ответ во временный файл. Из этого файла
или же из памяти (если часть ответа ещё не попала в файл) ответ
отдаётся клиенту.
Я полагаю, что Squid делает то же самое, хотя в исходниках
за полчаса я этого не увидел. Впрочем, алгоритма mod_proxy
я не увидел тоже.

Игорь Сысоев

=============================================================================
=               Apache-Talk@lists.lexa.ru mailing list                      =
Mail "unsubscribe apache-talk" to majordomo@lists.lexa.ru if you want to quit.
=       Archive avaliable at http://www.lexa.ru/apache-talk                 =



 




Copyright © Lexa Software, 1996-2009.