Доступен (http://mailman.nginx.org/pipermail/nginx-ru-announce/2016/00...) новый выпуск основной ветки высокопроизводительного HTTP-сервера nginx 1.11.4 (http://nginx.org/), в котором реализованы следующие изменения:
- Добавлена переменная $upstream_bytes_received позволяющая получить число байт, полученных от сервера группы. Значения нескольких соединений разделяются запятыми и двоеточиями подобно адресам в переменной $upstream_addr;
- Добавлены новые переменные в модуле 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 - время получения первого байта данных, время хранится в секундах с точностью до миллисекунд. Времена нескольких соединений разделяются запятыми подобно адресам в переменной $upstream_addr;
- $upstream_session_time - длительность сессии в секундах с точностью до миллисекунд. Времена нескольких соединений разделяются запятыми подобно адресам в переменной $upstream_addr.
- Добавлен новый модуль ngx_stream_log_module (http://nginx.org/ru/docs/stream/ngx_stream_log_module.html), позволяющий записывать логи сессий в указанном формате;
- Добавлен параметр proxy_protocol в директиве listen и переменные $proxy_protocol_addr и $proxy_protocol_port в модуле stream;
- Добавлен новый модуль ngx_stream_realip_module (http://nginx.org/ru/docs/stream/ngx_stream_realip_module.html), позволяющий менять адрес и порт клиента на переданные в заголовке протокола PROXY;
- Исправлена ошибка, когда nginx не собирался с модулем stream и модулем
ngx_http_ssl_module;
- Исправлена опция сокета, когда опция IP_BIND_ADDRESS_NO_PORT не использовалась;
- Исправлен параметр ranges в директиве geo;
- Исправлена ошибка, которая могла возвращать некорректный ответ при использовании директив "aio threads" и "sendfile".
URL: http://mailman.nginx.org/pipermail/nginx-ru-announce/2016/00...
Новость: http://www.opennet.ru/opennews/art.shtml?num=45141
Интересно, а Апач еще пользуется популярностью, в сравнении с nginx?
nginx уже умеет все, что умеет апач?
да, ещё как
А тебе зачем?
Ему мама сказала, что дружить нужно только с популярными...
Он просто тащится от жабоскрипта в конфигах nginx(
Сравнение некорректное. Эти инструменты используются для решения задач разного плана, плюс они часто используются вместе.https://news.netcraft.com/archives/2016/06/22/june-2016-web-...
> они часто используются вместеВозникает резонный вопрос - нахрена.
Это же очевидно, для решения определенных задач. Например может быть нужда в апачевском mod_чего_нибудь или в .htacces, но при этом необходимость нормально держать нагрузку или в диспетчере/балансировщике.
Haproxy+Apache = связка нормального человека, остальное наркомания)
>> они часто используются вместе
> Возникает резонный вопрос - нахрена..htaccess же, многие "web-приложения" не работают нормально без этой "лапши" и проще поставить nginx+apache (или даже просто apache (он и умеет и кэш и сжатие)), чем заставить работать через nginx+php-fpm (например).
Есть такое.
Но авторам такого нужно прижимать головы асфальтоукладочными катками.
это то да. да вот только mod_php работает только в связке с prefork, который хренеет от медленных клиентов. да, можно подключить к apache php-fpm и переключить индейца в event mode, но в apache в event mode больше граблей, чем в nginx. вот в итогде и имеем прижившуюся структуру: nginx->apache+mod_php.
Например mod_php шустрее php-fpm. Пруфы легко гуглятся.
> Например mod_php шустрее php-fpm. Пруфы легко гуглятся.Чё то у меня гуглится строго наоборот.
Сравнивал на своих проектах. Нагрузка от 400 до 5000 заросов в секунду.
http://pix.toile-libre.org/upload/original/1473848027.png
Разницы между php-fpm и apache2 никакой.
Вообще-то они одинаковы. Разве что если тестировать хеловордом и сравнивать nginx+php-fpm против apache+mod_php, а не nginx+apache+mod_php. Тогда тест покажет оверхед от коммуникации через fastcgi. Но если взять скрипт посложнее, то разница в скорости окажется в пределах погрешности.
Разумеется это всё при условии отключения .htaccess в апаче, в противном случае nginx+php-fpm покажет серьезное преимущество в скорости, на чем многие прокалываются.
Тестировал две связки в продакшене, на реальных запросах.
Как писал выше нагрузка на пике (примерно в 9 вечера) доходит до 5000 запросов в секунду.
nginx + php-fpm vs nginx + apache + mod_php.Результаты практически одинаковы.
Тебе об этом и написали.
Это — инструменты для решения одной задачи, отдачи веб-контента. В 99% случаев индеец заменяется на nginx с полпинка и серверу становится гораздо легче, а вот в 1% случаев наталкиваемся на диковинную самопИсь, в которой половина функций делается через htaccess и там фиг так просто перенесешь. За последние несколько лет я натолкнулся дважды на чудеса которые не переносятся нормально на nginx+что-то(php-fpm и ко), в одном случае автор самописи сгинул где-то в недрах истории и все работает как есть, пришлось просто ставить nginx в качестве фронт-энда, во втором автор занимается движком и сказал, что готовит следующую версию без заморочек с htaccess, а нынешняя версия пусть работает, как есть, все равно ей жить год-полтора, не больше.
Очевидно Вы никогда не админили сервера, которые используются для shared хостинга.
У тебя на сервере 2 000 сайтов. Все сайты разных клиентов, их поддерживают разные веб-разработчики. Типичная задача - сделать редиректы. Каким образом Вы будете объяснять тех. поддержке (которая это должна объяснить клиентам), что у нас нет поддержки htaccess, а доступ к конфигам nginx мы дать не можем, потому что это небезопасно.
Каким образом Вы настроете связку nginx+php fastcgi, так чтобы каждый сайт работал под своим пользователем?
И еще куча вопросов которые нужно решать.
> Каким образом Вы настроете связку nginx+php fastcgi, так чтобы каждый сайт работал под своим пользователем?Вот как раз это совсем не сложно, штатная возможность у php-fpm.
> И еще куча вопросов которые нужно решать.
Есть и встречные, например как сделать, чтобы нагрузка на один сайт не валила остальные. С php-fpm это решается чуть проще, чем с апачем.
> Очевидно Вы никогда не админили сервера, которые используются для shared хостинга.10 лет не занимался сим глупым и бесполезным делом
> Каким образом Вы настроете связку nginx+php fastcgi, так чтобы каждый сайт работал под своим пользователем?
google://php-fpm pool
Все прекрасно работает под разными пользователями и не жужжит.> а доступ к конфигам nginx мы дать не можем, потому что это небезопасно.
Про инклюды не слышали?
Ну и шаред-хостинги — зоонекрофилия, шареды чуть ли не дороже виртуалок ныне и не имеют смысла.
>> а доступ к конфигам nginx мы дать не можем, потому что это небезопасно.
> Про инклюды не слышали?Твердая пятерка по админскому долбоклюйству. А ведь тебе даже ключевое слово дали - безопасность.
>Ну и шаред-хостинги — зоонекрофилия, шареды чуть ли не дороже виртуалок ныне и не имеют смысла.
Это смотря в чьих руках. Не сомневаюсь, что если за их организацию возьмешься ты, то может и дороже получится.
> 10 лет не занимался сим глупым и бесполезным деломНормальное и обычное дело, админить сервера которые предоставляют услуги shared,VPS (LXC,OpenVZ,KVM) хостинга, довольно интересное занятие. Автоматизировать кучу работы с помощью puppet тоже занятно. Не вижу тут ничего глупого. Или нужно убрать из рынка все хостинги, потому что это по Вашему "глупо". Я если честно не понял Вас.
> Про инклюды не слышали?Я то об инклюдах слышал, но видимо Вы о безопасности ничего не слышали.
> Ну и шаред-хостинги — зоонекрофилия, шареды чуть ли не дороже виртуалок ныне и не имеют смысла.Например имеет смысл брать тем людям, которые не имеют скилов настройки веб-серверов, СУБД, хранилищь для кэша, php и т.д. Или тем, кто не хочет платить человеку, который будет это все делать за него.
> Все прекрасно работает под разными пользователями и не жужжит.
Спасибо. Буду знать.
Назовите пожалуйста хотя бы 5-10 shared хостингов, которые не используют apache2.
> не имеют скилов настройки веб-серверов, СУБД, хранилищь для кэша, php и т.д.Гнать из отрасли ссаными тряпками.
> Гнать из отрасли ссаными тряпками.Клиентов ? Вы, любезный, тогда бутылки собирать по помойкам будете.
> В 99% случаев индеец заменяется на nginx с полпинка и серверу становится гораздо легчеБез цифр это трололо.
Там где ресурсов много обычно используется Апач, чтобы не появлялось ощущение того, что оборудование простаивает.
Зачастили как-то релизы nginx-а...
Деньги, просто деньги...
> Деньги, просто деньги...Не завидуй деньгам в чужих карманах.
nginx 1.0.0 12 Apr 2011
nginx 1.2.0 23 Apr 2012
nginx 1.4.0 24 Apr 2013
nginx 1.6.0 24 Apr 2014
nginx 1.8.0 21 Apr 2015
nginx 1.10.0 26 Apr 2016Совершенная стабильность выпуска релизов.
Ты где увидел зависть? Так что иди ....
С момента выхода nginx 1.0.0 релизы стабильной ветки идут раз в году в апреле месяце.nginx 1.0.0 12 Apr 2011
nginx 1.2.0 23 Apr 2012
nginx 1.4.0 24 Apr 2013
nginx 1.6.0 24 Apr 2014
nginx 1.8.0 21 Apr 2015
nginx 1.10.0 26 Apr 2016За год разработки в нестабильной ветке выходит от 12 до 15 «релизов», в зависимости от накопления изменений и/или необходимости выпуска баг-фиксов.
Таким образом можно говорить, что nginx абсолютно стабилен по количеству «релизов» в нестабильной ветке и совершенно стабилен в выпуске релизов ветки стабильной.
>> Зачастили как-то релизы nginx-а...
> nginx абсолютно стабилен по количеству «релизов» в нестабильной ветке и совершенно стабилен в выпуске релизов ветки стабильной.Да, стабилен. И я тоже стабильно коментирую каждый релиз.
Update: Andrey Mitrofanov, в июне я обещал тебе перестать постить этот коммент. Я пытался перестать, но не смог. Извини.
>Я пытался перестать, но не смог. Извини.Караул! Милиция!! Фулюганы!!1
Наверно скоро какие-нибудь побитные маски введёт.
Жаль, что некогда простой и лёгкий сервер становится монстром
лёгким монстром :)а вообще, такое характерно для любого успешного продукта.
Монстры вытесняют в динамические модули.
Каким бы монстром небыл стоит учесть, что он стабильный и производительный. Другим опен сурс проектам стоит поучится у команды разработчиков nginx.
модульная архитектура существенно сглаживает монструозность.
Это вы с чего взяли?Больше модулей - да. Но никто не заставляет собирать модули, которые не нужны.
Само ядро какое было - такое и осталось.