On 2/20/06, Igor Sysoev <is@xxxxxxxxxxxxx> wrote:
> В данном случае будет два копирования - демон > nginx > client.
> Есть такой академический сервер Flash, в котором разделяются блокирующиеся
> и неблокирущиеся запросы. Основной процесс проверяет страницы за'mmap'ленного
> файла на предмет присутствия в памяти с помощью mincore() и, если страницы
> в памяти нет, то вспомогательный процесс читает кусок файла. Есть развитие
> этого сервера, см. "Making the ``Box'' Transparent: System Call Performance
> as a First-class Result", http://www.cs.princeton.edu/~yruan/
> где файлы не mmap'ять, а используется sendfile(), и в результате во
> FreeBSD 5.х у sendfile() появился флаг SF_NODISKIO.
>
> При проектировании nginx'а такая архитектура учитывалась и кое-где
> учитывается, что чтение из файла может вернуть NGX_AGAIN, но реализации
> специального процесса нет.
А если поступить так: группу потоков, умеющих делать sendfile,
порождать непосредственно в nginx, считать все без исключения вызовы
sendfile - блокирующими. "Основной" поток рабочего процесса при
необходимости сделать sendfile будет передавать сокет и
соответствующее распоряжение sendfile-потоку, а сам при этом -
возвращаться к обслуживанию других соединений. При такой схеме вроде
все зайцы разом убиваются?
> Что касается большого количества потоков, то как показывает практика,
> по-видимому, потоков нужно меньше, иначе они создают много паралелльных
> запросов к диску.
Ну хотелось бы это регулировать так, чтобы не затрагивать при этом
всякие неблокирующие операции.
--
Alexey Polyakov