sendfile_max_chunk

[Igor Savchenko]

Hello Anton,

Friday, May 11, 2007, 2:02:06 PM, you wrote:

> 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 на нужный файл.


на данном этапе нет человеко/часов для переписывания системы. Нужно
пробывать выжать максимум из того что есть...

---------------------------------
Igor V. Savchenko

http://webta.net

mailto: igor at webta.net
ICQ: 86915046