QoS

Kostya Alexandrov koticka at mail.ru
Fri May 23 15:52:50 MSD 2008


не вижу великого страха, и имхо нет необходимости отдельного диспетчера, 
хотя можно и с диспетчером.
"повышенная нагрузка" это распарсить реквест и положить в нужную 
очередь. Я лет 5 не писал на С, потому даже в
резюме перестал указавыть, но на c++ или жаве, это тривиальная задача. 
Но вот не очень уверен что это укладывается
в идеологию nginx.

Борис Долгов wrote:
> Если использовать "пулы" - одному процессу придется решать на какой
> пул направить текущее соединение.
> То есть, придется принимать сокет и читать запрос всего одним
> процессом, и только после этого передавать его на обработку.
> Не вижу в этом смысла, так как на тот процесс будет повышенная
> нагрузка, так как он, по сути, и будет один выполнять основную роль
> веб-сервера.
>
> 23 мая 2008 г. 1:06 пользователь Kostya Alexandrov <koticka at mail.ru> написал:
>   
>>>> другой вариант решения - запустить два различных экземпляра nginx
>>>> (на разных IP) - один для отдачи статики, а другой для отдачи html.
>>>> я еще не пробовал, поэтому советовать не буду. второй экземпляр apache,
>>>> например, у меня удалось запустить только сделав копию бинарного файла.
>>>>         
>> Через три nginx. Один фронтендом и в зависимости от локейшена проксирует или
>> на один или на второй.
>> Это работает хорошо, сам так раздаю.
>>
>> На счет разных пулов воркеров для разных задач - супер идея, имхо.
>> +1
>>
>> Gena Makhomed wrote:
>>     
>>> On Tuesday, May 20, 2008 at 17:25:20, Андрей wrote:
>>>
>>> А> почему я не могу выдать пользователю html мгновенно
>>>
>>> можно, если есть свободные воркеры
>>> и этот html уже будет в memcached.
>>>
>>> А> плохо то что пользователь не может видеть страницу,
>>> А> хотя процессор не нагружен, сеть хорошая и отдача должна
>>> А> происходить мгновенно.
>>>
>>> второй вариант решения - прикрутить к php eAccelerator, APC или XCache.
>>> тогда mod_php / php-fpm будет брать php скрипты прямо из shared memory,
>>> вообще без обращения к дисковой подсистеме. но нужны свободные воркеры.
>>>
>>> А> Варианта два - либо  все воркеры заблокированы, либо
>>> А> чтение самой php-страницы с диска происходит медленно.
>>>
>>> в этом случае обычно просто увеличивают количество воркеров.
>>> хотя в случае DDoS-атаки, насколько я понимаю, любое количество
>>> воркеров можно будет заблокировать на диске, 100 их там или 1000.
>>>
>>> другой вариант решения - запустить два различных экземпляра nginx
>>> (на разных IP) - один для отдачи статики, а другой для отдачи html.
>>> я еще не пробовал, поэтому советовать не буду. второй экземпляр apache,
>>> например, у меня удалось запустить только сделав копию бинарного файла.
>>>
>>> ==========================================================================
>>>
>>> хотя, такого же эффекта очень быстрой отдачи html можно было бы достичь,
>>> если внутри nginx разделить все воркеры на несколько различных классов:
>>>
>>> - 0 class/pool, занимается только отдачей из memcached,
>>> - 1 class/pool, занимается только отдачей от fastcgi backend`ов,
>>> - 2 class/pool, занимается только отдачей от http_proxy backend`ов,
>>> - 3 class/pool, занимается только отдачей содержимого cache.
>>> - 4 class/pool, занимается только отдачей static_best_effort.
>>> - 5 class/pool, занимается только отдачей static_idle_priority.
>>>
>>> PS реализовать поддержку aio - это вариант борьбы с этой же проблемой,
>>> только другим способом: сделать так, чтобы все воркеры на диске (почти)
>>> не блокировались. не знаю, какой вариант будет лучше (надежнее и быстрее).
>>>
>>> PPS в случае DDoS-атаки / большой нагрузки полезной была бы возможность
>>> включить QoS для отдачи статики - какие файлы отдавать в первую очередь,
>>> а какие можно задержать / отбросить. с помощью aio это труднореализуемо.
>>>
>>> если воркеры будут разделены на классы - disk io QoS можно реализовать
>>> средствами операционной системы через io scheduling class and priority
>>> ioprio_set(2), чтобы дисковая подсистема сервера работала с учетом QoS
>>> даже после того, как nginx уже отправил запрос на чтение ядру системы.
>>>
>>> ==========================================================================
>>>
>>>
>>>       
>>     
>
>
>
>   





More information about the nginx-ru mailing list