Мы рады представить бету NGINX Amplify, нашего нового инструмента для мониторинга NGINX и NGINX Plus. Используя NGINX Amplify, вы сможете отслеживать и контролировать NGINX и приложения, которые он обслуживает. Новый инструмент позволит быстро решать проблемы с производительностью и доступностью отдельных сервисов и инфраструктуры в целом. На текущий момент он включает в себя гибко настраиваемую панель мониторинга с механизмом оповещений, а также систему автоматических рекомендаций по оптимизации производительности и улучшению безопасности.

Узнать больше и увидеть NGINX Amplify в действии можно записавшись на онлайн вебинар, который пройдет 13 июля в 20:00 по московскому времени.

Также, вы можете начать бесплатно использовать NGINX Amplify прямо сейчас, пройдя регистрацию.

Давным давно, в начале 1989 года, Рональд Рейган ещё был президентом, хотя до окончания его срока оставалось 19½ дней. А перед тем, как 1989 год подошел к концу, родилась Тейлор Свифт, а Андрей Сахаров и Сэмюэл Беккет скончались.

В долгосрочной перспективе, наиболее значительным событием 1989 скорее всего станет то, что Тим Бернерс-Ли заложил основы протокола HTTP и назвал результат «World Wide Web». (Одно примечательное свойство этого имени состоит в том, что аббревиатура «WWW» имеет в два раза больше слогов и требует больше времени для произнесения.)

Протокол HTTP, предложенный Тимом, работал в 10-мегабитных сетях с коаксиальными кабелями, а его компьютером был NeXT Cube с частотой 25 МГц. 26 лет спустя, в моем ноутбуке установлен процессор в сотни раз быстрее, а оперативной памяти в тысячи раз больше, чем было на компьютере Тима, но протокол HTTP всё тот же.

