QoS

[Kostya Alexandrov]

при чем тут сетеыое оборудование??? реч идет о блокировании при 
операциях с файлами на диске.
читайте флейм целиком.

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