ПРОЕКТЫ 


  АРХИВ 


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] Re: [apache-talk] mod_accel - вопросы к разработчику и к тем, кто его использует



On Sun, Feb 10, 2002 at 03:44:55PM +0500, Alexey Zvyagin wrote:
> >  А причем здесь размер буфера? И с какой стати сквид при _малом буфере_
> >  должен ждать, пока клиент будет вытягивать документ? Объясните.
> 
> Че то не понимаю я вас. При малом буфере он и будет ждать медленного
> клиента, разумеется, обслуживая также других. А что он, сокет с ним должен
> отрубить и отдать ему битый документ? И держать при этом backend сервер -
> mod_perl скрипты, например, пока медленный клиент не вытянет от фронтенда
> хотя бы до остатка в размере TCP приемного буфера между фронтендом и
> бекендом? IMHO вы сами запутались или что-то не так понимаете.

 Да нет, это Вы все-таки не разобрались, как работает сквид.
 Запрошенный документ он вытягивает сразу, на предельно возможной скорости.
 И складывает вытянутый документ в свой кэш (в памяти или на диске -
 зависит от разных обстоятельств, это сейчас неважно). При этом одновременно
 начинает отдавать всем клиентам, которые документ просят.

 Поэтому картина должна быть такая: независимо от размера буферов
 документы с backend'а тягаются на такой скорости, которую позволяет
 достичь LAN. Процесс этот ничем не тормозится, и заканчивается с
 концом документа (а вовсе не с уходом клиента, который, кстати,
 может быть не один - придет 2й пока не отвалился 1й, и тоже начнет
 качать, и так далее).

 Более того, возможности ограничить скорость download'а _до сих пор_ нет,
 хотя многим это реально нужно (не в акселераторах, конечно:).

> >  Мне кажется, Вы просто не понимаете, как сквид работает.
> Размер имеет значение :)

 Смотря для чего. Для скорости вытягивания документа с backend'а - не имеет,
 если мы только не беремся обсуждать доли процента.

> А вам не кажется, что squid с бекендом работает через HTTP 1.0 и keep-alive
> в этой версии протокола не работает?

 Насчет того, что сквид запросы делает по HTTP/1.0 - правильно. Насчет
 невозможности keep-alive при запросе по HTTP/1.0 - совершенно неверно.

 Проверять не пробовали? :)

% telnet localhost http
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
HEAD / HTTP/1.0
Connection: keep-alive

HTTP/1.1 200 OK
Date: Sun, 10 Feb 2002 12:03:10 GMT
Server: Apache/1.3.14 (Unix) e1f mod_perl/1.24 rus/PL30.0
Keep-Alive: timeout=45, max=100
Connection: Keep-Alive
Content-Type: text/html

[здесь коннекция висит положенные 45 сек]

> >  Я ничего не имею против mod_accel, но мне кажется, что дело не в магии.
> 
> Кроме язвительного тона, никакой сути я так не извлек из вашего письма.

 Жаль. Тогда буду конкретнее: запустите tcpdump и посмотрите, что
 происходит в действительности. Если keep-alive работает, то Вы должны
 увидеть незакрытую коннекцию после скоростной перекачки ВСЕГО документа.

 А если такое поведение действительно имеет место, то можно распаковать
 дамп трафикa и увидеть живьем этот keep-alive в хедерах.

 Хотя я не исключаю того, что у Вас были какие-то иные проблемы, но все
 равно tcpdump поможет их выявить (надеюсь, лучше, чем мой тон:).

> Вы вообще используете squid как аксселератор? Если да, то сколько хитов в
> день к нему (или к бекенду) идет? Или вы только теоретик squid-а?

 С акселераторами сейчас не работаю. А вообще я теоретик, судьба такая. :)
-- 
 Eugene Berdnikov
=============================================================================
=               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.