Несколько дней назад рабочая группа IESG (The Internet Engineering Steering Group) запросила последние комментарии по новому протоколу HTTP/2.0 (https://tools.ietf.org/id/draft-ietf-httpbis-http2) перед тем, как утвердить его в качестве официального стандарта.

[Спустя пару месяцев с минимальными изменениями стандарт был утвержден. — прим. пер.]

Disclaimer: оригинальная статья, перевод которой здесь представлен, служит цели объявить о выходе новых старших версий продукта, рассказать в целом о политике версионирования и успехах за прошедший год. Если вас интересуют сухие технические подробности, то рекомендую смотреть полный лог изменений, либо его выжимку с кратким пояснением в конце статьи.

Мы рады представить NGINX 1.10 и 1.11. Эти номера версий обозначают стабильную (stable) и основную (mainline) ветки бесплатных открытых выпусков, над которыми мы сфокусируем наши усилия на протяжении следующих 12 месяцев.

NGINX версии 1.10.0 уже вышел, а будущий выпуск основной ветки будет под номером 1.11.0.

Как известно, для обработки соединений NGINX использует асинхронный событийный подход. Вместо того, чтобы выделять на каждый запрос отдельный поток или процесс (как это делают серверы с традиционной архитектурой), NGINX мультиплексирует обработку множества соединений и запросов в одном рабочем процессе. Для этого применяются сокеты в неблокирующем режиме и такие эффективные методы работы с событиями, как epoll и kqueue.

За счет малого и постоянного количества полновесных потоков обработки (обычно по одному на ядро) достигается экономия памяти, а также ресурсов процессора на переключении контекстов. Все преимущества данного подхода вы можете хорошо наблюдать на примере самого NGINX, который способен обрабатывать миллионы запросов одновременно и хорошо масштабироваться.

Каждый процесс расходует память и каждое переключение между ними требует дополнительных циклов процессора, а также приводит к вымыванию L-кэшей

У медали есть и обратная сторона. Главной проблемой асинхронного подхода, а лучше даже сказать «врагом» — являются блокирующие операции. И, к сожалению, многие авторы сторонних модулей, не понимая принципов функционирования NGINX, пытаются выполнять блокирующие операции в своих модулях. Такие операции способны полностью убить производительность NGINX и их следует избегать любой ценой.

Но даже в текущей реализации NGINX не всегда возможно избежать блокировок. И для решения данной проблемы в NGINX версии 1.7.11 был представлен новый механизм «пулов потоков». Что это такое и как его применять разберем далее, а для начала познакомимся с нашим врагом в лицо.

NGINX вполне заслуженно является одним из лучших по производительности серверов, и всё это благодаря его внутреннему устройству. В то время, как многие веб-серверы и серверы приложений используют простую многопоточную модель, NGINX выделяется из общей массы своей нетривиальной событийной архитектурой, которая позволяет ему с легкостью масштабироваться до сотен тысяч параллельных соединений.

Инфографика Inside NGINX сверху вниз проведет вас по азам устройства процессов к иллюстрации того, как NGINX обрабатывает множество соединений в одном процессе. Данная статья рассмотрит всё это чуть более детально.

В NGINX версии 1.9.1 появилась новая возможность, позволяющая использовать сокетную опцию SO_REUSEPORT, которая доступна в современных версиях операционных систем, таких как DragonFly BSD и Linux (ядра 3.9 и новее). Данная опция разрешает открывать сразу несколько слушающих сокетов на одном и том же адресе и порту. При этом, ядро будет распределять входящие соединения между ними.

С радостью объявляем о выходе новых релизов NGINX 1.8 стабильной (stable) ветки и NGINX 1.9 основной (mainline) ветки, в рамках которой будет продолжаться разработка новой функциональности. Новые ветки релизов заменяют 1.6 и 1.7 соответственно.

За последний год в 1.7 было выпущено 12 версий, и все новые возможности, которые в них появились, теперь доступны в 1.8, включая:

• Проверку SSL сертификатов бэкендов — Призвана защитить соединения с upstream-серверами от MITM-атак;
• Логирование в syslog — Позволяет передавать логи по сети посредством UDP-сообщений;
• Пулы потоков для выполнения блокирующих операций ввода-вывода — Увеличивают производительность NGINX в ситуациях, когда блокировка на чтении с диска неизбежна;
• Новый метод балансировки нагрузки “hash” — Позволяет выбирать сервер из группы базируясь на хэше от произвольной переменной;
• Небуферизированный прием тела запроса — Позволяет передавать запрос на бэкенд сразу, не дожидаясь окончания приема тела запроса целиком.

Полный список нововведений за последний год можно посмотреть в логе изменений для 1.8.

Вчера, 24 апреля, был анонсирован релиз NGINX 1.6 и 1.7. Эта статья объясняет, как планируются релизы NGINX и значение этого изменения нумерации версий.

NGINX 1.6 отделился от текущей основной (mainline) ветки 1.5, а последняя была перенумерована в 1.7. Это ежегодное событие, когда берется текущая основная ветка с новой функциональностью и от нее ответвляется новая стабильная (stable) ветка. Разработка активно продолжается на уже перенумерованной основной ветке.


Версия 1.4 более не поддерживается. Основная ветвь 1.5 была форкнута для создания стабильной 1.6 и перенумерована в 1.7.

На прошлой неделе Максим Дунин разместил в англоязычном списке рассылки разработчиков Nginx сообщение с просьбой потестировать патч, добавляющий полноценную (включая chunked-ответы) поддержку Keep-Alive соединений (при использовании upstream keepalive модуля) с http, fastcgi и memcached бэк-энд серверами.

Во избежание кривотолков, напомню, что Nginx обладает прекрасной поддержкой протокола HTTP 1.1 и Keep-Alive соединений с клиентами. Однако, постоянные соединения с http бэк-эндами не поддерживаются. На то были свои причины.

Первоначально хотел оформить как топик-ссылку, но тогда не получилось бы вставить картинку:

а она всё иллюстрирует, как нельзя лучше. Если картинка вас заинтересовала, то вы можете сразу пройти на открытый по случаю релиза сайт, или заглянуть под хабракат за комментами и некоторыми моими мыслями.

Позднее, как появится свободное время, напишу более подробную пошаговый HowTo, что вообще можно и что нужно делать с модулем, как можно представить MVC в виде: M — ваши сервисы, V — этот модуль и C — Nginx.