QoS

[Kostya Alexandrov]

10к соединений, в каждом из которых запросят отдать файл nginx не 
обслужит, по таймауту отпадет,
а для проксирования ничего не меняется.

Борис Долгов wrote:
> Как минимум - на три действия больше для каждого соединения.
>
> 23 мая 2008 г. 22:03 пользователь Kostya Alexandrov <koticka at mail.ru> написал:
>   
>> А что меняется кроме того что раздачей файлов с диска заемется отдельный пул
>> воркеров?
>>
>> Борис Долгов 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 уже отправил запрос на чтение ядру
>>>>>>>>> системы.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ==========================================================================
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>                 
>>>>>>>
>>>>>>>               
>>>>>           
>>>>         
>>>
>>>
>>>       
>>     
>
>
>
>