On Sun, Feb 10, 2002 at 05:41:20PM +0500, Alexey Zvyagin wrote:
> > начинает отдавать всем клиентам, которые документ просят.
>
> Ну если он будет отдавать тот же документ другим клиентам, то для
> динамических запросов это будет кошмар - они почти все всегда ориентированы
> для одного клиента.
Ну уж как настроите.
> > Поэтому картина должна быть такая: независимо от размера буферов
> > документы с backend'а тягаются на такой скорости, которую позволяет
> > достичь LAN. Процесс этот ничем не тормозится, и заканчивается с
> > концом документа (а вовсе не с уходом клиента, который, кстати,
> > может быть не один - придет 2й пока не отвалился 1й, и тоже начнет
> > качать, и так далее).
>
> Я тоже ранее так думал, что будет все так работать. Но на живом сервере с
> большим количеством запросов я видел обратное - httpd демоны тогда росли в
> огромных количествах.
[далее поскипано]
У нас пустопорожний спор получается. Я объясняю Вам, ПОЧЕМУ эти процессы
МОГУТ плодиться (keep-alive), а Вы циклитесь на каком-то своем объяснении,
даже не утруждаясь проверить его. Смысла в таком общении нет, правда?
> > Насчет того, что сквид запросы делает по HTTP/1.0 - правильно. Насчет
> > невозможности keep-alive при запросе по HTTP/1.0 - совершенно неверно.
>
> Это уже "неправильная" реализация apache, если можно так сказать. По RFC в
> HTTP/1.0 нет Keep-Alive, а squid обязан работать по RFC, так как бекендом
> может оказаться на apache сервер.
А что, в rfc по 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 сек]
>
> Ваша проверка работает для apache, но из этого не следует, что squid делает
> keep-alive запросы к бекенду по HTTP 1.0 стандарту. Это ваши докадки и
> умозаключения.
Да? Давайте проверим вместе, что там напридумывали товарищи теоретики.
# tcpundump host elf.ihep.su and port 80
Kernel filter, protocol ALL, datagram packet socket
tcpdump: listening on all devices
16:05:06.996749 eth0 > 192.168.30.31.3213 > 194.190.161.106.www: S
2933871559:2933871559(0) win 32120 <mss 1460,sackOK,timestamp 330732697
0,nop,wscale 0> (DF) (ttl 64, id 41182)
16:05:07.023602 eth0 < 194.190.161.106.www > 192.168.30.31.3213: S
3182397771:3182397771(0) ack 2933871560 win 32120 <mss 1460,sackOK,timestamp
148339669 330732697,nop,wscale 0> (DF) [tos 0x4] (ttl 57, id 35250)
16:05:07.023741 eth0 > 192.168.30.31.3213 > 194.190.161.106.www: . 1:1(0) ack 1
win 32120 <nop,nop,timestamp 330732699 148339669> (DF) (ttl 64, id 41188)
16:05:07.025371 eth0 > 192.168.30.31.3213 > 194.190.161.106.www: P 1:193(192)
ack 1 win 32120 <nop,nop,timestamp 330732700 148339669> (DF) (ttl 64, id 41191)
HEAD / HTTP/1.0
Pragma: no-cache
Via: 1.0 sky-gate.rdtex.ru:3128 (Squid/2.3.STABLE4)
X-Forwarded-For: 127.0.0.1
Host: elf.ihep.su
Cache-Control: max-age=259200
Connection: keep-alive
16:05:07.060943 eth0 < 194.190.161.106.www > 192.168.30.31.3213: . 1:1(0) ack
193 win 32120 <nop,nop,timestamp 148339673 330732700> (DF) [tos 0x4] (ttl 58,
id 35254)
16:05:07.067973 eth0 < 194.190.161.106.www > 192.168.30.31.3213: P 1:293(292)
ack 193 win 32120 <nop,nop,timestamp 148339673 330732700> (DF) [tos 0x4] (ttl
58, id 35255)
HTTP/1.1 200 OK
Date: Sun, 10 Feb 2002 13:08:48 GMT
Server: Apache/1.3.14 (Unix) e1f mod_perl/1.24 rus/PL30.0
Content-Length: 1023
Last-Modified: Sun, 09 Sep 2001 17:20:01 GMT
ETag: "2f59-3ff-3b9ba4c1"
Keep-Alive: timeout=45, max=100
Connection: Keep-Alive
Content-Type: text/html
16:05:07.068077 eth0 > 192.168.30.31.3213 > 194.190.161.106.www: . 193:193(0)
ack 293 win 31856 <nop,nop,timestamp 330732704 148339673> (DF) (ttl 64, id
41194)
16:05:53.075507 eth0 < 194.190.161.106.www > 192.168.30.31.3213: F 293:293(0)
ack 193 win 32120 <nop,nop,timestamp 148344275 330732704> (DF) [tos 0x4] (ttl
57, id 35260)
16:05:53.075599 eth0 > 192.168.30.31.3213 > 194.190.161.106.www: . 193:193(0)
ack 294 win 31856 <nop,nop,timestamp 330737305 148344275> (DF) (ttl 64, id
41241)
16:05:53.075825 eth0 > 192.168.30.31.3213 > 194.190.161.106.www: F 193:193(0)
ack 294 win 31856 <nop,nop,timestamp 330737305 148344275> (DF) (ttl 64, id
41242)
16:05:53.104999 eth0 < 194.190.161.106.www > 192.168.30.31.3213: . 294:294(0)
ack 194 win 32120 <nop,nop,timestamp 148344277 330737305> (DF) [tos 0x4] (ttl
57, id 35261)
Обратили внимание на timestamp'ы? Видите задержку в 45 секунд?
Единственное, что отличает от Вашего случая - это работа в режиме
нормального прокси, не акселератора. Возможно, для акселератора
будет иначе, но проверьте уж сами, пожалуйста.
Да, кстати, в запросе не было никакого "Connection: keep-alive",
сквид поставил его сам. Версия сквида в хедерах видна, можете проверить.
> > Хотя я не исключаю того, что у Вас были какие-то иные проблемы, но все
> > равно tcpdump поможет их выявить (надеюсь, лучше, чем мой тон:).
>
> sniffit лучше такие вещи выявляет. Я им пользуюсь.
Иногда? :)
> > > Вы вообще используете squid как аксселератор? Если да, то сколько хитов
> в
> > > день к нему (или к бекенду) идет? Или вы только теоретик squid-а?
> >
> > С акселераторами сейчас не работаю. А вообще я теоретик, судьба такая. :)
>
> Ну тогда все понятно :)
> Вот когда запустите squid аксселератор на 100 тыс. хитовом серваке с 90%
> динамическими страницами, тогда я поверю, что 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 =