QoS

[Борис Долгов]

Как минимум - на три действия больше для каждого соединения.

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 уже отправил запрос на чтение ядру
>>>>>>>> системы.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ==========================================================================
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>>
>
>



-- 
С уважением, Борис Долгов.
icq 77556665
e-mail boris at dolgov.name