QoS

[Sergey Shepelev]

Написать несложно ничего. Речь о времени выполнения этого кода. На 
данный момент непосредственно accept сокету делает воркер. И воркер 
парсит запрос. В это время другой воркер может блокироваться на диске 
или парсить другой запрос. А в случае предложенных пулов, один мастер 
должен делать accept и парсить запросы, чтобы давать обработку воркерам. 
Получаем узкое место - производительность мастера.

Предлагаю настраиваемое кол-во воркеров первой очереди, которые акцептят 
и парсят запрос и отдают непосредственно воркерам в пулах, которые могут 
блочиться на диске. Другими словами, встроенная схема nginx-nginx.

Kostya Alexandrov пишет:
> не вижу великого страха, и имхо нет необходимости отдельного диспетчера, 
> хотя можно и с диспетчером.
> "повышенная нагрузка" это распарсить реквест и положить в нужную 
> очередь. Я лет 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 уже отправил запрос на чтение ядру системы.
>>>>
>>>> ========================================================================== 
>>>>
>>>>
>>>>
>>>>       
>>>     
>>
>>
>>
>>   
>