Re: QoS

["Борис Долгов" <boris@xxxxxxxxxxx>]

Если использовать "пулы" - одному процессу придется решать на какой
пул направить текущее соединение.
То есть, придется принимать сокет и читать запрос всего одним
процессом, и только после этого передавать его на обработку.
Не вижу в этом смысла, так как на тот процесс будет повышенная
нагрузка, так как он, по сути, и будет один выполнять основную роль
веб-сервера.

23 мая 2008 г. 1:06 пользователь Kostya Alexandrov <koticka@xxxxxxx> написал:
>>> другой вариант решения - запустить два различных экземпляра 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 уже отправил запрос на чтение ядру системы.
>>
>> ==========================================================================
>>
>>
>
>



-- 
С уважением, Борис Долгов.
icq 77556665
e-mail boris@xxxxxxxxxxx