QoS

[Alexey V. Karagodov]

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?
что тут вообще разделять?