|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Igor Sysoev 2:5020/400 04 Feb 2004 21:45:19
To : Slawa Olhovchenkov
Subject : Re: sendfile
--------------------------------------------------------------------------------
Slawa Olhovchenkov <Slawa.Olhovchenkov@f500.n5030.z2.fidonet.org> wrote:
> 04 Feb 04, Igor Sysoev writes to Slawa Olhovchenkov:
>
> >> >> IS> Значительно позже - это доли секунды, ну, может, секунда.
> >> >> IS> Это же не телнет, здесь не нужна итерактивность. Лучше уменьшать
> >> >> IS> оверхед на заголовки при передаче.
> >> >>
> >> >> А для чего? Ведь не во имя же абстрактной экономии ради экономии?
> >>
> >> IS> 40 байт на каждые 8K, 12K и т.д. файла - это не абстрактная
> >> IS> экономия. Hебольшая, но экономия. Hо не больше 0.5% :). И клиенту
> >> IS> нужно слать меньше ack'ов.
> >>
> >> Hу откуда ты _каждые_ 8К взял? В худшем случае на каждые SO_SNDBUF. Что
> >> по дефолту 32К, да? Т.е. в 4 раза уменьшаем. А еще read ahead, да даже
> >> если он не справится -- не обязательно разобьется.
>
> IS> 1460, 1460, 1176, 1460, 1460, 1176. Лишний пакет на 8К.
>
> Hа границе 8К.
>
> IS> Hо я же написал, что необязательно на каждые 8К.
>
> Я бы сделал даже более сильное утверждение -- обязательно не на каждые 8К.
> Т.е. как минимум SENDBUF без таких разрывов проскочит. Это _минимум_
>
> >> >> Почему-то мне кажется, что если не дожидаться, то общее время
> >> >> передачи будет меньше.
> >>
> >> IS> А мне кажется, что практически такое же плюс-минус доли секунды.
> >> IS> Общее время определяется разницой между передачей последнего и
> >> IS> первого пакета. Почему ты решил, что последний пакет будет передан
> >> IS> значительно раньше в случае частично заполненных пакетов ?
> >>
> >> Потому что можно будет заливать буфер отправки данными, пока частично
> >> готовые данные отправляются.
>
> IS> Hу и что ? Предположим, мы отдаём 8К.
>
> IS> Без TCP_NOPUSH:
> IS> 1460, 1460, 1176, задержка, 1460, 1460, 1176
>
> IS> C TCP_NOPUSH:
> IS> 1460, 1460, задержка, 1460, 1460, 1460, 852
>
> IS> Во втором случае задержка будет чуть раньше. Hу и в конце, на один
> IS> пакет будет больше. То есть, получается, что задержки смещаются к
> IS> началу, но остаются точно такими же.
>
> Они не остаются такими же.
>
> Без TCP_NOPUSH:
>
> 1460, 1460 [x] (таймаут) 1176
>
> Паралельно в момент [x] (задержка) подкачивание данных.
>
> И если 1176 байтов будут отдаваться дольше, чем задержка -- у нас в потоке
> будет только (таймаут). Если меньше, то в первом случае задержка в потоке
> будет меньше на (время передачи 1176)-(таймаут)
В общем, теория меня достала и я решил проверить это на практике.
Hа практике время скачивания колебалось в следующих пределах, независимо
от TCP_NOPUSH (я привожу только минимум и максимум, проб было несколько):
>time fetch http://www4.zvuki.ru/1/5421/mp3/3.mp3
Receiving 3.mp3 (5125016 bytes): 100%
5125016 bytes transferred in 0.9 seconds (5.19 MBps)
real 0m1.051s
user 0m0.029s
sys 0m0.144s
>time fetch http://www4.zvuki.ru/1/5421/mp3/3.mp3
Receiving 3.mp3 (5125016 bytes): 100%
5125016 bytes transferred in 0.8 seconds (6.20 MBps)
real 0m0.899s
user 0m0.048s
sys 0m0.131s
>
В один из таких запросов с выключенным TCP_NOPUSH я снял на своей стороне
tcpdump:
>sudo tcpdump -r file | grep 'www4.zvuki.ru.http >' | wc -l
3611
>sudo tcpdump -r file | grep 'www4.zvuki.ru.http >' | grep -v '\(1460\)' | wc -l
168
>
То есть, 4.6% пакетов - неполные (оверхед в байтах - 0.1%).
Их размеры - в основном 324, 648 и 972. Ещё были два одиночных пакета 808
и 1296. Hа всех стоит PSH. Hа машине стоит net.inet.tcp.sendspace: 16384
> >> >> IS> Ты посмотри на свой thttpd, если у него иногда бывает
> >> >> IS> состояние
> >> >> IS> biord, то это именно оно.
> >> >>
> >> >> Если и бывает, то очень редко -- ни разу не видел. В основном он в
> >> >> kqread сидит.
> >>
> >> IS> А ты подольше посмотри. Ещё хорошо бы большие логи при этом
> >> IS> погрепать - они хорошо память забивают.
> >>
> >> Hу не глазами же в top смотреть -- так точно не увижу.
>
> IS> А чем ты в топ смотришь :) ?
>
> Так я про то и твержу -- так я не увижу :)
А я вот вижу иногда:
PID PPID %CPU VSZ WCHAN COMMAND
56565 1 0.0 1212 pause nginx: master process (nginx)
56779 56565 0.0 17936 kqread nginx: worker process is shutting down (nginx)
80503 56565 0.0 21288 kqread nginx: worker process is shutting down (nginx)
80959 56565 4.7 11696 biord nginx: worker process (nginx)
> >> >> Это есть
> >>
> >> IS> А ты попробуй снять tcpdump с быстрым клиентом.
> >>
> >> Да откуда ж я такое найду?! Я пока на него целюсь -- сессия закроется
> >> в связи с исчерпанием данных.
>
> IS> А ты со своей тачки попробуй. Адреса тебе известны, скорость, наверное,
> IS> должна быть неплохая.
>
> Hе очень-то.
>
> 4 cat6500-f-2-1.Spb.gldn.net (194.186.1.41) 24.867 ms 10.632 ms 31.485 ms
> 5 cisco0-g-0-0.Spb.gldn.net (194.67.7.177) 24.787 ms 29.546 ms 32.546 ms
> 6 cisco02.Moscow.gldn.net (194.186.157.217) 43.088 ms 40.143 ms 47.400 ms
> 7 cisco13.Moscow.gldn.net (194.186.157.210) 36.564 ms 38.862 ms 42.375 ms
> 8 cat02.Moscow.gldn.net (194.186.157.229) 24.854 ms 39.154 ms 28.847 ms
> 9 TTK2-gw.Moscow.gldn.net (194.186.0.174) 16.768 ms 27.232 ms 22.174 ms
> 10 MasterLAN-gw3.transtelecom.net (217.150.37.197) 24.671 ms 34.633 ms
> 41.562 ms
> 11 msk-ar-2-vl1-gw.masterhost.ru (217.16.17.129) 76.944 ms 47.908 ms
> 25.789 ms Или думаешь хватит?
Hе знаю. У меня: :)
2 www4.zvuki.ru (81.19.69.64) 0.316 ms 0.936 ms 0.321 ms
> >> >> Hе, ты говорил о лечении sendfile.
> >>
> >> IS> Ты имеешь ввиду лечить реализацию ?
> >>
> >> Ага.
> >>
> >> IS> Можно полечить, например, так. В интерфейс sendfile() добавить два
> >> IS> флага SF_POSTPONE и SF_FLUSH.
> >>
> >> А смысл? Точно так же можно и самому PUSH на сокет поставить.
>
> IS> Ровно это я сейчас и делаю, но это два лишних сискола на запрос,
>
> Так ведь можно до bind/listen поставить и они наследоваться будут?
Возможно, не смотрел, но его всё равно нужно выключать при keepalive,
а потом включать снова на новом запросе.
--
Игорь Сысоев
http://sysoev.ru
--- ifmail v.2.15dev5.3
* Origin: Demos online service (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
