|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Slawa Olhovchenkov 2:5030/500 04 Feb 2004 14:11:50
To : Igor Sysoev
Subject : sendfile
--------------------------------------------------------------------------------
04 Feb 04, Igor Sysoev writes to Slawa Olhovchenkov:
>> (отчет tcpdump убежал ранее)
IS> После того, как sendfile подготавливает для передачи данных размером около
IS> net.inet.tcp.sendspace, он засыпает (если сокет блокирующийся) или
IS> возвращается (если неблокирующийся).
(посмотрел lsof -- неблокирующийся)
IS> Если его разбудить или вызвать снова достаточно поздно, то последний
IS> подготовленный им в прошлый раз пакет будет отправлен неполным.
[1](чуток подумав) ну и фиг с ним. иначе полный пакет уйдет значительно позже.
Пожалуй имеющееся поведение правильно.
IS> "Достаточно поздно" зависит от разных условий - скорость клиента,
IS> загруженность сервера.
А разве не исключительно от параметров TCP?
IS> Кроме того, если sendfile заблокируется на чтении очередной страницы с
IS> диска, то быстрый клиент успеет получить то, что было подготовлено до
IS> этого.
Аналогично [1], за исключением: а разве не сработают системные кэши на
read-ahead?
>> IS> Я с этим борюсь просто - как в Линуксе, перед выдачей http
>> IS> заголовка
>> IS> включаю TCP_NOPUSH, а по окончании передачи - выключаю. В результате
>> IS> и заголовок попадает в один пакет с куском файла, и все файловые
>> IS> пакеты идут полными.
>>
>> # grep -r TCP_NOPUSH /usr/ports/www/thttpd/
>> #
IS> thttpd не ставит, а в моем сервере его можно включать/выключать на уровне
IS> location.
Я демонстрировал, что его не ставили в случае моего дампа.
Таки я не понял -- что надо делать для получения "плохого" эффекта, как
теоретически можно это залечить и не будет ли лечение хуже причины?
... Hет повести печальнее на свете, чем повесть о заклинившем Reset'е
--- GoldED+/BSD 1.1.5
* Origin: (2:5030/500)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
