QoS

[Alexey V. Karagodov]

On 24.05.2008, at 18:00, Kostya Alexandrov wrote:

> при чем тут сетеыое оборудование???
я имел в виду Cisco CSM

> реч идет о блокировании при операциях с файлами на диске.
> читайте флейм целиком.
сейчас от этого спасает сотня-другая вокеров
либо нормальный сетевой файл-сторадж

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