QoS

[Kostya Alexandrov]

Да почему один мастер должен быть??? И что узкого в этом месте?
С задачей акцепта и парсинга запросов с успехолм справляется ява, с ее 
ужасно "дорогими" строками и массивами.
Акцептать и парсить запрос впринципе можно любым воркером (каждым) но 
если запрос "не мой" то отдать другому (положить в очередь).


Sergey Shepelev wrote:
> Написать несложно ничего. Речь о времени выполнения этого кода. На 
> данный момент непосредственно 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 уже отправил запрос на чтение ядру 
>>>>> системы.
>>>>>
>>>>> ========================================================================== 
>>>>>
>>>>>
>>>>>
>>>>>       
>>>>     
>>>
>>>
>>>
>>>   
>>
>
>