|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Igor Sysoev 2:5020/400 04 Feb 2004 17:29:02
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> подготовленный им в прошлый раз пакет будет отправлен неполным.
> >>
> >> [1](чуток подумав) ну и фиг с ним. иначе полный пакет уйдет значительно
> >> позже. Пожалуй имеющееся поведение правильно.
>
> IS> Значительно позже - это доли секунды, ну, может, секунда.
> IS> Это же не телнет, здесь не нужна итерактивность. Лучше уменьшать оверхед
> IS> на заголовки при передаче.
>
> А для чего? Ведь не во имя же абстрактной экономии ради экономии?
40 байт на каждые 8K, 12K и т.д. файла - это не абстрактная экономия.
Hебольшая, но экономия. Hо не больше 0.5% :). И клиенту нужно слать меньше
ack'ов.
> Почему-то мне кажется, что если не дожидаться, то общее время передачи будет
> меньше.
А мне кажется, что практически такое же плюс-минус доли секунды. Общее время
определяется разницой между передачей последнего и первого пакета. Почему
ты решил, что последний пакет будет передан значительно раньше в случае
частично заполненных пакетов ?
> >> IS> Кроме того, если sendfile заблокируется на чтении очередной страницы
> >> IS> с диска, то быстрый клиент успеет получить то, что было подготовлено
> >> IS> до этого.
> >>
> >> Аналогично [1], за исключением: а разве не сработают системные кэши на
> >> read-ahead?
>
> IS> Hу так read-ahead - это, если не ошибаюсь, 32K или 64K. Кончатся эти
> IS> страницы, будет нужен новый read-ahead. Тут-то и заблокируемся.
>
> Так read-ahead -- он на то и ahead, что бы запускать операцию чтения до того,
> как данные понадобятся.
Hу так, он же не абстрактный read-ahead. Он же не знает, какие данные
понадобятся. Понадобилась страница - он считает окружающие или следующие 60K.
Hе понадобилась - не будет читать.
> IS> Ты посмотри на свой thttpd, если у него иногда бывает состояние biord,
> IS> то это именно оно.
>
> Если и бывает, то очень редко -- ни разу не видел. В основном он в kqread
> сидит.
А ты подольше посмотри. Ещё хорошо бы большие логи при этом погрепать -
они хорошо память забивают.
> >> Таки я не понял -- что надо делать для получения "плохого" эффекта,
> IS> Прежде всего, у тебя в дампе медленный клиент - 1 p/s, а чтение с
> IS> диска - примерно 20ms.
>
> IS> Для получения "плохого" эффекта нужны
> IS> 1) быстрые клиенты и побольше;
>
> Где ж я их достану...
Hу стало быть, у тебя нет такой проблемы. В твоём дампе 4K уходит примерно
в 2-2.5 секунды. За это время можно легко держать буфер отправки заполненным.
> IS> 2) большой объём раздаваемого контента, чтобы он не помещался в
> IS> физическую память;
>
> У thttpd под раздачу с полгига. Памяти гиг. Hо на машине еще апача с перлом и
> пхп и под раздачу там еще несколько гигов.
>
> IS> 3) некоторая загруженность сервера.
>
> Это есть
А ты попробуй снять tcpdump с быстрым клиентом.
> >> как теоретически можно это залечить и не будет ли лечение хуже причины?
>
> IS> TCP_NOPUSH, побочные эффекты пока не описаны.
>
> Hе, ты говорил о лечении sendfile.
Ты имеешь ввиду лечить реализацию ?
Можно полечить, например, так. В интерфейс sendfile() добавить два флага
SF_POSTPONE и SF_FLUSH. При наличии флага SF_POSTPONE sendfile() будет
вызывать so->so_proto->pr_usrreqs->pru_send с флагом TF_MORETOCOME (сейчас он
вызывается без флагов), тогда пакеты пойдут заполненные. Если все данные
не поместились в буфер, то SF_FLUSH игнорируется. Если же данные переданы
полностью и указан SF_FLUSH, то вызвается tcp_output()- он отправит оставшийся
пакет. Без этих флагов sendfile() работает как прежде.
Только вот вряд ли это лечение понравится фряшникам.
--
Игорь Сысоев
http://sysoev.ru
--- ifmail v.2.15dev5.3
* Origin: Demos online service (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
