Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 128
Специальная маска “msie6” (0.7.12) соответствует регулярному выражению “MSIE [4-6]\.”, но работает быстрее. Начиная с версии 0.8.11, из этой маски исключается “MSIE 6.0;… SV1”.
nginx.org/ru/docs/http/ngx_http_gzip_module.html
спасибо. Интересно бы было послушать о буферах (не о тех что вы подумали, а о, например, fastcgi_buffer… или client_body_buffer...)
оно ограничено числом сокетов, доступных в системе (это порядка 64 * 10^3).С чего вдруг?
Теперь разберёмся с логированием. Во-первых, оставим логирование только критических ошибок.Очень вредный совет. Путем эконоимии даже не на спичках, а… не знаю с чем сравнить, вы упустите кучу важных ошибок.
# Only log critical errors.
error_log /var/log/nginx/error.log crit
А какие настройки лучше делать, если nginx всего лишь прокся дальше?
Те же самые. Разве что только кеширование статических файлов будет бестолково.
Даже если nginx проксирует дальше, то всё равно он может компрессировать, обрабатывать запросы для клиентов и прочее быстрее.
Даже если nginx проксирует дальше, то всё равно он может компрессировать, обрабатывать запросы для клиентов и прочее быстрее.
наверно можно «попросить» бэкэнд не жать отдаваемый трафик, установив хедер nginx-ом (если у вас nginx жмет)… впрочем, все зависит от ситуации…
На самом деле, чем раньше сожмешь — тем меньше пересылать, меньше работы, в том числе и между бэкендом и nginx-ом.
Можно даже настроить так, чтобы бэкенд сжимал всегда, а nginx будет сжатый ответ складывать в кэш, а при необходимости, если вдруг клиент не поддерживает сжатие — разжимать с помощью gunzip модуля.
Конечно это не всегда применимо. Если у вас итоговая страница строится из нескольких SSI-подзапросов, то сжимать получится только итоговую страницу.
Можно даже настроить так, чтобы бэкенд сжимал всегда, а nginx будет сжатый ответ складывать в кэш, а при необходимости, если вдруг клиент не поддерживает сжатие — разжимать с помощью gunzip модуля.
Конечно это не всегда применимо. Если у вас итоговая страница строится из нескольких SSI-подзапросов, то сжимать получится только итоговую страницу.
Вот вам другой пример: api, который сильно грузит бэкэнд, но отдаёт не так много данных, чтобы забить канал фронт-бэк. Я же писал — все зависит от ситуации.
Верно. Самый практичный вариант — попробовать разные варианты и замерять скорость на каждом, что бы понять что лучше в данной ситуации.
Например, сжатие забирает процессорное время, но экономит на трафике. Получилось, что на сервере определённой конфигурации самый эффективный уровень сжатия был 6, а на другом сервере получилось 8.
Например, сжатие забирает процессорное время, но экономит на трафике. Получилось, что на сервере определённой конфигурации самый эффективный уровень сжатия был 6, а на другом сервере получилось 8.
самый эффективный 5-6
8 — большая нагрузка на процессор при соответствующем трафика, а разница в размере несущественна.
Так же, если статика не изменяется, можно заранее сжать и положить рядом с файлом уже сжатый файл и (или) кэшировать.
8 — большая нагрузка на процессор при соответствующем трафика, а разница в размере несущественна.
Так же, если статика не изменяется, можно заранее сжать и положить рядом с файлом уже сжатый файл и (или) кэшировать.
Если процессора много (как было в моём случае), то 8 добавляет очень несущественную нагрузку. Именно поэтому надо пробовать на своём сценарии, так как чужие варианты могут работать немного иначе в конкретной ситуации.
Я сжимаю динамический контент, а статика обычно уже сжата достаточно хорошо что бы её не жать ещё раз.
Я сжимаю динамический контент, а статика обычно уже сжата достаточно хорошо что бы её не жать ещё раз.
И зачем ссылаться на неофициальный вики, при наличии официальной документации да ещё и на русском? Для кого мы стараемся? При этом ещё давать крайне вольную интерпретацию того, что делает часть «рекомендуемых» к изменению директив.
Вот всегда удивлялся странному поведению людей. Кучу раз видел статьи про настройку nginx типа этой и думал, что это монстр непостижимый. А тут самому пришлось, так я сразу в документацию, а там — диво дивное. Потратил всего день на ознакомление и настройку и все теперь быстро и приятно :) Спасибо вам!
Боюсь спросить, а для чего тогда вообще существует это вики? Там написана неправда?
В старые добрые ламповые времена, когда nginx писал один Игорь в свободное от работы время, документация существовала только на русском языке. Любознательный Cliff Wells решил попробовать nginx и ему понравилось. C помощью Google Translate он переводил документацию, а чтобы его усилия не пропали запустил wiki у себя на сервере и попросил Игоря настроить поддомен wiki.nginx.org.
Сейчас там наверху каждой страницы с документацией красными буквами: WARNING: this article is obsoleted. Please refer to nginx.org/en/docs/ for the latest official documentation.
Сейчас там наверху каждой страницы с документацией красными буквами: WARNING: this article is obsoleted. Please refer to nginx.org/en/docs/ for the latest official documentation.
Это синдром «все лгут» и «власти скрывают». Почему-то люди боятся официальной документации как огня, хотя как раз уважающие себя продукты (к ним относятся Postfix, Apache HTTP, QT, ну и nginx тоже) делают очень хорошую документацию.
Читая вот такую хаутушку всё равно лезешь в документацию, чтоб понимать, что ты делаешь и что ещё можешь сделать, а там выясняется, что можно было не читать хаутушку — в документации написано лучше.
Читая вот такую хаутушку всё равно лезешь в документацию, чтоб понимать, что ты делаешь и что ещё можешь сделать, а там выясняется, что можно было не читать хаутушку — в документации написано лучше.
Зачем прописывать
И было бы любопытно почитать, обоснование полезности указанных настроек, их плюсы и минусы. Если по отключению логов все понятно, то остальное вызывает вопросы. Например:
Почему вообще sendfile разработчики не включили по умолчанию?
Зачем ограничивать keepalive_requests, пусть запрашивает себе на здоровье?
tcp_nodelay так вообще включен по умолчанию.
use epoll;, если nginx и так выбирает механизм, лучше всего работающий на данной системе?И было бы любопытно почитать, обоснование полезности указанных настроек, их плюсы и минусы. Если по отключению логов все понятно, то остальное вызывает вопросы. Например:
Почему вообще sendfile разработчики не включили по умолчанию?
Зачем ограничивать keepalive_requests, пусть запрашивает себе на здоровье?
tcp_nodelay так вообще включен по умолчанию.
Скорее всего это было просто надергано из другого источника (или нескольких). Итоговый конфиг и комментарии к нему обладают каким-то магическим сходством вплоть до мелких деталий с этой статьей: dak1n1.rannmann.com/blog/12-nginx-performance-tuning (а та в свою очередь также скомпонована из чьих-то советов на форумах и блогах).
Так множится чушь, один написал «the number of socket connections available on the system (~64k)», другие повторяют.
Так множится чушь, один написал «the number of socket connections available on the system (~64k)», другие повторяют.
Зачем прописывать use epoll;, если nginx и так выбирает механизм, лучше всего работающий на данной системе?
tcp_nodelay так вообще включен по умолчанию.
Вполне возможно ситуация, когда вы настраиваете Nginx не с нуля. И ваш предшественник вполне мог переопределить дефолтные настройки не самым оптимальным образом. А данная директива весьма критична для оптимизации. Поэтому я её и упомянул.
Почему вообще sendfile разработчики не включили по умолчанию?
Да, согласен, эту директиву можно было лучше описать.
Зачем ограничивать keepalive_requests, пусть запрашивает себе на здоровье?
По умолчанию оно имеет значение 100, так что я его как раз увеличил.
keepalive принято ограничивать со времён, когда в апаче утекала память, и боролись с этим прибивая процесс каждые 300 запросов. Вот такая вот дурацкая традиция, об истоках которой некоторые люди даже не задумываются
А зачем тогда keepalive ограничивается в дефолтных настройках Nginx?
Не знаю. Я не вижу сегодня смысла вообще в любом ограничении кипалайва. Может, чтоб tcp-соединения хоть когда-нибудь заканчивались и начинались заново?
keepalive_requests по прежнему служит для избежания утечек памяти, переполнения всяких счетчиков и прочего. Во время обработки запроса могут быть выделения памяти, которые персистентны для всего соединения, особенно во всяких сторонних модулях (где вообще может быть всё, что угодно).Значение 100 по умолнчанию вполне разумно.
чтоб кол-во портов не закончилось
Вы «типа» протюнили nginx, но даже не удосужились протюнить ядро через sysctl.
тот же диапазон локальных портов увеличить
net.ipv4.ip_local_port_range = 1024 65535
Вы «типа» протюнили nginx, но даже не удосужились протюнить ядро через sysctl.
тот же диапазон локальных портов увеличить
net.ipv4.ip_local_port_range = 1024 65535
При чём здесь это? nginx висит у меня на одном порту и висит себе, какое отношение это имеет к количеству данных, которые через этот порт переданы?
а где я написал про количество данных?
или Вы не знаете, что такое «диапазон портов» и каким-то боком это отнесли к количеству данных.
При том же проксировании через nginx исходящие соединения создают локальный порт. Вот чтоб этот порто-диапозон не закончился и надо немного протюнить ядро.
или Вы не знаете, что такое «диапазон портов» и каким-то боком это отнесли к количеству данных.
При том же проксировании через nginx исходящие соединения создают локальный порт. Вот чтоб этот порто-диапозон не закончился и надо немного протюнить ядро.
А, речь про проксирование. Да, похоже, что в этом случае могут закончиться. Но я с трудом представляю себе это: статика и так отдаётся nginx, если он берёт что-то из кэша — прокси-соединение тоже не создаётся, и наконец та сторона, куда он передаёт один запрос из примерно пятисот — обычно это apache — тоже поддерживает keepalive.
минусуют те, кто не видел линукс и кто никогда не сталкивался с доссом, нехваткой портов?
Да просто проблема реально неочевидная и большинство с ней никогда не сталкивалось. Я тут не исключение. О проблемах типа «порты закончились» как-то не задумываешься…
вот это показывает, что специалистов, кто реально сталкивался с не статичным HighLoad еденицы, в основном тут биомасса. которая минусует, но даже не знают о чем речь.
Это намекает на то, что вам было полезно сразу в комментарии пояснить, о чём речь, а не после моего вопроса ;)
Вы в своем сообщение выше, которое заминусовали, объяснили нехваткой портов назначение директивы
keepalive_requests. Потом вы уточнили, что нехватка портов может случиться для исходящих соединений при проксировании. А теперь потрудитесь объяснить, как проксирование в nginx связано с обсуждаемой директивой, и как вообще эта директива в этом случае может помочь? Ответ я знаю — никак не связано, помочь не может.
При чём тут это? Я насколько знаю, keep-alive или они же persistent connections служат для того, чтобы в рамках одного подключения передать большой объём данных. Например, когда у вас на странице много графики. А с проксированием это не связано практически никак.
Утекала память не в Апаче, а в php скриптах. Точнее в mod_php она утекала.
эти настройки можно изменить на более низком уровне.
через тот же sysctl
настроки по умолчанию примерно такие:
net.ipv4.tcp_keepalive_time = 300
net.ipv4.tcp_keepalive_intvl = 75
net.ipv4.tcp_keepalive_probes = 9
Первый параметр — проверять созданное соединение через 300 сек.
Второй — интервал проверки
третий — кол-во проверок
В условиях ддоса, настройки следует изменить на меньшие, примерно такие.
net.ipv4.tcp_keepalive_time = 60
net.ipv4.tcp_keepalive_intvl = 10
net.ipv4.tcp_keepalive_probes = 5
через тот же sysctl
настроки по умолчанию примерно такие:
net.ipv4.tcp_keepalive_time = 300
net.ipv4.tcp_keepalive_intvl = 75
net.ipv4.tcp_keepalive_probes = 9
Первый параметр — проверять созданное соединение через 300 сек.
Второй — интервал проверки
третий — кол-во проверок
В условиях ддоса, настройки следует изменить на меньшие, примерно такие.
net.ipv4.tcp_keepalive_time = 60
net.ipv4.tcp_keepalive_intvl = 10
net.ipv4.tcp_keepalive_probes = 5
Этот keepalive — это другой keepalive. Это «сколько времени держать поднятый сокет, если не было ни одного пакета». А keepalive в http-сервере — это обычно «сколько по одному tcp-соединению можно задать http-запросов».
А я не замену keepalive_requests указал,
я указал для:
«а закрывать открытое соединение некому.»
я указал для:
«а закрывать открытое соединение некому.»
Вы написали эти настройки можно изменить на более низком уровне. Эти? Как TCP keepalive соотносится с обсуждаемым в ветке HTTP keepalive? Никак.
Настройки, которые вы предложили менять через sysctl сразу для всей системы, можно задать в nginx индивидуально для сокета в параметрах директивы listen, причем работать будет на всех поддерживающих это ОС (включая даже DragonFlyBSD, где соответсвующие интервалы задаются в миллисекундах — будет произведена конвертация значений).
Настройки, которые вы предложили менять через sysctl сразу для всей системы, можно задать в nginx индивидуально для сокета в параметрах директивы listen, причем работать будет на всех поддерживающих это ОС (включая даже DragonFlyBSD, где соответсвующие интервалы задаются в миллисекундах — будет произведена конвертация значений).
Вредные советы от uaoleg :)
Вот эту строчку я особо не навижу
error_log /var/log/nginx/error.log crit
когда какие то проблемы и нихрена в логах нет.
error_log /var/log/nginx/error.log crit
когда какие то проблемы и нихрена в логах нет.
Автор, не нужно включать sendfile, если не работаете с ram диском! Во-первых, вы теряете кэширование, что очень актуально для мелких файлов. Во-вторых, для эффективной работы с дисками (hdd и ssd) есть aio/directio, которые не работают вместе с sendfile.
www.linux.com/community/forums/storage/sendfile-and-memory-cache
В коде лучше сами поищите, если так интересно;) По опыту работу с высоконагруженными файловыми серверами, скажу что для дисков эту опцию не включать. Очень сильно растет iowait и в целом, диски работают намного хуже. И для крупных файлов и для мелких.
В коде лучше сами поищите, если так интересно;) По опыту работу с высоконагруженными файловыми серверами, скажу что для дисков эту опцию не включать. Очень сильно растет iowait и в целом, диски работают намного хуже. И для крупных файлов и для мелких.
Есть ещё ядерный aio, который сводится к пулу ядерных тредов, выполняющих обычные read/write, только полностью в kernel space, и посылающие нотификацию процессу, когда всё будет готово. А вот там как раз опять могут всплыть засады с O_DIRECT, подробностей о состоянии дел на текущий день, к сожалению, не знаю.
То, что было почти 10 лет назад, можно посмотреть тут: www.kernel.org/doc/ols/2003/ols2003-pages-351-366.pdf
Более скудная, но зато свежая информация: www.fsl.cs.sunysb.edu/~vass/linux-aio.txt
И да, если мы можете почитать sendfile по диагонали и что-то при этом понять — вы очень круты :)
Более скудная, но зато свежая информация: www.fsl.cs.sunysb.edu/~vass/linux-aio.txt
И да, если мы можете почитать sendfile по диагонали и что-то при этом понять — вы очень круты :)
Щито? sendfile в принципе работает через pagecache. Можете не верить мне, но Торвальдс пишет то же самое: yarchive.net/comp/linux/splice.html.
Или вы про какое-то другое кеширование?
Или вы про какое-то другое кеширование?
а какие по размеру файлы «крупные» и «мелкие»?
в среднем HTML страница занимает 60К — это относим в какую категорию?
в среднем HTML страница занимает 60К — это относим в какую категорию?
Что за чушь? Почему это число открытых сокетов 64к? Автор попутал с числом портов в TCP, так вот, это разные вещи. Число разрешённых сокетов для приложения определяется лимитом на число FD'шек.
А вот за таймаут в 2с я бы по ушам сильно бил. В лаборатории ок, в реальной жизни у клиентов с неидеальным интернетом (особенно, если до сайта пинг порядка 300-400мс) сайт будет глючить и бибикать без явной причины.
А вот за таймаут в 2с я бы по ушам сильно бил. В лаборатории ок, в реальной жизни у клиентов с неидеальным интернетом (особенно, если до сайта пинг порядка 300-400мс) сайт будет глючить и бибикать без явной причины.
Добавил статью в избранное, почитал комментарии, удалил из избранного.
Я не совсем понял. Написано:
значение worker_rlimit_nofile должно быть равным удвоенному значению worker_connections.
Но при worker_connections 4000, worker_rlimit_nofile 200000? Почему 200000, а не 8000?
значение worker_rlimit_nofile должно быть равным удвоенному значению worker_connections.
Но при worker_connections 4000, worker_rlimit_nofile 200000? Почему 200000, а не 8000?
Все очень плохо.
Не буду комментировать явные ошибки типа 64 тыс соединений, они просто показывают некомпетентность автора, извините.
Экономия на логах — это не правильно. Если у вас узкое место — это запись логов на диск, купите диски побыстрее.
Логгирование должно быть максимально подробным, и access_log в том числе. Это позволяет быстро локализовать проблему при наличии.
Если отключить access_log, как советует автор, а error выставить в crit, а потом еще удалить всю статику, то система будет «выглядеть нормально», при этом клиенты будут видеть долбанное ничего. За то быстро :)
Не буду комментировать явные ошибки типа 64 тыс соединений, они просто показывают некомпетентность автора, извините.
Экономия на логах — это не правильно. Если у вас узкое место — это запись логов на диск, купите диски побыстрее.
Логгирование должно быть максимально подробным, и access_log в том числе. Это позволяет быстро локализовать проблему при наличии.
Если отключить access_log, как советует автор, а error выставить в crit, а потом еще удалить всю статику, то система будет «выглядеть нормально», при этом клиенты будут видеть долбанное ничего. За то быстро :)
Спасибо, про 64.000 — да, это был явный феил, куда же без них. Но я убрал это ещё пол часа назад, или все читают только комменты, а не статью? :)
Про логированию — в очередной раз позволю себе не согласится: я писал, что эти настройки я использовал в тестовом окружении, и что не стоит их слепо переносить на прод. Чем плохо отключить логирование, скажем на аксептансе, чтобы автотесты работали чуточку быстрее?
Про логированию — в очередной раз позволю себе не согласится: я писал, что эти настройки я использовал в тестовом окружении, и что не стоит их слепо переносить на прод. Чем плохо отключить логирование, скажем на аксептансе, чтобы автотесты работали чуточку быстрее?
>Чем плохо отключить логирование, скажем на аксептансе, чтобы автотесты работали чуточку быстрее?
Тем, что они не будут работать «чуточку быстрее».
Это совет из серии «в php одинарные кавычки быстрее двойных». Только в отличии от данного совета, ваш еще и вредит, т.к. лишает пользователя диагностической и отладочной информации.
Тем, что они не будут работать «чуточку быстрее».
Это совет из серии «в php одинарные кавычки быстрее двойных». Только в отличии от данного совета, ваш еще и вредит, т.к. лишает пользователя диагностической и отладочной информации.
Это совет из серии «в php одинарные кавычки быстрее двойных».
Т.е. писать строки в одинарных кавычках — это вредный совет? А его ещё и в официальной документации дают. Всё зависит от области применения, имхо.
По вашей ссылке написано
Что в переводе означает следующее:
Пожалуйста убедитесь, что для всех операторов запроса (начинающихся с $) вы используете одинарные кавычки, чтобы PHP не пытался заменить текст '$exists' значением переменной $exists.
Они по-разному обрабатываются, если что. Но это не означает, что одинарные работают быстрее. На выходе вы получите те же opcode, что с одинарными, что с двойными кавычками. И даже heredoc синтаксис даст такой же результат.
Возвращаясь к логгированию — я всего лишь хотел сказать, что отсутствие логов не увеличит быстродействие (по крайней мере вы не заметите этого увеличения ни одним тестом), но при этом вы потеряете кучу полезной информации.
Please make sure that for all special query operators (starting with $) you use single quotes so that PHP doesn't try to replace "$exists" with the value of the variable $exists.
Что в переводе означает следующее:
Пожалуйста убедитесь, что для всех операторов запроса (начинающихся с $) вы используете одинарные кавычки, чтобы PHP не пытался заменить текст '$exists' значением переменной $exists.
Они по-разному обрабатываются, если что. Но это не означает, что одинарные работают быстрее. На выходе вы получите те же opcode, что с одинарными, что с двойными кавычками. И даже heredoc синтаксис даст такой же результат.
Возвращаясь к логгированию — я всего лишь хотел сказать, что отсутствие логов не увеличит быстродействие (по крайней мере вы не заметите этого увеличения ни одним тестом), но при этом вы потеряете кучу полезной информации.
> отсутствие логов не увеличит быстродействие
Строго говоря, логирование может сказаться на быстродействии, если дисковое I/O загружено под завязку, либо если объём логов слишком велик. В случае СУБД рекомендуется выносить лог транзакций на отдельный физический диск, хранящий исключительно лог. В этом случае скорость работы СУБД ограничится потоковой скоростью записи на диск (~100+ МБ/с). Полагаю, для Nginx как и для других логирующих систем этот принцип будет так же справедлив.
Строго говоря, логирование может сказаться на быстродействии, если дисковое I/O загружено под завязку, либо если объём логов слишком велик. В случае СУБД рекомендуется выносить лог транзакций на отдельный физический диск, хранящий исключительно лог. В этом случае скорость работы СУБД ограничится потоковой скоростью записи на диск (~100+ МБ/с). Полагаю, для Nginx как и для других логирующих систем этот принцип будет так же справедлив.
Логи пишутся всегда последовательно, «в конец».
Я вообще рассматриваю вариант логирования через сеть на специально выделенный сервер. Так и безопаснее (подтереть логи за собой не выйдет), и проще (целевой системе не нужно задумываться об анализе вторжений, ротации и тому подобном).
Я вообще рассматриваю вариант логирования через сеть на специально выделенный сервер. Так и безопаснее (подтереть логи за собой не выйдет), и проще (целевой системе не нужно задумываться об анализе вторжений, ротации и тому подобном).
Да, логи пишутся в конец файла. Однако, если диск HDD, плюс на этом же диске хранится раздаваемая статика, БД и т.п., то головка диска будет совершать кульбиты туда-сюда, и IOPsы просядут.
С точки зрения производительности — лучше на другой физический диск на этом же сервере, с точки зрения безопасности — наверное Вы правы. Можно использовать syslog.
С точки зрения производительности — лучше на другой физический диск на этом же сервере, с точки зрения безопасности — наверное Вы правы. Можно использовать syslog.
А что мешает создать папку в памяти и складировать логи туда, а раз в 10 минут по крону перекидывать на жесткий диск?
пример:
Так создаем папку в памяти
sudo mkdir /home/logs
sudo chmod 0777 /home/logs
sudo mount -t tmpfs -o size=512M tmpfs /home/logs
пример:
Так создаем папку в памяти
sudo mkdir /home/logs
sudo chmod 0777 /home/logs
sudo mount -t tmpfs -o size=512M tmpfs /home/logs
Зачем такие сложности? nginx сам умеет кэшировать запись логов.
Вы только что изобрели асинхронную запись. Только ОС сбрасывает буфер на диск не раз в 10 минут, а раз в несколько секунд.
Использовать асинхронную запись не мешает ничто кроме риска потерять данные (если они критичны). Поэтому журнал транзакций в СУБД выполняется в синхронном режиме, и это влияет на производительность I/O. А логи веб-сервера могут вестись в асинхронном режиме (скорее всего, так и есть).
Кроме того, лог можно направлять в syslog и отправлять по сети на соседний сервер. Тоже выход.
Использовать асинхронную запись не мешает ничто кроме риска потерять данные (если они критичны). Поэтому журнал транзакций в СУБД выполняется в синхронном режиме, и это влияет на производительность I/O. А логи веб-сервера могут вестись в асинхронном режиме (скорее всего, так и есть).
Кроме того, лог можно направлять в syslog и отправлять по сети на соседний сервер. Тоже выход.
просветите пожалуйста, как изменить настройки, чтоб получать лог раз в n минут из памяти nginx, не напрягая жесткий диск каждые пару секунд.
access_log path [format [buffer=size [flush=time]]];
nginx.org/en/docs/http/ngx_http_log_module.html
nginx.org/en/docs/http/ngx_http_log_module.html
tail -1 /var/log/nginx/personal.access_log | wc
1 27 386
Чтобы сделать поток ~100МБ/с — надо примерно 200k rps. Это мягко говоря не мало.
Чуть дальше по ветке Masterme написал, что тупо просядут IOPS на HDD.
Это если вынести лог на отдельный диск.
А я имел ввиду ситуацию, когда и лог, и раздаваемый контент находятся на одном диске. Всё дело в количестве IOPs, а также в том, как именно nginx ведёт лог — синхронно или асинхронно (я не знаю этого наверняка, но, возможно кто-то другой здесь знает). Если синхронно, то любой запрос к статике — это, грубо говоря, 2 обращения к диску — на чтение целевого файла и на запись лога. Если асинхронный — то ситуация получше, запись кидается в очередь в оперативной памяти, а ОС сама записывает на диск когда ей удобнее.
А я имел ввиду ситуацию, когда и лог, и раздаваемый контент находятся на одном диске. Всё дело в количестве IOPs, а также в том, как именно nginx ведёт лог — синхронно или асинхронно (я не знаю этого наверняка, но, возможно кто-то другой здесь знает). Если синхронно, то любой запрос к статике — это, грубо говоря, 2 обращения к диску — на чтение целевого файла и на запись лога. Если асинхронный — то ситуация получше, запись кидается в очередь в оперативной памяти, а ОС сама записывает на диск когда ей удобнее.
> писать строки в одинарных кавычках — это вредный совет?
_надрачивать_ на одинарные кавычки — вредный совет
> А его ещё и в официальной документации дают
там дают совет «не забудьте, что в двойных кавычках происходит автозамена $-переменных на их значения», а вовсе не «одинарные кавычки быстрее двойных»
_надрачивать_ на одинарные кавычки — вредный совет
> А его ещё и в официальной документации дают
там дают совет «не забудьте, что в двойных кавычках происходит автозамена $-переменных на их значения», а вовсе не «одинарные кавычки быстрее двойных»
Блин, это еще и в лучшее попало.
Люди, очнитесь! Читайте официальную документацию nginx.org/en/docs/ nginx.org/ru/docs/, а не эти «вредные советы».
Nginx очень прост в настройке, не надо его бояться.
Люди, очнитесь! Читайте официальную документацию nginx.org/en/docs/ nginx.org/ru/docs/, а не эти «вредные советы».
Nginx очень прост в настройке, не надо его бояться.
Спасибо, действительно важная настройка. А у вас есть опыт, какие значения будут оптимальными и почему?
Тут не может быть оптимального значения. Потому как предсказать, на сколько быстро растащится очередь невозможно.
Лично я для обычных сайтов ставлю 10. Позволяет сгладить всплески нагрузки, но не до такой степени, что бы страницы отдавались с критичной задержкой.
Лично я для обычных сайтов ставлю 10. Позволяет сгладить всплески нагрузки, но не до такой степени, что бы страницы отдавались с критичной задержкой.
Интересно, почему на FreeBSD и на Mac OS X он имеет дефолтное значение -1, а на остальных системах 511.
Уверен, что атавизм.
backlog так же полезен, если не больше, между nginx и бэкэндом. Помогает отрабатывать коннекты без 502 ошибок клиенту на сервере с ограниченным количеством ОЗУ (т.е. по количеству рабочих процессов мы сильно лимитированны) ценой небольшой задержки. Ибо «стоимость» коннекта в backlog-е сильно «дешевле» чем висящий рабочий процесс бэкэнда (в контексте PHP говорю, но и для других неСишных бэкэндов актуально).
backlog так же полезен, если не больше, между nginx и бэкэндом. Помогает отрабатывать коннекты без 502 ошибок клиенту на сервере с ограниченным количеством ОЗУ (т.е. по количеству рабочих процессов мы сильно лимитированны) ценой небольшой задержки. Ибо «стоимость» коннекта в backlog-е сильно «дешевле» чем висящий рабочий процесс бэкэнда (в контексте PHP говорю, но и для других неСишных бэкэндов актуально).
Советую не копировать значения директив кеширования, а поиграть с ними, подобрав оптимальные для вашего окружения.
Ну и как с ними играть? Если уж говорите что нужно что-то тюнить, то говорите на какие показатели во время работы смотреть после тюна чтоб понимать что нужно подкрутить. Вы же не пишите статью только для суворых админов…
А почему топик не помечен как перевод? dak1n1.com/blog/12-nginx-performance-tuning
Переведите ту статью и сравните результат.
Переведите комментарии конфига из той статьи и сравните результат.
Да, сравните. Помимо той статьи я использовал много других источников.
Я вижу явный плагиат и вранье с Вашей стаороны, извините.
Вступление абсолютно одинаковое
Из чего я делаю вывод, что сами Вы лично эти тесты не проводили.
Далее вы просто перессказываете весь файл конфигурации, с переводом на русский язык. Я не нашел вообще ничего, что есть у Вас, и нет в той статье.
Вступление абсолютно одинаковое
Generally, a properly tuned Nginx server on Linux can handle 500,000 — 600,000 requests per second. My Nginx servers consistently handle 904k req/sec, and have sustained high loads like these for the ~12 hours that I tested them.
It's important to know that everything listed here was used in a testing environment, and that you might actually want very different settings for your production servers.
Из чего я делаю вывод, что сами Вы лично эти тесты не проводили.
Далее вы просто перессказываете весь файл конфигурации, с переводом на русский язык. Я не нашел вообще ничего, что есть у Вас, и нет в той статье.
Статья была взята за основу, но к каждой настройке я писал развёрнутое пояснения по материалам wiki.nginx.org, вопросов на stackovwerflow.com, а ряда других источников. Как это может быть переводом, если я внёс свои пояснения к каждой директиве? Плюс благодаря комментариям читателей исправил ошибки и внёс улучшения в исходный конфиг. Что здесь плохого? Кому это навредит?
Я не говорю что это кому-то навредит.
Я говорю, что вы выдаете работу другого человека (и поиск оптимальной конфигурации, и проведение тестов) за свою. Развернутые пояснения ко всем директивам есть в оригинальной статье — я вижу только их вольный перевод.
Я говорю, что вы выдаете работу другого человека (и поиск оптимальной конфигурации, и проведение тестов) за свою. Развернутые пояснения ко всем директивам есть в оригинальной статье — я вижу только их вольный перевод.
Я не вижу смысла пересказывать ещё раз всю статью. Но постараюсь вас всё-таки отстоять свою позицию на примере первой же директивы. В приведенной вами статье к ней указан следующий комментарий:
В моей стать комментарий следующий:
Я думаю очевидно, что моё описание куда более развёрнутое, объясняет в каких ситуациях какое значение для директивы будет более оптимальным и почему. Я потратил на эту работу достаточно личного времени для того, чтобы опубликовать её не как банальный перевод.
# This number should be, at maximum, the number of CPU cores on your system.
# (since nginx doesn't benefit from more than one worker per CPU.)
В моей стать комментарий следующий:
Начнём с директивы worker_processes. Если Nginx выполняет работу нагружающую процессор (например SSL или gzipping), то оптимально установить эту директиву в значение, равное количеству ядер процессора. Выигрыш при большем значении вы получите только в случае обработки очень большого количества статики.
Я думаю очевидно, что моё описание куда более развёрнутое, объясняет в каких ситуациях какое значение для директивы будет более оптимальным и почему. Я потратил на эту работу достаточно личного времени для того, чтобы опубликовать её не как банальный перевод.
Я понимаю Ваше желание отстоять свой труд. Я лишь говорю о том, что не стоит присваивать себе действия других людей, и когда в таком количестве копируете материал (а у вас скопирована вся конфигурация) — ставьте ссылку на источник.
Однако, на примере первой же директивы я не понимаю, чем Ваше описание лучше чужого. Вы просто развернуто написали то же самое, посоветовали установить ее в конкретное значение. Почему ее нужно установить именно так — я не понял из Вашей статьи. А если мой nginx не занимается
В оригинальной статье мне намного понятнее, почему имеено так —
Вашу позицию я понял, считаю что спор продолжать нет смысла.
Однако, на примере первой же директивы я не понимаю, чем Ваше описание лучше чужого. Вы просто развернуто написали то же самое, посоветовали установить ее в конкретное значение. Почему ее нужно установить именно так — я не понял из Вашей статьи. А если мой nginx не занимается
SSL или gzipping— мне можно ее в 1 установить? И все равно получу 900к реквестов в секунду?
В оригинальной статье мне намного понятнее, почему имеено так —
since nginx doesn't benefit from more than one worker per CPU.То есть самое важное осталось без перевода.
Вашу позицию я понял, считаю что спор продолжать нет смысла.
Скажем не перевод, а компиляция. Но источники автор должен был указать.
После такого рьяного спора о логах я задался вопросом, почему в nginx не поступить так же как это реализовано в том же haproxy? А именно, зачем обязательно писать логи в файл? Почему бы не писать их в rsyslog на соседний сервер.
Плюсы:
не тратим IO
храним безопасно логи на другом сервере
отправляем логи по UDP следовательно если лог сервер ляжет, производительность не упадет никак.
Насколько я понял встроенного решения такого в NGginx нет, но виден в инете несколько модулей
Плюсы:
не тратим IO
храним безопасно логи на другом сервере
отправляем логи по UDP следовательно если лог сервер ляжет, производительность не упадет никак.
Насколько я понял встроенного решения такого в NGginx нет, но виден в инете несколько модулей
Ад, угар и содомия, извините. Подавляющее большинство статьи — чушь, которую просто опасно применять на production.
Звучит неубедительно.
Не пойму, за что минусы? Критика mifa — на уровне школьника. Почему бы не написать, что конкретно не так? И я бы с радостью это исправил. И тысячи читателей получили бы более качественный материал.
Да более-менее грамотным людям и так все понятно…
Треш. После этого статью вообще можно дальше не читать. Вы вообще представляете себе как воркер работает?
Ненужная экономия на логах, 64к сокетов, бешеные таймауты, форсинг epoll — в общем, автор явно не понимает о чем говорит. А учитывая, что автор, судя по всему, не топикстартер, то это еще и просто перевод/компиляция некачественного материала.
Даже не то жалко, что написали фигню. А то, что написали на Хабре — этого могут начитаться начинающие специалисты, а потом применять на практике, вот что страшно.
worker_processes 24;
Треш. После этого статью вообще можно дальше не читать. Вы вообще представляете себе как воркер работает?
Ненужная экономия на логах, 64к сокетов, бешеные таймауты, форсинг epoll — в общем, автор явно не понимает о чем говорит. А учитывая, что автор, судя по всему, не топикстартер, то это еще и просто перевод/компиляция некачественного материала.
Даже не то жалко, что написали фигню. А то, что написали на Хабре — этого могут начитаться начинающие специалисты, а потом применять на практике, вот что страшно.
Так вот чем админы хабра сейчас заняты.
А какая конфигурация сойдёт для
500,000 — 600,000
про sendfile не знал.. думал она поумолчанию включена.. т.к. замерял производительность апача и энжинкса на отдаче статики была разница в 3.5 раза
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Ускоряем Nginx за 5 минут