Nginx занял 51% вебсерверов в рунете

[@kuzvac]

А где картинки:)

[@opium]

Сейчас починю.

[@bondbig]

Лучше снять скриншоты и выложить на habrastorage.org. У меня порезало фильтрами, например, пришлось добавлять исключение. Оно на habrastorage и поспокойнее будет, пролежит долго и не сменит url.

[@VolCh]

Когда же?

[@opium]

Вроде у всех показываются.

[@VolCh]

Судя по минусу не только у меня не показывается.

[@mark_ablov]

у меня — нет.

[@opium]

А сейчас? Слил на хабрасторадж.

[@mark_ablov]

всё ок.

[@VolCh]

теперь ок

[@mrded]

[@kuzvac]

Замечательная картинка.

[@opium]

Поясните пожалуйста картинку. Сходу не вкурил.

[@opium]

Вкурил

[@mrded]

Эта картинка объясняет, почему 51% занял Nginx а не Apache :)

[@bondbig]

Эта картинка — трололо. Nginx никак не поможет в данной ситуации. Они с апачем и не конкуренты воообще, если на то пошло, разные ниши, разные задачи.
Вот ведь я раскапитанился…

[@reiser]

Ну почему же не конкуренты?
Конечно есть области, где apache ещё нужен, но nginx покрыл основную часть его задач.

[@bondbig]

nginx не выполняет динамический код. Он лишь проксирует. А к апачу ли, к вебсфере или ко всяким fastcgi — это уже вопрос отдельный.

[@bondbig]

Апач как раз выполняет, посредством модулей.

[@mrded]

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

[@fakedream]

а что на картинке — 20-30 мегов большинство инстансов. Ну и что? Это ерунда. К тому же используется mpm prefork :) — mod_php наверное? для него? :)

[@bondbig]

VIRT

[@ColorPrint]

Ну так тут апач префорком запущен, а можно с MPM-worker тем же )
А так да, nginx рулит )
У нас на серверах уже несколько лет процентов 80 — nginx.

[@alekciy]

Можно. Только зачем, если менее стабильно? Года этак полтора назад запускали MPM-worker на нашед хостинге под CentOS именно в контексте меньшего потребления ресурсов (nginx+php-fpm тут из-за отсутсвия htaccess конечно же не подходит). По сравнению с prefork слишком нестабилен, клиенты недовольны, пришлось быстро возвращаться на prefork.

Может конечно дело в CentOS, уж слишком по мне ретроградская ОСь, но подобные результаты ранее получались и на FreeBSD. Впрочем вполне закономерно, упавший форк в prefork-е тянет за собой максимум один упавший коннект, в worker-e — ThreadsPerChild коннектов.

[@fakedream]

а php как был заведен?

[@alekciy]

Сейчас могу уже попутать, но мой склероз говорит, что через fastcgi.

[@fakedream]

тогда странно. то поведение, что Вы описали очень похоже не mod_php + mpm_worker.
к тому же есть еще mpm_event :) это типа продолжение mpm_worker.
вообще я все это говорю не к тому, что nginx не нужен, а то, не одним нджинксом, как говорится… :)

[@alekciy]

Нет, точно не event. Я сейчас уже точно не помню, в mod_php оно работало или через врапер в fastcgi, но точно именно worker, не event.

[@fakedream]

нене. я там пару букв неправильно написал :) про ивент я вспомнил, потому что кроме worker есть еще мультитредный мпм.
а говорил я то, что скорее всего был все-таки mod_php — поэтому и падало.

[@impass]

nginx+php-fpm тут из-за отсутсвия htaccess конечно же не подходит

Разве так сложно необходимые правила переделать? :)
Да и в приложениях, которые сами пишете, ведь давно пора уже разбор URL'ов перенести в приложение с плеч mod_rewrite.

[@Plohich]

расскажите это двум-трем сотням клиентов на виртуальном хостинге, которые на этом сервере сидят. Прям таки все и переписали скрипты.

[@impass]

таким, полагаю, и наличие nginx то ни к чему :)

[@alekciy]

Ну отчего же, статику в таких условиях nginx прекрасно на себе берет разгружая бекэнд для скриптов.

[@Xarakternik]

Утилита htop, а вот назвать машину idiot — это смело. )

[@Mystex]

Чтобы никто не догадался!

[@ajaxtelamonid]

Своп на 100% используется, поэтому и D.

[@seriyPS]

la 191.38 176.57 108.17 O_o

[@willwin]

а шо это за top такой симпатичный?

[@trevel]

htop

[@phasma]

httpd.apache.org/docs/2.2/mod/prefork.html

У вас просто неправильно настроен apache. la 191 показывает, что nginx вам тоже не сильно поможет, т.к. нет понятия в чем архитектурное отличие apache от nginx.

[@fakedream]

ну в некотором случае все-таки поможет, так как возьмет на себя отдачу данных «медленным» клиентам, тем самым освободив некоторое количество чайлдов апача.

