QoS

[Sergey Shepelev]

nginx часто работает под большими нагрузками.
Речь идёт о тысячах запросов в секунду. С тысячами виртуальных хостов.
Я не хочу ничего плохого сказать про Джаву.

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