После года разработки и 16 экспериментальных выпусков в тестовой ветке 1.3.x представлена (http://mailman.nginx.org/pipermail/nginx-announce/2013/00010... новая стабильная версия высокопроизводительного HTTP-сервера nginx 1.4.0 (http://nginx.org/). В дальнейшем все изменения в новой стабильной ветке будут связаны с устранением ошибок и внесением незначительных улучшений, не нарушающих API. Все существенные изменения будут развиваться в рамках новой экспериментальной ветки 1.5.x.
В соответствии с апрельским (http://news.netcraft.com/archives/2013/04/02/april-2013-web-... отчетом компании Netcraft nginx используется на 12.91% всех активных сайтов, что соответствует второму месту по популярности в данной категории (доля Apache соответствует 51.01%, а Microsoft IIS - 12.13%). Доля nginx среди всех сайтов составляет 14.81%, среди миллиона самых посещаемых сайтов в мире - 12.96%, среди 10 тысяч наиболее крупных ресурсов - 30%, среди сайтов, работающих на платформе Amazon AWS, - 44%. В настоящее время под управлением nginx работает около 96.1 млн сайтов, что на 26.3 млн больше чем год назад. По данным (http://w3techs.com/technologies/overview/web_server/all) W3Techs 16.1% из миллиона самых посещаемых сайтов в мире используют nginx, в апреле прошлого года этот показатель составлял 11%. В России nginx используется (http://w3techs.com/technologies/breakdown/ws-nginx/top_level... на 66.3% самых посещаемых сайтов (год назад - 58.2%).
Из улучшений (http://nginx.org/ru/CHANGES.ru-1.4), добавленных в процессе формирования экспериментальной ветки 1.3.x, можно отметить:
- Интеграция модуля ngx_http_spdy_module (http://nginx.org/ru/docs/http/ngx_http_spdy_module.html) с реализацией протокола SPDY, который продвигается для включения в состав будущего стандарта HTTP/2.0. SPDY был создан специально для минимизации задержек при соединении и обмене данными между клиентом и сервером. По данным Google ускорение загрузки страниц при использовании SPDY составляет от 15% до 50%. SPDY добавляет сеансовый уровень поверх SSL, что даёт возможность обеспечить передачу нескольких одновременных потоков в рамках одного TCP-соединения. При использовании HTTP запросы в рамках одного потока обслуживаются последовательно, задействование SPDY даёт возможность мультиплексировать запросы ресурсов, обрабатывать их параллельно и отправлять запросы с учетом динамически рассчитываемых приоритетов, увеличивая текущую пропускную способность. Использование SSL одновременно позволяет решить проблему с прохождением запросов через прокси серверы и позволяет организовать доставку данных по инициативе сервера, без специального запроса клиента (технология Server push). Дополнительное ускорение достигается за счёт сжатия HTTP-заголовков запроса и ответа, что уменьшает размер передаваемых данных и заметно ускоряет загрузку страниц, порождающих большое число мелких запросов (CSS, JavaScript файлы, картинки), особенно при использовании медленных каналов связи.- Поддержка работы в роли прокси для соединений WebSocket (http://nginx.org/ru/docs/http/websocket.html). Поддержка WebSocket-соединений в модулях ngx_http_uwsgi_module и ngx_http_scgi_module. Протокол WebSocket разработан для решения проблемы с организацией двустороннего надёжного обмена данными между web-приложением и сервером. По своей сути WebSockets является своеобразным аналогом TCP для Web и позволяет в произвольном порядке инициировать отправку данных от сервера к web-приложению, а не только от web-приложения к серверу. Сам протокол не использует "сырые" TCP-соединения или множественные HTTP-запросы, вместо этого постоянное соединение поддерживается в рамках единого с HTTP канала передачи данных, по которому не передаётся лишних HTTP-заголовков. Установив WebSocket-соединение между сервером и клиентом, разработчик может отправить данные из web-браузера при помощи метода send() и получить отправленные со стороны сервера данные через установку специального обработчика событий;
- Добавлен модуль ngx_http_gunzip_module (http://nginx.org/ru/docs/http/ngx_http_gunzip_module.html) с реализацией фильтра, позволяющего распаковывать на стороне nginx ответы серверов, сжатые методом gzip, если клиент не поддерживает gzip-сжатие. Таким образом появляется возможность хранить все прокэшированные ответы в сжатом виде, что достаточно сильно экономит дисковое пространство;
- В модуле ngx_http_ssl_module появилась (http://nginx.org/ru/docs/http/ngx_http_ssl_module.html#ssl_s... поддержка механизма OCSP stapling (http://en.wikipedia.org/wiki/OCSP_stapling), позволяющего выполнять проверку статуса TLS/SSL-сертификатов на OCSP-серверах и оперативно реагировать на факты отзыва сертификатов;
- Добавлены директивы: limit_req_status (http://nginx.org/ru/docs/http/ngx_http_limit_req_module.html... (http://nginx.org/ru/docs/http/ngx_http_limit_conn_module.htm... image_filter_interlace (http://nginx.org/ru/docs/http/ngx_http_image_filter_module.h... real_ip_recursive (http://nginx.org/ru/docs/http/ngx_http_realip_module.html#re... geoip_proxy (http://nginx.org/ru/docs/http/ngx_http_geoip_module.html#geo... и geoip_proxy_recursive (http://nginx.org/ru/docs/http/ngx_http_geoip_module.html#geo...
- Добавлена поддержка переменных в директивах proxy_bind, fastcgi_bind, memcached_bind, scgi_bind и uwsgi_bind;
- В почтовом прокси-сервере добавлена поддержка IPv6-бэкендов;
- Переменные (http://nginx.org/ru/docs/http/ngx_http_log_module.html#log_f... $status, $pipe, $request_length, $time_iso8601, $request_time,$bytes_sent, $connection, $connection_requests, $msec и
$time_local теперь можно использовать не только в директиве
log_format;
- В модуль ngx_http_geoip_module добавлена поддержка IPv6. Директива geo теперь поддерживает IPv6 адреса в формате CIDR;
- При использовании директивы include с маской на
Unix-системах включаемые файлы теперь сортируются в алфавитном порядке;
- Директивы proxy_pass, fastcgi_pass, scgi_pass, uwsgi_pass
и директива server в блоке upstream теперь поддерживают IPv6-адреса. В директиве resolver теперь можно указывать порт и
задавать IPv6-адреса DNS-серверов;
- Поддержка автоматической настройки директивы worker_processes в зависимости от числа процессорных ядер в системе (параметр auto);
- Поддержка компилятора Clang;
- Добавлена поддержка директивы least_conn (http://nginx.org/ru/docs/http/ngx_http_upstream_module.html#... в блоке upstream, которая задаёт для группы метод балансировки нагрузки, при котором запрос передаётся серверу с наименьшим числом активных соединений, с учётом весов серверов. При использовании директивы ip_hash (http://nginx.org/ru/docs/http/ngx_http_upstream_module.html#... теперь можно задавать веса серверов.
URL: http://mailman.nginx.org/pipermail/nginx-announce/2013/00010...
Новость: http://www.opennet.ru/opennews/art.shtml?num=36777
Молодцы! Дальнейшего развития и долгой жизни проекту!
Спасибо Сысоеву, отличный софт.
Ну что, ждём громкого форка по примеру вебкита и мариидб?
К чему бы это? Сталбильный и сильный проект, набирающий всю большую популярность.
*Стабильный
> СталбильныйФикс заглючен.
Уже есть форк:Из фич имеется только, пожалуй, единственная, но крайне интересная, особенность - динамическая загрузка модулей. Проект поддерживает контакт с апстримом.
Made in china
О, прямо как Ubuntu!
Ты имеешь в виду Ubuntu Chinese Edition? Но это не форк. Потрудись выражать свою мысль точнее и не старайся не путаться в наименованиях.
> Из фич имеется только, пожалуй, единственная, но крайне интересная, особенность - динамическая загрузка модулей. Проект поддерживает контакт с апстримом.У них ещё syslog из коробки.
Taobao наверное крупнейший шоп-портал Китая, поэтому форк они делали под себя, включает оно не только DSO, но еще и некоторые патчи, которые не были приняты в апстрим nginx по разным соображениям.
Есть еще http://openresty.org/ тоже интересный проект
Он же просто набор модулей.А сами модули - крайне интересны, да. ngx_lua особенно, умеющий LuaJIT2.
>ngx_lua особенно, умеющий LuaJIT2.
> Он же просто набор модулей.
> А сами модули - крайне интересны, да. ngx_lua особенно, умеющий LuaJIT2.trollface.png
знаю ОС, где nginx если собирать с поддержкой lua юзается luajit, с нулевой головной болью пользователя
в каком он месте интересен? там обычный nginx+набор 3rd party модулей
а, еще там афтар мудаг и configure у него на перд
Игорь, так держать !
там Максим Дунин в основном ворочает всем теперь в плане разработки :)
Сысоев разве что идейно руководит
Сысоев в интервью говорил, что вторую версию уже пишет, с блэкджеком и сами знаете чем.
Некоторые новшества очевидны, некоторые приятный, некоторые непонятны...
только имеет смысл для высоконагруженных проектов
для любых, экономия памяти и ресурсов ...
> для любых, экономия памяти и ресурсов ...Если есть 4Гб ОЗУ и количество одновременно работающих пользователей сервера (серверной или какой-нибудь легкой версии Linux с графикой) в пределах сотен, достаточно Apache. Попросту - вы не заметите разницы. Кроме того, хотя сабж крайне прост в настройках и отлично документирован, используемое вами приложение может требовать Apache (либо, например, у вас может не быть специалистов для нетривиальной настройки, а пакет "из коробки" вас устраивает).
Поэтому, говоря о любых проектах, я бы не был столь категоричен.
>> для любых, экономия памяти и ресурсов ...
> Если есть 4Гб ОЗУ и количество одновременно работающих пользователей сервера (серверной
> или какой-нибудь легкой версии Linux с графикой) в пределах сотен, достаточно
> Apache.всегда есть возможность отхватить digg(хабр итд итп)эффект, в любом случае статистика массового использования nginx кажет не только чистые nginx'ы, но и варианты проксирования
nginx -> apache в бэкэнде, совместимость и преимущества apache тут сохраняются практически полностью, для тех кто не любит новое или что-либо менять.
>в любом случае статистика массового использования nginx кажет не только чистые nginx'ы, но и варианты проксирования nginx -> apache в бэкэнде, совместимость и преимущества apache тут сохраняются практическиДумаю, nginx используется как прокси процентах в 90, а чисто как http сервер, оставшиеся 10 % не более. Поэтому говорить о популярности nginx как web сервера можно с большой натяжкой...
возможности оценить достоверно _что ж там за нжинксом?_ нет, так что всё на уровне предположений, опять же если брать число сайтов, то большинство живут как раз "в общагах" всяких жутких хостингов, так что наверное будет даже больше 90%
Впрочем, nginx в своей нише тоже не единственный, иностранцы часто пользуются вместо nginx'a lighttpd, или в роли реверс-прокси apache+mod_proxy (зачастую даже версии 1.3.х), или varnish.
Он в роли прокси и работает, by design, если только статику не раздаёт.
А статику ему стоит отдать, даже если он перед апачем стоит - бонус огромный.
Ну и других плюшек хватает, чтобы использовать даже на дешёвом хостинге (особенно на дешёвом).
>>в любом случае статистика массового использования nginx кажет не только чистые nginx'ы, но и варианты проксирования nginx -> apache в бэкэнде, совместимость и преимущества apache тут сохраняются практически
> Думаю, nginx используется как прокси процентах в 90, а чисто как http
> сервер, оставшиеся 10 % не более. Поэтому говорить о популярности nginx
> как web сервера можно с большой натяжкой...Когда apache стоит бэкендом и только занимается тем, что шедулит скрипты, то он уже самый настоящий application-сервер. Так что говорить о популярности nginx как web-сервера можно и нужно всегда.
>> для любых, экономия памяти и ресурсов ...
> Если есть 4Гб ОЗУ и количество одновременно работающих пользователей сервера (серверной
> или какой-нибудь легкой версии Linux с графикой) в пределах сотен, достаточно
> Apache. Попросту - вы не заметите разницы. Кроме того, хотя сабж
> крайне прост в настройках и отлично документирован, используемое вами приложение может
> требовать Apache (либо, например, у вас может не быть специалистов для
> нетривиальной настройки, а пакет "из коробки" вас устраивает).
> Поэтому, говоря о любых проектах, я бы не был столь категоричен.В любых проектах конфигурить nginx в 100 крат проще и приятней.
> для любых, экономия памяти и ресурсов ...во времена нынешних цен на память и компутерных мощностей - если вам приходится экономить ресурсы и память, то проект скорей все высоконагруженный ))
>> для любых, экономия памяти и ресурсов ...
> во времена нынешних цен на память и компутерных мощностей - если вам
> приходится экономить ресурсы и память, то проект скорей все высоконагруженный ))забываете VPS решения, не у всех есть необходимость ставить выделенный сервер в стойку,
а вот VPS за очень низкую цену вполне хватит, памяти там как раз будет весьма немного для "жирного индейца" с его форками для каждого соединения или multithreaded тоже кушает весьма и весьма много, а вот nginx+php-fpm + почтовый сервер могут уже работать на 64Мб памяти (разумеется далеко не весело, но работать это будет и даже не станет тормозить для пары одновременных пользователей), хотя минимальные VPS сейчас 256Мб (OpenVZ SLM) практически у любого жлобо-хостера
>[оверквотинг удален]
>> приходится экономить ресурсы и память, то проект скорей все высоконагруженный ))
> забываете VPS решения, не у всех есть необходимость ставить выделенный сервер в
> стойку,
> а вот VPS за очень низкую цену вполне хватит, памяти там как
> раз будет весьма немного для "жирного индейца" с его форками для
> каждого соединения или multithreaded тоже кушает весьма и весьма много, а
> вот nginx+php-fpm + почтовый сервер могут уже работать на 64Мб памяти
> (разумеется далеко не весело, но работать это будет и даже не
> станет тормозить для пары одновременных пользователей), хотя минимальные VPS сейчас 256Мб
> (OpenVZ SLM) практически у любого жлобо-хостеранет не забываю - вы хотя бы пытались понять что я написал?
как раз таки вы не хотите понимать, что экономить = использовать по максимуму, и не нужно тащить bloatware в систему для задач, которые выполняются на гораздо меньшем количестве имеющихся ресурсов, ну а если оставшееся девать некуда - можно еще что-то запустить на той же железяке.В случае nginx vs apache bloatware это apache. Хотя разумеется фанатизм и привычки неискоренимы, заставлять кого-либо что-либо (не) использовать не в моих силах, для массовых хостингов nginx без апача пока не очень годится, надо чтобы панельки хорошо поддерживали его настройки для типичных задач, но наверное это дело времени, как реверс прокси вроде как поддерживают, я то привыкла все через ssh делать и за лицензию на панельку платить не хочу.
На шаред-хостингах основная киллер-фича apache - это .htaccess. Nginx'овые инклюды его заменить не могут, т. к. при наличии ошибки в .htaccess ломается только location, в котором оный находится, а при наличии ошибки в заинклюженном подконфиге nginx'на нельзя ни перезапустить, ни порелоадить сервер. Дополнительную сложность создает то, что .htaccess намертво укоренился в шайтан-туториалах и головах типа-веб-мастеров, так что отказ от его поддержки для шареда будет подобен смерти.
увы да, поэтому и максимум для хостингов это nginx как реверс прокси
>при наличии ошибки в заинклюженном подконфиге nginx'на нельзя ни перезапустить, ни порелоадить сервер"не умею" != "нельзя", %аноним%
>> На шаред-хостингах основная киллер-фича apache - это .htaccess.http://www.anilcetin.com/convert-apache-htaccess-to-nginx/
http://winginx.ru/htaccess
это все хорошо если есть доступ к nginx.conf
а представьте клиента shared-хостинга, это он саппорт должен уломать внести изменения в конфиг? А если учесть что саппорт большинства пупкин-хостингов это малограмотные "белки" у которых и техническая возможность что-либо подкорректировать может отсутствовать?Пока это не появится в Cpanel/Plesk/итд/итп никуда индеец с хостингов не уйдет
> http://www.anilcetin.com/convert-apache-htaccess-to-nginx/
> http://winginx.ru/htaccessВы недооцениваете разработчиков. Тривиальные случаи и конвертировать не надо, но разработчики славятся нетривиальными. Да разбросанными по всему участку, везде разные. Да какими-нибудь затеинками, что конвертор подавится.
Тогда вам нужен cherokee
там в вебморде ваши .htaccess
> В случае nginx vs apache bloatware это apache.Разработчики openbsd, склонные к чистоте рядов и духа, так не считают. И то и другое входит в базовую систему. С припиской, что когда-нибудь, может быть...
Кстати, не думаю, что apache ест много ресурсов. А вот что он ест некие части тела разработчиков и пользователей, приучая их к апачизмам и php-змам - вот это очень плохо. Вместо удобнейшего интерфейса типа wsgi, который можно нанизывать в любом порядке хоть на сервер, хоть друг на друга - какие-то условности 17 века, что вот это - файл, который можно исполнять (а потом где-нибудь, через 5 лет, появляется сторонний ftp, на который можно залить php файл и тот будет исполнен, хотя для этого не был предназначен. если у cgi в perl-ах и sh-еллах хотя бы нужно было права execute установить, то php исполнится даже если имеет права только на чтение).
Замена apache на nginx + (по расширению запроса) даст только замену апачизмов на nginx-измы и прибавку к производительности. Прибавки к ответственности он не даст... поэтому без разницы, на чём такую парадигму исповедовать, хоть тушкой, хоть фронтендом. Особенно, если пиковые нагрузки несравнимы с facebook.
>> В случае nginx vs apache bloatware это apache.
> Разработчики openbsd, склонные к чистоте рядов и духа, так не считают. И
> то и другое входит в базовую систему. С припиской, что когда-нибудь,
> может быть...openbsd последние пару лет плавно мигрирует с апача на nginx, так что apache там долго не задержится, он deprecated, всем рекомендовано с него слезать.
на OpenVZ Апач теперь кушает так же мало памяти, как и на Xen на ядрах RHEL6-based.
> для любыхОга. Как только научится нормально Transfer-encoding: Chunked и другие элементарнийшие вещи при использование в качестве reverse-proxy.
умеет уже давно
>> для любых
> Ога. Как только научится нормально Transfer-encoding: Chunked и другие элементарнийшие
> вещи при использование в качестве reverse-proxy.Проснитесь из анабиоза, давно умеет.
> только имеет смысл для высоконагруженных проектовПроще сразу с ним иметь дело чем с тормозным утюгом апаче. А то однажды вы просыпаетесь, а в мыло уже пользователи нагадили - "сайт лежит!".
>> только имеет смысл для высоконагруженных проектов
> Проще сразу с ним иметь дело чем с тормозным утюгом апаче. А
> то однажды вы просыпаетесь, а в мыло уже пользователи нагадили -
> "сайт лежит!".Если часто случается - смотрите железо (особенно память).
> А то однажды вы просыпаетесьА ты не спи.
Мы тут проект сделали http://repobuild.com/ для самостоятельной сборки RPM пакетов с любыми выбранными параметрами.В данный момент возможно собрать rpm пакеты под CentOS/RHEL 5.x/6x Nginx (1.4.x) Nginx_stable (1.2.x) Tengine (1.4.x) ngx_openresty (1.2.7.x) с любыми параметрами и многими сторонними модулями.
Регистрируемся, выбираем ОС, архитектуру, добавляем пакеты и выбираем опции сборки - на выходе получаем ссылку на репозиторий в котором лежат rpm пакеты собранные с нужними вам параметрами и модулями.
Принципально новый проект.
прошу добавить TokuDB, это форк mariadb с плюшкамиисходники: https://github.com/Tokutek/mariadb
Постараюсь в ближайшее время протестировать и добавить в проект
TokuDB - это не форк MariaDB, а Storage Engine для MySQL/MariaDB + несколько патчей.
Отличная вещь, когда надо ворочать сотни гигасов данных.
А теперь еще и банано^W под GPLv2.
> Мы тут проект сделалиНу молодцы.
> Регистрируемся
Понятно - анонимам путь заказан. С персональными данными как у вас? Сами-то в Роскомнадзоре зарегистрировались?
Любому здравомыслящему человеку, который прочитал описание проекта, должно быть очевидно по каким причинам сделана регистрация:1. Вы можете создать приватный репозиторий в который имеете доступ только Вы.
2. При очередном обновлении пакеты автоматически пересобирутся с Вашими параметрами, а не с теми которыей натыкал случайный посетитель.
P.S. Про персональные данные слишком толсто.
Молодцы, но нет - спасибо. Свои проекты буду собирать, как и всегда, по старинке - на локальном компьютере.
Эх, ну не судьба.
Будем совершенствовать свои навыки сетевого маркетинга :) и в следующий то раз Вы точно попадете в наши сети.
> Будем совершенствовать свои навыки сетевого маркетинга :) и в следующий то раз Вы точно попадете в наши сети.А можно узнать, в чём прибыль?
ps. Я милого представителя сетевого маркетинга ВСЕГДА узнаю по написанию Вы с большой буквы. Такое ощущение, что их там на каких-то спецкурсах сознательно этому учат.
Нет прибыли, just for fun.
Собственно как и в предыдущем проекте которому уже года 3 http://centlos.alt.ru .Увы и ах, обращению на Вы при общении с незнакомыми людьми меня научили родители.
> Увы и ах, обращению на Вы при общении с незнакомыми людьми меня научили родители.А русский язык регламентирует, когда пишут "вы", а когда "Вы". И есть такой интересный парадокс, чисто психологического свойства, с русским языком мало связанный - спамеры и подобные им люди, обманщики и механизмы обязательно пишут "Вы".
Простите за праздный интерес, к какой из перечисленных групп Вы отнесли меня ? :)
Да будет известно из школьного курса русского языка: "Вы" - обращение к одному лицу. "вы" - к многим. Поэтому спамеры, как ни странно, в данном вопросе куда более верны, нежели ваши предпочтения.
> Да будет известно из школьного курса русского языка: "Вы" - обращение к одному лицу. "вы" - к многим.Гхм... кх... кх... пишите лучше про php, за php хоть не стыдно, в отличие от русского языка.
А кто вам тогда сертифицированных бакдоров насует? Не православненько как-то
Для тестов создал пользователя user пасс user
> С персональными данными как у вас?Всё, что вы навбиваете в регистрационной форме -- это НЕ персональные данные, даже если там просят вводить домашний адрес и номер телефона.
Персональными данными будет считаться лист с вашим адресом-телефоном-чем-то-там ещё, подписанный вами, к которому пришпилена ксерокопия вашего паспорта (заметим -- российского, так как по законодательству "по умолчанию" документом, удостоверяющим личность, является _только_ паспорт гражданина РФ либо документ, его заменяющий -- для того, чтобы банки стали принимать водительское удостоверение и заграничные паспорта, Центробанк выпустил специальную инструкцию, номер которой легко ищется Яндексом).
А также копия этих данных, введённая в систему машинной обработки информации, если в случае возникновения "разборок" вы внятно сможете доказать в суде, что эти данные попали таки именно с вашего паспорта (предъявите, например, второй экземпляр договора на предоставление услуг подвижной радиотелефонной связи -- или вы его уже выкинули?-)
Всё остальное -- это чушь и ересь, так как при "регистрации на сайте" я легко могу ввести свои имя и фамилию и домашний адрес моей секретарши -- эта совокупность информации будет являться _чьими_ персональными данными?
+100 в карму. Надо приучать к правильному деплою софта пакетами из репозиториев, а не руками из тарболлов, даже тех, кто не осилил rpmbuild.P.S. А почему src.rpm'ки не даете?
P.P.S. В состав многих пакетов входят базовые конфиги приложений (например, nginx.conf в составе пакета nginx). Было бы мегакруто, если бы вы предоставили возможность редактировать их перед сборкой.
P.P.P.S. Где кнопка donate? Пользоваться сервисом не буду, т. к. осилил самостоятельную сборку пакетов, но поддержать начинание хочу.
Спасибо за карму, весь вечер икаю :)SRPMS проекто зависимые, собрать из нее с помошью rpmbuild будет проблематично, т к в spec передаются опции каждой сборки.
Над возможностью самостоятельно запиливать свой conf в пакет мы думали, пока в далеких планах в связи с тяжелой реализуемостью.
Donate пока нет, проект только только родился и баги правятся на лету :)
Спасибо за интерес к проекту.
Да, кстати, сорцы на каком-нибудь гитхабе есть? Я бы, может быть, попробовал сам что-нибудь допилить и прислать пулл-реквест.
> Да, кстати, сорцы на каком-нибудь гитхабе есть? Я бы, может быть, попробовал
> сам что-нибудь допилить и прислать пулл-реквест.Пока связь по проекту через кнопку "FeedBack" на repobuild.com или в комментах на CentALT http://centos.alt.ru/?p=803
Если есть реальные пожелания по развитию проекта велком :)
> +100 в карму. Надо приучать к правильному деплою софта пакетами из репозиториев,
> а не руками из тарболлов, даже тех, кто не осилил rpmbuild.Нет, нельзя приучать к подобным проектам. Денис действует из лучших побуждений, а вот его "коллега", представивший публичный билдер, насует троянов в собранные пакеты...
Лучше некий сервис, который хранит спеки (имхо)
> Лучше некий сервис, который хранит спекиОн уже есть. Называется github.
>> Лучше некий сервис, который хранит спеки
> Он уже есть. Называется github.anoncvs
учитесь mozilla и chrome, как версии нумеровать.
Проект хороший. Нужно только улучшить диагностику (в том числе информативность сообщений об ошибках в логах).
> Проект хороший. Нужно только улучшить диагностику (в том числе информативность сообщений
> об ошибках в логах).Если сразу заработает - нормально, везуха. А так в логи всякую шнягу пишет - хрен разберешься в истинной причине.
регулярно есть коммиты, улучшающие тексты сообщений об ошибкахпиши в http://trac.nginx.org/ или в рассылку, такое (если обоснованно) охотно правят
Засунули бы nginx в базовые репки CentOS/RHEL и сразу бы апачик стал -25%, а nginx +25%. :(
Вероятность того что на сервере подключены только базовае репы стремится к нулю.Nginx есть в Epel, Atomic, PUIAS Unsupported, Webtatic, CentALT.
Смехотворно. Ещё с rpmfind предложите nginx поставить :)))
Что именно смехотворно ?
> Что именно смехотворно ?Политика компании может запрещать подключение сторонних репозиториев. Или политика техподдержки red hat, к примеру (тут уже не уверен, но всяко бывает).
Внутрекорпоративные репозитории тоже политика компании использовать мешает?Религия запрещает собрать rpm-ку (или взять готовую с nginx.org) и положить у себя?
Что же касается техподдержки Redhat, то это только доказывает ее бесполезность и необходимость обратить внимания на аналогичные предложения Canonical и IBM.
>> Что именно смехотворно ?
> Политика компании может запрещать подключение стороннихНу-дк, и смейтесь над своей "политикой" -- она запрещает использование nginx.
херня, один раз поставил, он мне старую информацию с динамического сайта выдавал, кеш не правильно что ли работает. Pagespeed для апача использовать мне кажется больше толку будет.
> херня, один раз поставил, он мне старую информацию с динамического сайта выдавал,
> кеш не правильно что ли работает. Pagespeed для апача использовать мне
> кажется больше толку будет.а разбираться конечно же было лениво? проще взять и скопировать было чей-то там конфиг с кешированием и неглядя и не разбираясь его использовать, а потом сказать "ну и гадость эта ваша заливная рыба!"
Кеширование данных отдаваемых бэкэндом вообще штука достаточно специфичная в настройке, скорость конечно влет, но для начала от этого лучше отказаться и переходить к nginx постепенно.1 этап, для самых осторожных
nginx фронтэндом, в бэкэнде apache, требуется включить mod_rpaf для корректности IP адресов используемых апачем и mod_php (или другим модулем)2 этап, включите отдачу статики nginx'ом
большая часть запросов уйдет от apache с его форками к nginx-у, динамика и неизвестные типы файлов будут по прежнему обрабатываться apache3 этап, отказаться от apache :)
самые большие проблемы которые тут ждут - корректно транслировать правила .htaccess
как url rewrite так и права на папки, которые в веб светить не нужно.а далее уже берете и настраиваете фичи под ваше веб приложение, включая возможно и кеширование ответов бэкэнда (apache или php-fpm например)
1 этап: Event MPM на фронт
2 этап: нет
> 1 этап, для самых осторожных
> 2 этап, включите отдачу статики nginx'ом
> 3 этап, отказаться от apache :)4 этап - иногда оказывается, что если вместо первого этапа занялись бы переписыванием решения на нормальной среде, суммарного времени затребовалось бы меньше, поддержка была бы проще, и любви к php в этом мире было бы меньше. На этом этапе кто-то идёт пить водку, кто-то - в слёзы, кто-то моментально выгоняет эту мысль из головы и занимается самоуспокоением "зато нас банда", а кто-то - начинает на opennet устраивать пропаганду php.
"Свифт нанял актёров, чтобы те несли людям его мысли. Но наш губернатор оказался хитрее — он нанял зрителей." // х/ф "Дом, который построил Свифт"
Понимаешь ли, в чём фишка. Среда разработки в рыночно-коммерческой среде выбирается далеко не просто так, и вовсе не за красивые глазки ("патамушта наманая я так щетаю") :) Критерий пригодности определяется строго коммерческим интересом, интерсекцией потребностей и возможностей, и наличием мощностей для реализации.
> Понимаешь ли, в чём фишка. Среда разработки в рыночно-коммерческой среде выбирается далеко
> не просто так, и вовсе не за красивые глазки ("патамушта наманая
> я так щетаю") :) Критерий пригодности определяется строго коммерческим интересом, интерсекцией
> потребностей и возможностей, и наличием мощностей для реализации.Короче говоря, желанием левой пятки "потому что так вышло". А потом привязыванием костылей. Пока мои наблюдения вывели только такие критерии, ни одной компании, где было бы иначе, я не знаю.
И прежде чем подчиняться "правила диктует рынок", нужно вообще-то знать, что такое правила, и что такое рынок. И я хорошо, поимённо, знаю на opennet тех, кто этого не знает.
Впрочем, речь была совсем не об этом. А о ВЫБОРЕ, а не "выборе между php с apache и php без apache". Причина этого чаще всего одна (потому что я знаю только два слова - php(.exe) и apache(.exe), и буду долго гнать велосипед"), никаким анализом, никаким выбором, никаким банальным планированием "чё мы ваще хотим получить" никто не озабочивается, предпочитают шить штаны бесконечным латанием юбки.
Не будем говорить про "дорого и дыряво", но даже поверхностный анализ показывает, что куча мелких и средних проектов на php от перехода на более подходящие средства только бы выиграли - и рублями, и поддержкой, и деплоем, и повышением репутации (знающие люди смеяться перестанут).
> Не будем говорить про "дорого и дыряво", но даже поверхностный анализ показывает,
> что куча мелких и средних проектов на php от перехода наЧей анализ? Если бы "показывал" - уже перешли бы. Или вы считаете, что в разномастных компаниях сидит 99.99% идиотов? А вы один такой, на белом коне...
>> Не будем говорить про "дорого и дыряво", но даже поверхностный анализ показывает,
>> что куча мелких и средних проектов на php от перехода на
> Чей анализ?С точки зрения банальной эрудиции не каждый индивидуум...
> Если бы "показывал" - уже перешли бы.Это видно снаружи, но не видно изнутри. Проще говоря, ОТКУДА ОНИ ЗНАЮТ?
> Или вы считаете, что в разномастных компаниях сидит 99.99% идиотов? А вы один такой, на белом коне...В современном веб-шуме просто нельзя знать всё. И проверять всё тоже нельзя, потому что жизни не хватит. И идёт обратный процесс, отторжения всего нового, чтобы не связываться и не засорять эфир. Я уже не раз объяснял php-шникам, чем некоторые вещи на python, ruby и node (в зависимости от их ситуации) - лучше. Но противодействие php-шников, которые учиться не хотят и не умеют, php-шное лобби, до сих пор сильно. У этих людей цели прямо противоположны достижению результата - они не хотят напрягаться, чтобы сделать лучше, они хотят мямлить и месить код по привычке. И именно они придумывают все страшилки и немыслимые достоинства php. Но это, увы, пшик. :)
Почти каждый, кто изучил современные средства, к php не возвращается - это медицинский факт. И почти каждый php-шник не знает python на таком уровне, чтобы хотя бы сравнивать эти языки - это тоже медицинский факт. Вот и всё.
Похоже, так и будете воевать с ветряными мельницами, пока не повзрослеете.
> Похоже, так и будете воевать с ветряными мельницами, пока не повзрослеете.Похоже, так и будете отрицать очевидные факты и прятаться за "миллионы мух".
Мне с вами воевать не надо, потому что у меня есть всё то, что есть у лучших. Это у вас проблемы, очевидные. И затыкаемые единственным известным способом.
> Короче говоря, желанием левой пятки "потому что так вышло". А потом привязыванием
> костылей. Пока мои наблюдения вывели только такие критерии, ни одной компании,
> где было бы иначе, я не знаю.Это уже твои личные половые фантазии. Реально выбор всегда вполне себе аргументирован.
И очень часто он аргументирован тезисом "это работает". Вот просто работает, и всё. Просто, быстро и удобно. И каши не просит, как ни странно. При наличии толковых рук.
Вообще спор о PHP/... сродни спорам о Linux/BSD, MySQL/PGSQL, Apache/nginx. В реальной жизни побеждает не правильность и академичность, а простота, удобство, скорость и надежность. Можно их собрать под одним словом - "окупаемость". Именно эти критерии обычно становятся во главе угла при выборе сред. Да и вообще.
Есть на самом деле задачи, для которых подобные решения неприменимы. Но их не так уж и много, в % соотношении. Поэтому в основной массе вы встретите именно _удобные_ и _окупаемые_ среды. Эти среды не годятся для нетиповых задач, но для основной массы типовых лучше их на данный момент, подчеркну - на данный момент - нет. Поэтому и выбирают. Появится что-то лучше - все будут выбирать иное.
Каким боком это в топик? Можно, конечно, сидеть и человекомесяцами пилить nginx, чтобы он не падал, чтобы вязался с инфраструктурой, etc. Для _разовых_ применений, где массовый вариант не катит - хайлоадов и подобного - это оправдано, и окупаемо. Но там, где прекрасно работает массовый проект - смысла пилить специфику просто нет.
Ну да что мне вас учить. Подрастете - сами осознаете.
Всё очень круто, разработчики молодцы! Вот только не совсем понятно, почему реализована 2-я версия протокола SPDY, а не 3-я? Может уже было обсуждение, ткните носом.
> Всё очень круто, разработчики молодцы! Вот только не совсем понятно, почему реализована
> 2-я версия протокола SPDY, а не 3-я? Может уже было обсуждение,
> ткните носом.Ачо, тебе принципиально? У тебя 15 млн клиентов его жаждут? :D
3 миллиарда только выручка
Подскажите, а не появилась ли в nginx поддержка аутентификации через LDAP? Помнится приходилось держать собственную сборку с сторонним модулем.
Нативно не появилось, есть https://github.com/r10r/ngx_http_auth_pam_module/blob/master...
А еще есть прямой модуль без pam - https://github.com/kvspb/nginx-auth-ldap
да ладно, я же пошутил, думал мне расскажут как настраивать и как его с php подружить без апача, если такое возможно, короче я его не использую.)))
Как fcgi легко.
location ~ \.php$ {
fastcgi_pass unix:/var/php/php-fpm.sock;
к слову забавно смотреть как апач сейчас пытается догнать то, что достигнуто в nginx и lighttpd, и event mpm сделали и поддержку mod_proxy_fcgi для php-fpm в версии 2.4
> location ~ \.php$ {
>
>
> fastcgi_pass unix:/var/php/php-fpm.sock;1. нет поддержки apache mod_access
2. нет поддержки /index.php/tra/la/laа большинство проектов предлагают или безальтернативный 1, или выбор между 1 и 2
это не поддержка php. это поддержка "идеального" php, на котором никто не пишет.
> нет поддержки apache mod_accessСм. ngx_http_access_module
> нет поддержки /index.php/tra/la/la
rewrite (/index.php)(.*) $1?q=$2;
В общем, читаем документацию.
>> нет поддержки apache mod_access
> См. ngx_http_access_module
>> нет поддержки /index.php/tra/la/la
> rewrite (/index.php)(.*) $1?q=$2;
> В общем, читаем документацию.Между "аналогом" и "костылём" разница в неудачный год может достигать полкилометра.
не костыльный штатный способ - fastcgi_split_path_info
> не костыльный штатный способ - fastcgi_split_path_infoНи один способ, который рекомендуется тем же owncloud, включая этот, не заработал. owncloud не мог понять, что ему суют. То же у apache с cgi, он единственный понимает форму /cgi-bin/file.cgi/hello/mat/vashu. И ни один сервер, кроме apache, так не умеет, попробовав 20 серверов разного уровня cgi-шности, просто заставить работать фоссиловский асинхронный веб-интерфейс не удалось. :( Я уже тысячу раз писал, почему люди вынуждены так писать, и тысячу раз писал, почему это криво и неудобно.
Вообще, это нелепо - у php нет единого способа, который работает на том же внутреннем сервере. У меня тогда вообще вопрос, зачем нужен внутренний сервер?
Увы, в php с его манерой исполнения, все способы представить, будто у него есть роуты, будут всегда костыльными. По сравнению с wsgi это каменный век. Кстати, по этой же причине php-фреймворки имеют довольно мало смысла (кроме причины "зато мы пишем на php" нет никакого прока использовать иллюзии, что это не php, на php), уж лучше ЛЯПИТЬ по старинке, или использовать подобные фреймворки там, где раскрывается их потенциал.
потому что надо не просто лепить копипасту, а разобраться, какие переменные среды ожидает видеть приложение (да, приложения написаны зачастую через жопу).в nginx, в отличие от всяких лайти, не захардкоженные пресеты (и флаги типа "compat_with_broken_shit"), а четко расписывается каждая fcgi-переменная.
дефолтный fastcgi_params не всегда подходит, для всякого несоответствующего cgi стандартам дерьма надо сесть и написать свой.
> к слову забавно смотреть как апач сейчас пытается догнать то, что достигнуто в nginx и lighttpdЛучше бы nginx достиг такой фичи lighttpd, как simple vhost. У меня с помощью циркуля и линейки накостылился вот такой вот вариант (даже не знаю, правильный ли, и насколько безопасный)
server { забайкалье default }
server { ... }
server { ... }server {
server_name ~^(www\.)?(.+)$;
if (!-d /гдето/лето/$2) {
rewrite ^/(.*) http://забайкалье.далеко permanent;
break;
}
root /гдето/лето/$2;
}но оно работает не так, как хотелось бы - и ненужный редирект, и вообще страшно.
map $host $vhroot {
hostnames;
.....
}
server {
root $vhroot;
}
Игорь тоже рекомендует map он хорошо хешируеться
> Игорь тоже рекомендует map он хорошо хешируетьсяТолько это не аналог simple vhost. simple vhost - это просто создал каталог, и сервер его подхватил.
Новый апачкопец стал ещё лучше! ^^
http://www.securityfocus.com/archive/1/526439/30/0/threadedвот есть же "интересные" люди, наверняка специально ждали релиза чтобы "попиариться" на найденной возможной дырке.
Не критично если стоит grsecurity
http://forum.nginx.org/read.php?2,238713официальный ответ Дунина, все-таки китаец просто пиарился на пустом месте