QoS

[Alexey V. Karagodov]

On 24.05.2008, at 13:36, Kostya Alexandrov wrote:

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

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