[@phasma]

Я так понимаю, что автор сего опуса хвастается тем, что он заменил не настроенный апач на nginx и это дало 100500% прироста производительности. Я не знаю как ведет себя php-fpm, может это и быстрее. Мы обычно используем свой вебсервер для фронт-энда, который не умеет ничего кроме статики(ну практически) и апач за ним. Получается весьма не плохо.

[@Luge]

Ха, не я один так комп обозвал, оказывается. :)

[@mark_ablov]

виват :)

[@kitaisc]

Меня радует его простота, гибкость и экономия вечно не хватающих ресурсов.

[@bondbig]

Отличный продукт, отличная документация, ожидаемый успех. Игорь и Михаил молодцы.

[@akzhan]

Документация скорее аскетичная. Иногда англоязычные товарищи пишут объемнее.

Например, о X-Accel-* я информацию находил не в документации, а в рассылке и в вики wiki.nginx.org/XSendfile

[@romka777]

вспоминается будущее?

[@ergil]

Игорю прежде всего ВИВАТ за то, что если есть проблема то он отвечает лично и быстро(мне подкидывал как обойти проблему OpenSSL решение(отзыв сертификата))

[@korum]

Браво! В очередной раз убедился что наши разработчики — лучшие

[@kolpeex]

Да вообще все хороши.

[@korum]

Несомненно, но очень приятно от того что наши разработки таки весьма качественные, и что продукт Сысоева занял 51% от общего количества серверов.

[@eloki]

контрольный пакет

[@bondbig]

[bore]Контрольный пакет это 50%+1 акция. Допустим если Всего 60000 вебсерверов, то «контрольный пакет» это 30001 сервер, до 51% далеко при этом ;)[\bore]

[@mark_ablov]

а у вас слэш не в ту сторону повернут.

[@homm]

Т.е. 51% — это уже не контрольный пакет?

[@Roler]

Ну, если строго — то это вы блокирующий пакет определил)
Контрольными могут быть и 5% акций, если больше ни у кого нет. Так Баллмер и Гейтс могут рулить Microsoft — больше чем у них просто ни у кого нет. А у них в сумме меньше 20%.

[@bazzilic]

Блокирующий пакет — это 25%. Обладатель блокирующего пакета обладает правом вето на любое решение. Отсюда и название.

Контрольный пакет — пакет размером строго больше 50%, как правило, под контрольным пакетом подразумевается 50%+1 акция, т.е. минимальный контрольный пакет.

Капитан Финансист

[@smartov]

КОНТРОЛЬНЫЙ ПАКЕТ АКЦИЙ — минимальная доля акций, дающая возможностьих владельцам осуществлять фактический контроль за деятельностью акционерного общества.

Теоретически контрольный пакет акций составляет не менее половины всех голосующих акций. Практически (при широком распространении акций) контрольный пакет составляют 20% акций.

Капитанское удостоверение сдайте в канцелярию Наденьке.

[@bazzilic]

Хорошее умение копипастить, поздравляю! Осталось только матчасть подучить. Могу посоветовать Т. А. Батяева, И. И. Столяров «Рынок ценных бумаг. Учебное пособие».

[@Chamie]

Почему же? Если владельцы меньших пакетов, в сумме превосходящих этот, проголосуют единогласно, то их голоса будут решающими.

[@lehha]

Это статистика не webnames, а 1stat.

[@deniamnet]

Спасибо Сысоеву!

[@gigimon]

Всеравно из этих 51% думаю даже 10% нету, где чистый nginx, без апач сзади

[@ColorPrint]

Для большинства задач апач сзади на самом деле не нужен… php и cgi скрипты уже давно можно без апача с nginx запускать… Главное неудобство — реврайты из .htaccess переписывать в конфиг nginx.

[@Fr0stb1te]

Вот да, специально зашел напомнить, что очень много где nginx используется как прокси для апача и/или чего-то еще.

[@ArjLover]

Забавно что треть любителей не поленились выпилить номер версии…

[@ibnteo]

Видимо не учтены многие backend, Apache небось больше половины будет, но зачастую он используется вместе с frontend Nginx.

[@ibnteo]

Ну вот, читать надо внимательнее, в статье об этом говорится, посыпаю себе голову пеплом.

[@bazzilic]

А в комментариях вы не вошли даже в первую сотню упомянувших об этом! )

[@EMPIRE]

Друзья, у меня в настоящий момент под проект трекера установлен nginx 0.8.36, стоит ли обновить до 1.0.4?
Прошу понять правильно. В настоящий момент никаких проблем с версией 0.8.36 не наблюдаю, тьфу-тьфу-тьфу, но тем менее хотелось бы получить ответ от вас дорогие хабра юзеры.

[@hf35]

Статистика использования версий более чем красноречива — “не сломано, не чини”

[@ajaxtelamonid]

Не трогайте. У многих вот 0.6 еще стоит, работает.

