После года разработки представлена (http://nginx.org/?1.12) новая стабильная ветка высокопроизводительного HTTP-сервера nginx 1.12.0 (http://nginx.org/), которая вобрала в себя изменения, накопленные в рамках основной ветки 1.11.x. В дальнейшем все изменения в стабильной ветке 1.12 будут связаны с устранением серьёзных ошибок и уязвимостей. В скором времени будет сформирована основная ветка nginx 1.13, в рамках которой будет продолжено развитие новых возможностей. Для обычных пользователей, у которых нет задачи обеспечить совместимость со сторонними модулями, рекомендуется (http://nginx.com/blog/nginx-1-6-1-7-released) использовать основную ветку, на базе которой раз в три месяца формируются выпуски коммерческого продукта Nginx Plus.
По данным (https://w3techs.com/blog/entry/nginx_reaches_33_3_percent_we...) W3Techs 33.3% из миллиона самых посещаемых сайтов в мире используют nginx, в апреле прошлого года этот показатель составлял 29.8%, позапрошлого - 23.8%. Доля Apache впервые опустилась ниже 50%, а доля Microsoft IIS составила 11.3%. Если рассматривать только 10 тысяч наиболее крупных сайтов, то доля nginx составляет 39.7%, а Apache - 42.8%. В России nginx используется (http://w3techs.com/technologies/breakdown/ws-nginx/top_level...) на 76.9% самых посещаемых сайтов (год назад - 75.2%).В соответствии с мартовским отчетом (https://news.netcraft.com/archives/2017/03/24/march-2017-web...) компании Netcraft nginx используется на 19.55% (год назад 16.81%, два года назад 14.24%) всех активных сайтов, что соответствует третьему месту по популярности в данной категории (доля Apache соответствует 41.06%, а Microsoft IIS - 24.46% (доля IIS выросла за счёт парковки неиспользуемых доменов)). Доля nginx среди всех сайтов составляет 19.91% (год назад 13.23%, два года назад 14.87%), среди миллиона самых посещаемых сайтов в мире - 25.64% (год назад 25.64%, два года назад 21.43%). В настоящее время под управлением nginx работает около 350 млн сайтов (год назад 143 млн).
Из улучшений (http://nginx.org/ru/CHANGES.ru-1.12), добавленных в процессе формирования основной ветки 1.11.x, можно отметить:- Обеспечена возможность указания нескольких SSL-сертификатов разных типов. Для загрузки сертификатов разных типов (RSA, ECDSA) директивы "ssl_certificate" и "ssl_certificate_key" можно указывать несколько раз;
- Добавлена возможность ограничения максимального числа соединений для директивы server в блоке upstream, через указание параметра max_conns;
- Добавлена новая директива absolute_redirect (http://nginx.org/ru/docs/http/ngx_http_core_module.html#abso...), которая отвечает за абсолютное или относительное перенаправление в nginx;- Добавлена директива "worker_shutdown_timeout (http://nginx.org/en/docs/ngx_core_module.html#worker_shutdow...)", позволяющая задать время ожидания корректного завершения работы рабочих процессов. Если за указанное время рабочие процессы не успеют довести до конца обработку имеющихся запросов, то связанные с ними соединения будут закрыты принудительно;
-
Новые модули
:
- ngx_stream_map_module (http://nginx.org/ru/docs/stream/ngx_stream_map_module.html), позволяющий создавать переменные, значения которых зависят от значений других переменных;- ngx_stream_return_module (http://nginx.org/ru/docs/stream/ngx_stream_return_module.html), который даёт возможность отправить заданное значение клиенту и после этого закрыть соединение;
- ngx_stream_geo_module (https://nginx.org/ru/docs/stream/ngx_stream_geo_module.html), позволяющий создавать переменные, значения которых зависят от IP-адреса клиента;- ngx_stream_geoip_module (https://nginx.org/ru/docs/stream/ngx_stream_geoip_module.html), позволяющий создавать переменные, значения которых зависят от IP-адреса клиента, используя готовые базы MaxMind (http://www.maxmind.com/) для привязки диапазонов адресов к регионам;
- ngx_stream_split_clients_module (https://nginx.org/ru/docs/stream/ngx_stream_split_clients_mo...), позволяющий создавать переменные для A/B тестирования (также известного как "split-тестирование");
- ngx_stream_log_module (http://nginx.org/ru/docs/stream/ngx_stream_log_module.html), позволяющий записывать логи сессий в указанном формате;
- ngx_stream_realip_module (http://nginx.org/ru/docs/stream/ngx_stream_realip_module.html), позволяющий менять адрес и порт клиента на переданные в заголовке протокола PROXY;
- ngx_stream_ssl_preread_module (https://nginx.org/ru/docs/stream/ngx_stream_ssl_preread_modu...), позволяющий извлекать информацию из сообщения ClientHello без терминирования SSL/TLS, например можно получить имя сервера, запрошенное через SNI;
-
Новые переменные
:
- $request_id (http://nginx.org/en/docs/http/ngx_http_core_module.html#var_...), в которой содержится уникальный идентификатор запроса;- $proxy_protocol_port (http://nginx.org/en/docs/http/ngx_http_core_module.html#var_...), содержащая номер клиентского сетевого порта, указанного в заголовке протокола PROXY;
- $upstream_bytes_received (https://nginx.org/en/docs/stream/ngx_stream_upstream_module....), позволяющая получить число байт, полученных от сервера группы. Значения нескольких соединений разделяются запятыми и двоеточиями подобно адресам в переменной $upstream_addr;
- Формат переменных '$ssl_client_s_dn' и '$ssl_client_i_dn' приведён в соответствие с RFC 2253 (RFC 4514). Значения в старом формате доступны через переменные '$ssl_client_s_dn_legacy' и '$ssl_client_i_dn_legacy';
-
Изменения в модулях
:- В модуле ngx_http_image_filter_module добавлена поддержка формата WebP;
- В модуле stream (http://nginx.org/en/docs/stream/ngx_stream_core_module.html) добавлена возможность использования переменных и добавлена проверка клиентских SSL-сертификатов. Если сервер, описанный в блоке upstream, был признан неработающим, то после истечения fail_timeout он признавался работающим только после завершения тестового соединения, теперь достаточно чтобы соединение было успешно установлено;
- В модуле ngx_http_v2_module появилась директива "http2_max_requests", определяющая максимальное число запросов, которые можно сделать по одному соединению при использовании протокола HTTP/2;
- В модуле ngx_http_realip_module добавлена переменная $realip_remote_port (http://nginx.org/en/docs/http/ngx_http_realip_module.html#va...), содержащая номер сетевого порта клиента, с которого было инициировано соединение;- В модулях stream (http://nginx.org/ru/docs/stream/ngx_stream_core_module.html) и ngx_stream_upstream_module (http://nginx.org/ru/docs/stream/ngx_stream_upstream_module.html) добавлены новые переменные:
- $bytes_received - число байт, полученных от клиента;- $session_time - длительность сессии в секундах с точностью до миллисекунд;
- $protocol - протокол, используемый для работы с клиентом: TCP или UDP;
- $status - статус сессии;
- $upstream_addr - хранит IP-адрес и порт или путь к UNIX-сокету сервера группы. Если при проксировании были сделаны обращения к нескольким серверам, то их адреса разделяются запятой, например "192.168.1.1:12345, 192.168.1.2:12345, unix:/tmp/sock";
- $upstream_bytes_sent - число байт, переданных на сервер группы. Значения нескольких соединений разделяются запятыми подобно адресам в переменной $upstream_addr;
- $upstream_bytes_received - число байт, полученных от сервера группы. Значения нескольких соединений разделяются запятыми подобно адресам в переменной $upstream_addr;
- $upstream_connect_time - время установки соединения с сервером группы, время хранится в секундах с точностью до миллисекунд. Времена нескольких соединений разделяются запятыми подобно адресам в переменной $upstream_addr;
- $upstream_first_byte_time - время получения первого байта данных, время хранится в секундах с точностью д...
URL: http://mailman.nginx.org/pipermail/nginx-ru-announce/2017/00...
Новость: http://www.opennet.me/opennews/art.shtml?num=46367
Фух, наконец-то новость о nginx.
А то аж целую неделю ничего не было слышно, я уже волноваться начал! *rolleyes*
1 [05.04.2017] Выпуск nginx 1.11.13
2 [25.03.2017] Выпуск nginx 1.11.12
3 [22.03.2017] Выпуск nginx 1.11.11
4 [15.02.2017] Выпуск nginx 1.11.10
5 [01.02.2017] Обновление nginx 1.10.3
6 [24.01.2017] Выпуск nginx 1.11.9
7 [28.12.2016] Выпуск nginx 1.11.8
8 [14.12.2016] Выпуск nginx 1.11.7
Ну что же вы за люди-то? У них двухнедельный цикл по выпуску mainline-версии. Каждый считает своим долгом их упрекнуть в этом оставив тут свой комментарий?!
Ничего себе изменений в этот раз.
> Временные файлы в каталоге кэша теперь располагаются не в отдельном подкаталоге, а в том же подкаталоге, что и остальные файлы;Сомнительная доработка. Я бы точно такое не стал бы делать.
Напишешь свой сервер и не будешь так делать.
А аргументировать сможешь или просто "патамушо"?
Во-первых, это опция. Во-вторых, она бывает полезна, когда временные файлы расположены на отдельной от остального кэша файловой системе. Почему - предстоит выяснить вам. Но только после того, как сделаете уроки! Я проверю!
Если вчитаться в текст "Временные файлы в каталоге кэша теперь располагаются не в отдельном подкаталоге, а в том же подкаталоге, что и остальные файлы", то не ясно остюда что это опция. Поэтому ваше "во-первых" - пшик.
И во-вторых, ваше "во-вторых" снова пшик, т.к. именно когда нужно (а оно бывает нужно) например кэш вынести в отдельную ФС или носитель, то как раз нужно располагать отдельно от временных.
Ну и в третьих, вам бы ума или фантазии, а то читать чушь про уроки несколько поднадоело.ps: только не распускайте свои сопли и не устраивайте здесь флуд
Дело в том, что nginx перед тем, как переместить файл в директорию с кэшом, вначале пишет во временный файл в директории для временных файлов. Объяснять, почему хорошо бы иметь обе директории на одной фс надеюсь не надо?
Увеличение коллизии, праздник какой то!!!!
>Добавлена возможность ограничения максимального числа соединений для директивы server в блоке upstream, через указание параметра max_conns;Красавцы!!!!
Уже поставил. Старый конфиг подошел
Я так понимаю рекомендуется использовать основную ветку так как им нужны тестеры на баги?
как эту статистику считают. у нас на входе стоит балансер F5, который распределяет нагрузку и кеширование на несколько nginx. nginx никогда бы с таким количеством SSL соединений не справился бы
Ну, так и считают )
Результаты статистика никогда нельзя признавать достоверными на 100%
> nginx никогда бы с таким количеством SSL соединений не справился быС каким количеством, если не секрет?
>> nginx никогда бы с таким количеством SSL соединений не справился бы
> С каким количеством, если не секрет?для начала хотя бы с 1000 новыми SSL соединениями в секунду. SSL Offload
> для начала хотя бы с 1000 новыми SSL соединениями в секунду. SSL
> Offloadведь это не проблема nginx, а все упирается в нижележащих мощностей на чем оно работает (ресурсы железа). SSL Offload иногда зачастую передают на плечи HAProxy для большой производительности.
>> для начала хотя бы с 1000 новыми SSL соединениями в секунду. SSL
>> Offload
> ведь это не проблема nginx, а все упирается в нижележащих мощностей на
> чем оно работает (ресурсы железа). SSL Offload иногда зачастую передают на
> плечи HAProxy для большой производительности.Так я к тому и веду, что статистика - чуть менее, чем полностью не правильная. nginx в первую очередь обеспечивает проход трафика, может быть его частичную модификацию. Все остальное на себя берут все остальные системы.
Даже на дохлом ноутбуке справится. Не распространяйте ЛПП, пожалуйста.Протестил. На моем core i7 4700hq 1700 хендшейков в секунду.
> Даже на дохлом ноутбуке справится. Не распространяйте ЛПП, пожалуйста.
> Протестил. На моем core i7 4700hq 1700 хендшейков в секунду.так надо не только установить соединение, но еще и обслужить желательно ;)
Это не зависит от конкретного веб-сервера и выносится за скобки. Факты говорят о том, что производительность nginx значительно выше, чем вы утверждаете. На типичном сервере с 16 физ. ядрами при обработке 1000 хендшейков в секунду примерно 80% процессорного времени будет свободно для других задач.P.S. Естественно, тест проводился с полноценной обработкой запроса, а не с голыми хендшейками.
Да, что-то наговариваете на nginx по поводу того, что он не сможет обслуживать указанное количество
> для начала хотя бы с 1000 новыми SSL соединениями в секунду. SSL
> OffloadДернул ab на одном из балансирующих серверов. Где-то 1160 per server. Хотя признаю, ожидал большего.
Проблема у жизни с внешним балансером в том, что привыкаешь к тем теплым ламповым условиям, которые он дает. А когда его опускаешь и пускаешь трафик прямо в nginx, случается "ой, втупляет, надо тюнить".
Посмотрите доклад Дмитрия Смирнова когда он еще работал в TNS, там он рассказывает как они считают статистику, довольно занятное чтиво да и человек он приятный когда трезвый.
Прекрасно справляется и с 10К. Зависит только от железа. С openssl 1.0.2 очень хорошо перформит.
Комрады, имейте в виду, что в 1.11.10 изменен формат заголовка кэша, ранее хранившиеся в кэше ответы теперь будут загружены заново;
Отсюда: https://www.opennet.me/opennews/art.shtml?num=46048Я так понимаю, это приехало и в 1.12.
После обновления до 1.12 ваш proxy_cache может внезапно инвалидироваться весь.
Приехало. Не может, а совершенно точно инвалидируется.
Думаю, придется сначала запустить 1.12 рядом, настроить ему кэш в другую директорию и "прогреть" его.