Nginx-ru mailing list archive (nginx-ru@sysoev.ru)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: QoS
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@xxxxxxx
> написал:
А что меняется кроме того что раздачей файлов с диска заемется
отдельный пул
воркеров?
Борис Долгов wrote:
И сможет ли nginx после этого держать 10к коннектов?
23 мая 2008 г. 16:57 пользователь Kostya Alexandrov <koticka@xxxxxxx
>
написал:
Да почему один мастер должен быть??? И что узкого в этом
месте?
С задачей акцепта и парсинга запросов с успехолм справляется
ява, с ее
ужасно "дорогими" строками и массивами.
Акцептать и парсить запрос впринципе можно любым воркером
(каждым) но
если
запрос "не мой" то отдать другому (положить в очередь).
Sergey Shepelev wrote:
Написать несложно ничего. Речь о времени выполнения этого
кода. На
данный
момент непосредственно accept сокету делает воркер. И
воркер парсит
запрос.
В это время другой воркер может блокироваться на диске или
парсить
другой
запрос. А в случае предложенных пулов, один мастер должен
делать accept
и
парсить запросы, чтобы давать обработку воркерам. Получаем
узкое место -
производительность мастера.
Предлагаю настраиваемое кол-во воркеров первой очереди,
которые акцептят
и
парсят запрос и отдают непосредственно воркерам в пулах,
которые могут
блочиться на диске. Другими словами, встроенная схема nginx-
nginx.
Kostya Alexandrov пишет:
не вижу великого страха, и имхо нет необходимости отдельного
диспетчера,
хотя можно и с диспетчером.
"повышенная нагрузка" это распарсить реквест и положить в
нужную
очередь.
Я лет 5 не писал на С, потому даже в
резюме перестал указавыть, но на c++ или жаве, это
тривиальная задача.
Но
вот не очень уверен что это укладывается
в идеологию nginx.
Борис Долгов wrote:
Если использовать "пулы" - одному процессу придется
решать на какой
пул направить текущее соединение.
То есть, придется принимать сокет и читать запрос всего
одним
процессом, и только после этого передавать его на
обработку.
Не вижу в этом смысла, так как на тот процесс будет
повышенная
нагрузка, так как он, по сути, и будет один выполнять
основную роль
веб-сервера.
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 уже отправил запрос на
чтение ядру
системы.
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=========================================================
вот нахрена козе баян? извините за глупый вопрос
- 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?
что тут вообще разделять?
|