[@impass]

там нет даже try_files :-P

[@crea7or]

У меня неделю назад ещё 0.3.4 стоял.

[@TheShock]

у Sony, например.

[@opium]

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

[@alexxxst]

Я сижу с 0.1, если бы не nginx в свое время, многие мои проекты так и не были бы реализованы или загнулись бы быстро…

[@Andrey_Zentavr]

Золотое правило админа:
Работает? не лезь! :)

[@Magiq]

глобальное правило админа — если что то делаешь не забудь сделать бэкап.

[@Andrey_Zentavr]

Ну это как бы по-дефолту :)))

[@impass]

Золотое правило админа:
Работает? не лезь! :)

Недавние жертвы хакеров из LulzSec — Sony и PBS — видимо особенно тщательно этим руководствовались при построении своих систем…

[@ranzhe]

Есть разница между обновлением ради обновления и обновлением в целях повышения безопасности.

[@impass]

Объективную разницу можно понять только если регулярно читать рассылки типа bugtraq, чем, думаю, среди аудитории Хабра крайне мало кто занимается. Да и в нынешних реалиях почти каждая новая версия какого-то популярного ПО содержит исправления тех или иных уязвимостей, от малосущественных до критических. Особенно это важно в случаях, когда доступ к вашим системам теоретически может получить любой.
В случае со свободным ПО это ещё и непрекращающееся совершенствование функционала.

[@azxc]

Правило, конечно, хорошее. Но в целом есть риск, что некий продукт может иметь некоторые дыры в плане безопасности, которые могут огласить публично. Тогда всякие script-kiddies могут полезть и поломать то, что уже долго работало.

[@EMPIRE]

Спасибо большое за ответы.

[@andrew_tch]

Боже, куда рунет катится.

[@AgaFonOff]

Программисты, соберитесь уже и напишите htaccess модуль для nginx!
И остальные 49% падут на колени пред вами :)

[@kirilloid]

ИМО нужен скрипт переноса .htaccess в конфиг nginx-а. Не всё можно, но хотя бы простые правила. Идея апача, где в каждой директории лежат свои настройки мне не нравится. Не нравится именно то, что это в разных файлах, а не чрезмерная гибкость.

[@AgaFonOff]

На самом деле я полностью согласен — так правильнее. Просто уже надо что-то с этим делать, а не голову ломать и вспоминать как там переписать это всё в когфиг.

[@cadmi]

ИМО, не нужен.
Просто потому, что [практически] любой автоматический перевод сделает из одного гамна другое гамно. Ну разве что новое гамно будет со вкусом ванили.

В конфигах nginx зачастую нужна просто другая парадигма. Регулярно в рассылке появляется очередной кекс с вопросом типа «посоны, я тут переписываю htaccess, вроде перевел, но вот остался еще маленький вопросик. взгляните на конфиг». После чего Игорь, в очередной раз терпеливо вздохнув, объясняет ему, что не стоит всегда решать задачу прямо в лоб. И превращает два экрана уродливого конфига с табуном rewrite (с регэкспами) в три-четыре элегантных location.

[@impass]

htaccess не нужен
научитесь парсить входные параметры в самом приложении без каких-либо рерайтов

[@AgaFonOff]

Учите создателей стороннего софта, я уже давно всё это делаю сам. Но иногда приходится ставить написанное другими, и с примерно 100% вероятностью там есть эти весёлые файлики по всем каталогам.

[@cadmi]

Зачем? Чтобы превратить nginx в apache?

[@fenrirgray]

Все равно в большинстве случаев за этими серверами с nginx бэкендом апач стоит.

[@roman_tik]

А процент пользователей IE6 в интернете вас не удивляет? Вот тут примерно то же самое, только на серверной стороне…

[@build_your_web]

Ничего общего.
IE6 — браузер для пользователей с начальными навыками работы с компьютером. Используют, потому что им так когда-то поставили и так оно до сих пор работает.
IIS + .Net — довольно удобная и современная среда, в которой можно разрабатывать хорошие быстрые приложения (stackoverflow.com тому пример). Беда его в том, что работать с фреймворком учат через GUI и обученные таким образом программисты еще долго продолжают пытаться использовать стандартные контролы, подпирая их со всех сторон костылями. С опытом обычно это проходит.

[@jerom]

Просто десяток крупных сквоттеров используют nginx, вот и всё?

Этим вопросом я демонстрирую, что к статистике надо относиться критично, точно понимая, что она показывает.

[@skynoname]

Тем более многие используют связки фронтэнд- нгинкс, бэкэнд — апач и прочие. Интересно было бы посмотреть статистику по таким вот смешанкам на сервере

[@ergil]

фронт-энд nginx, бэкэнд приложения наших разработчиков на Луа

[@lashtal]

Более реальная статистика: топ 1 млн посещаемых сайтов — 6.93%
netcraft.com

Никто же не будет держать тысячи спамо-доменов на iis ;)