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?
>>> Пример есть на и в рассылке
>>> Смысл - разнести процессы-раздатчики_файлов и процессы, которые уходят в
>>> блокировку при проверке закачки. В результате сможете иметь
>>> контролируемое (и неблокирующееся за счёт sendfile_max_chunk) количество
>>> раздатчиков_файлов(дискам полегче будет) и независимое от этого
>>> количество процессов, занимающихся проверкой закачки. Блокировка этих
>>> процессов не будет никому мешать(например worker_connections 1 :) )
IS>> все не так просто. Перловый реврайт проверяет сессии, разрешенные
IS>> айпишники, из базы берет путь к файлу. Он довольно большой. в sbwait
IS>> процессы висят не много. Мускульные сервера не нагружены.. это просто
IS>> те милисекунды которые нужны для соеденения с сервером и выполнения
IS>> запроса.
> Эти миллисекунды вполне могут быть узким местом в этой схеме.
> IMHO стоит попробовать вынести проверку сессий на отдельный fastcgi
> сервер, который потом будет выдавать X-Accel-Redirect на нужный файл.
на данном этапе нет человеко/часов для переписывания системы. Нужно
пробывать выжать максимум из того что есть...
---------------------------------
Igor V. Savchenko
mailto: igor@xxxxxxxxx
ICQ: 86915046
