Re[3]: sendfile_max_chunk

[Anton Yuzhaninov <citrin@xxxxxxxxx>]

Hello Igor,

You wrote on Friday, May 11, 2007, 1:22:35 PM:

>> 8 процессов в sbwait(а значит клиенты этих процессов не получают сейчас
>> ничего, тк заблокированы процессы) - ждут перлового реврайта судя по 
>> старым постам. Судя по статусу Reading >=10 скорость входящих запросов
>> довольно большая. Не думали над схемой nginx frontend 5 worker's 
>> (sendfile, proxy_pass, X-Accel-Redirect) -> nginx(apache) 40+ workers 
>> (perl rewrite(либо что вам удобней) с выдачей редиректа)? Либо сделать
>> контролируемое скачивание одним nginx'ом, повесив perl в fast_cgi? 
>> Пример есть на http://sysoev.ru/nginx/links.html и в рассылке
>> Смысл - разнести процессы-раздатчики_файлов и процессы, которые уходят в
>> блокировку при проверке закачки. В результате сможете иметь 
>> контролируемое (и неблокирующееся за счёт sendfile_max_chunk) количество
>> раздатчиков_файлов(дискам полегче будет) и независимое от этого 
>> количество процессов, занимающихся проверкой закачки. Блокировка этих 
>> процессов не будет никому мешать(например worker_connections 1 :) )

IS> все не так просто. Перловый реврайт проверяет сессии, разрешенные
IS> айпишники, из базы берет путь к файлу. Он довольно большой. в sbwait
IS> процессы висят не много. Мускульные сервера не нагружены.. это просто
IS> те милисекунды которые нужны для соеденения с сервером и выполнения
IS> запроса.

Эти миллисекунды вполне могут быть узким местом в этой схеме.

IMHO стоит попробовать вынести проверку сессий на отдельный fastcgi
сервер, который потом будет выдавать X-Accel-Redirect на нужный файл.

-- 
 Anton Yuzhaninov.

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature