QoS

[Kostya Alexandrov]

А что меняется кроме того что раздачей файлов с диска заемется отдельный 
пул воркеров?

Борис Долгов wrote:
> И сможет ли nginx после этого держать 10к коннектов?
>
> 23 мая 2008 г. 16:57 пользователь Kostya Alexandrov <koticka at mail.ru> написал:
>   
>> Да почему один мастер должен быть??? И что узкого в этом месте?
>> С задачей акцепта и парсинга запросов с успехолм справляется ява, с ее
>> ужасно "дорогими" строками и массивами.
>> Акцептать и парсить запрос впринципе можно любым воркером (каждым) но если
>> запрос "не мой" то отдать другому (положить в очередь).
>>
>>
>> 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 уже отправил запрос на чтение ядру системы.
>>>>>>>
>>>>>>>
>>>>>>> ==========================================================================
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>             
>>>>>
>>>>>
>>>>>           
>>>       
>>     
>
>
>
>