QoS

[Kostya Alexandrov]

При таких объемах статики данное обсуждение не имеет смысла, как и 
вопрос чем это раздавать.
Апач 2.2 справится легко и лайт и т.п.

Alexey V. Karagodov wrote:
>
> On 23.05.2008, at 23:00, Kostya Alexandrov wrote:
>
>> 10к соединений, в каждом из которых запросят отдать файл nginx не 
>> обслужит, по таймауту отпадет,
>> а для проксирования ничего не меняется.
> допустим файл (кучка файлов, хтмл-ко с картинкаме) в сумме 128 кило байт
> за секунду на гигабите, нгинх (и не только нгинх) максимум отдаст 1024 
> таких запроса
> таймауты чего тут сработают ?
> просто полосы не хватит
>
>>
>>
>> Борис Долгов 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 уже отправил запрос на чтение ядру
>>>>>>>>>>> системы.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ========================================================================== 
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>
> вот нахрена козе баян? извините за глупый вопрос
>
>
>>>>>>>>>>> - 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.
>>>>>>>>>>
>>>
>
> вот тут что-то умное перечисленно, но
> обычная схема например такая
> статика, ну статика, отдаётся, либо из кеша либо из фс
> динамика, либо из кеша либо с бекенда
> и зачем тут разделять вокеры по QoS?
> что тут вообще разделять?
>
>
>