Высокая производительность

индекс
187,32

Отдаём статику nginx'ом

Начиная с версии 0.8.11 в nginx появилась новая возможность для раздачи статики — использование AIO (Asyncronous Input-Output — неблокирующий ввод-вывод) для Linux и FreeBSD.

Чем это событие знаменательно? До этого момента nginx использовал неблокирующий режим только при работе с сетью — любая работа с файлами блокировала рабочий процесс. К чему это приводило? Если у вас есть много разного контента, который не весь находится в кэше ОС (фотохостинг, etc) — то рано или поздно все 50, 150, 200 процессов будут ждать дисковые операции и не смогут обслужить нового клиента — даже если нужный ему контент можно отдать из файлового кэша или запросить с бэкенда.


Как с этим боролись раньше?

  • Первый метод — увеличивать количество рабочих процессов. Но, сколько бы их ни было, всегда есть шанс, что на диске заблокируются все.
  • Второй способ — раздавать динамику и статику разными nginx'aми. Но запросы на популярную статику всё рано не будут обслуживаться так быстро, как могли бы.
  • Ещё больше усложнить 2ю схему — определить понятие «популярные файлы», и раздавать их так же отдельно. Но кэш ОС всегда будет работать эффективнее, чем свой собственный список популярности (да и это, по сути, повторение логики работы кэша)

Теперь появился новый способ, задействовав небольшое количество рабочих процессов, раздавать всё в неблокирующем режиме. Тестирование будет эмулировать нагрузку на файловый/картиночный хостинг — отдача большого числа относительно небольших файлов. Диск при этом упирается в скорость random seek.

Методика тестирования:
  • Тестовый сервер — OC FreeBSD 7.2 stable, 2xSATA 150GB 7200 rpm raid1, 2gb ram
  • Объём памяти под файловый кэш ~1.2gb
  • Объём тестовых файлов ~2.5 gb, каждый файл занимает 8-16кб, send-буфер в nginx выставлен на 16кб
  • nginx версии 0.8.19
  • Тестирующий сервер — подключен по сети, пропускная способность канала ~20mbit
  • Нагрузка создавалась утилитой ab, для генерации случайного имени файла использовался fastcgi скрипт, отдающий X-Accel-Redirect

image
image

Выводы: судя по тому, что с AIO удалось добиться 300 rps, что заметно превышает seek rate для используемых дисков, ядро FreeBSD умеет внутри переупорядочивать запросы, идущие через AIO, что даёт значительный выигрыш при отсутствии «умного» raid-контроллера с большим кэшем. При использовании же традиционного метода — большое количесто рабочих процессов, если они все уйдут на диск, сказывается на производительности лишь отрицательно.

PS: несколько замечаний по методике. Скорость генерации случаных имён файлов — достаточная, добавляет <0.5мсек на запрос (точнее измерять не было необходимости, такой скорости достичь не удалось). Возможно, в тестах с aio на большом количестве потоков был достигнут потолок канала. Время проведения каждого теста — две минуты.

PPS: работа AIO на Linux не проверялась, результаты могут отличаться в любую сторону.
+34
16 ноября 2009, 14:32
89

комментарии (18)

+7
ZAZmaster #
Неужели так сложно было рассказать про настройку AIO? Или дать ссылку?

www.lexa.ru/nginx-ru/msg26901.html
0
DurRandir #
Я практически не проводил настройки. Просто aio: on или aio:sendfile.
0
ZAZmaster #
Ну вот, я про это и говорил, что стоило упомянуть как включить данную фичу. Хотя уверен, что все умеют пользоваться поиском, но иногда просто лень :)
0
schors #
[плакал] отлично :) я в смысле ответа :)
P.S. Никакой иронии. Меня надо понять буквально.
0
spanasik #
Это здорово, а для Linux тестов нет?
Ну и какой опцией включается данный режим, по идее в статье желательно это написать?
0
DurRandir #
К сожалению, у меня нет под рукой Linux-машины. Не на чем проводить тесты.
0
esc #
К сожалению aio в nginx еще очень сырое, при его использовании nginx не определяет закрытое соединение (конкретно в этом могу ошибаться, в общем, не освобождаются ресурсы) и nginx съедает всю память вместе со свопом (со временем), кроме того, статистика stub_status показывает черти что (данные увеличенные в десятки раз).
0
DurRandir #
Но перспективы очень неплохие. Это давно ожидаемая фича, и Игорь, надеюсь, исправит все баги.
0
esc #
Да, я тоже в каждом новом релизе жду что-то об исправленном aio.
0
trak #
Парни, а не об этом писали>?
+1
DurRandir #
Там заявка о новой фиче. Здесь — тесты производительности, «а-нужна-ли-нам-эта-фича».
0
trak #
Так я и не против, просто засомневался. Спасибо!
–4
erley #
Спасибо за заметку, коротко и ясно всё описано! Побольше бы таких статей…
0
tony #
Спасибо за тесты!
0
Serafim #
почему для тестов с aio было выставлено 20 воркеров, в рассылке nginx'а неоднократно рекомендовали выставлять число воркеров равным числу ядер?
было бы интересно посмотреть на графики, когда при использовании aio выставлено 2, 4 или 8 воркеров.
0
DurRandir #
Они не ели cpu вообще. Пару процентов на все. 4х не хватает на эту нагрузку точно (проверял), поэтому поставил побольше. Чего не хватает на 4х — мне сложно сказать.

Воркеры = ядрам — это, в общем случае, много. Обычно хватает 2х. Здесь же специфическая нагрузка.
0
Serafim #
Не очень понятно, как именно Вы определили, что 4-х воркеров недостаточно (я правильно понял, что тестирование проходило на 4-х ядерной машине?)?
Вы написали, что сложно сказать чего не хватает, но ведь основываясь на чем-то Вы пришли к выводу, что надо выставить не 4, а 20, хотелось бы услышать, на чем Вы основывались в своем решении.

Прошу прощения за повторения вопроса, когда Вы производили тестирование, случайно не делали графиков для меньшего числа воркеров? Если такие графики есть, был бы рад, если Вы ими поделитесь.
0
DurRandir #
Машинка вообще на 2 ядра. У меня был тест на 4 воркера+aio — результат был меньше, чем простой sendfile. Исходников не осталось — новый график построить не смогу.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.