Комментарии 97
Что-то мне кажется, что это IISы за Nginx'ы ставят.
в этом действии смысла совсем немного, вряд ли так поступает кто-то.
поступают
Интересно бы посмотреть на этих людей. Что ими движет?
А смысл статику IISом гонять?
nginx не сумеет это сделать лучше. IIS — он не апач. У него есть kernel-режим, в мире линуксов такое умеет лишь забытый всеми веб-сервер tux.
Nginx на относительно слабой машине может ответить 40к раз в секунду «403» без тюнинга. От IISа такого замучаешься добиваться. Не очень-то kernel-режим помогает. А учитывая в каком ядре оно работает…
И да — само собой, убирают не за nginx на той же машине, а за шлюзы с bsd/linux с поднятым nginx.
И не стоит забывать, что многие сейчас бегут с полудохлого lighttpd на nginx.
И да — само собой, убирают не за nginx на той же машине, а за шлюзы с bsd/linux с поднятым nginx.
И не стоит забывать, что многие сейчас бегут с полудохлого lighttpd на nginx.
не, почему бегут с лайти — это понятно. Но городить nginx перед IIS'ом все равно не понимаю зачем. Отвечать быстро он умеет, на треды в памяти не расползается, как апач. Не понимаю.
Да хотя бы, как балансировщик который встречает сеть TCP-стеком из под *nix-овой машины.
а профит где?
В скорости и надежности балансировщика. Надеюсь в контексте было понятно, что фронэнды и бэкенды на разных машинах. И да «миф» о MS-решете таки еще крепко сидит в умах тех, кто видал виды.
так вот про то и разговор, что тот миф так и сидит.
Ну а скорость и ресурсоемкость (производительность )?
Если балансировщик как фронтэнд за которым пачка серверов приложений, неужели есть смысл делать отдельный балансировщик на Windows Server?
Очевидно, что аскетичный linux-дистр с одним лишь nginx-ом явно будет в десятки (а может и сотни) раз больше запросов обрабатывать и раскидывать. И какой смысл кормить на такие задачи прожорливый Виндоуз?
Если балансировщик как фронтэнд за которым пачка серверов приложений, неужели есть смысл делать отдельный балансировщик на Windows Server?
Очевидно, что аскетичный linux-дистр с одним лишь nginx-ом явно будет в десятки (а может и сотни) раз больше запросов обрабатывать и раскидывать. И какой смысл кормить на такие задачи прожорливый Виндоуз?
десятки-сотни, прожорливый, пачка серверов, отдельный балансировщик на windows
Набор ключевых слов, выдающий отсутствие минимальной матчасти по обсуждаемому предмету. Иногда лучше жевать ©
Набор ключевых слов, выдающий отсутствие минимальной матчасти по обсуждаемому предмету. Иногда лучше жевать ©
Да что вы говорите… у меня стоял IIS на внешку, первый и последний раз. Да можно сколько угодно говорить, что «вы просто не умеете его готовить», но после этого я предпочитаю заворачивать это никсы, и не знать кошмаров и ступоров которые выдавал этот сервачокс (еще один термин вам в набор)…
Я вообще с трудом понимаю, зачем использовать IIS, т.е.в принципе, зачем он нужен кому-либо. Но уж если «готовить», то надо доделывать, а не выставлять дефолтный конфиг в инторнэтики.
Ну, с точки зрения здравомыслящего человека, использование IIS абсолютно нерационально.
Но есть такие люди, которых в институтах/университетах/учебных курсах настолько плотно подсадили на иглу, что они ничего кроме дотнетов и MS-платформ знать не желают, и будут даже на балансировщик нагрузки громоздить Microsoft® Windows® Server® 2008 R2 Datacenter Edition.
Но есть такие люди, которых в институтах/университетах/учебных курсах настолько плотно подсадили на иглу, что они ничего кроме дотнетов и MS-платформ знать не желают, и будут даже на балансировщик нагрузки громоздить Microsoft® Windows® Server® 2008 R2 Datacenter Edition.
Давайте вот так, с менее оценочным и более прагматичным подходом:
Карта системных вызовов при одинаковом замере отдачи одной html-странички.
Это Apache под Linux:
www.habrahabr.ru/pictures/00/00/00/09/44/picture_1.jpg
Это IIS под Windows:
www.habrahabr.ru/pictures/00/00/00/09/44/picture_2.jpg
Даже невооруженным глазом понятно, что чисто скалярно более ресурсоемко, и чисто статистически больше потенциальных точек для ошибок.
Оригинал короткой статьи тут:
habrahabr.ru/blogs/web_security/3033/
Если еще прикинуть что NGnix шустрее апача, то и вовсе думать не очем,
или у вас желание потроллить или ваш аватар противоричит вашим тезисам.
Apache быстрее IIS
Карта системных вызовов при одинаковом замере отдачи одной html-странички.
Это Apache под Linux:
www.habrahabr.ru/pictures/00/00/00/09/44/picture_1.jpg
Это IIS под Windows:
www.habrahabr.ru/pictures/00/00/00/09/44/picture_2.jpg
Даже невооруженным глазом понятно, что чисто скалярно более ресурсоемко, и чисто статистически больше потенциальных точек для ошибок.
Оригинал короткой статьи тут:
habrahabr.ru/blogs/web_security/3033/
Если еще прикинуть что NGnix шустрее апача, то и вовсе думать не очем,
или у вас желание потроллить или ваш аватар противоричит вашим тезисам.
Apache быстрее IIS
Это было адресовано bondbig, но у хабра кончились отступы в верстке.
Апач не быстрее IIS, особенно на отдаче статики. Nginx, вероятно, будет быстрее, но не так драматически, как перед апачем. Мой аватар ничему не противоречит и тут вообще не при чем. Я стараюсь ломать стереотипы и мифы, независимо от их принадлежности к тем или иным компаниям, религиям, верованиям и т.п. Просто раздражает, когда кто-то мыслит шаблонами.
На отдаче статики там и так ясно, что кеш это короткий проброс и во этом смысле всякие kernel-моды могут, и видимо даже обгоняют Apache. Но ветка, как помнится пошла зачем ставят Ngnix перед IIS, так же?
И ответ:42 балансировщик перед несколькими серверами приложений позади, ибо будет быстрее таки, ибо windows server тяжелее обезжиренной под эти цели фрюхи или линукса, ибо судя по карте системных вызовов чисто математически надежнее.
Какие вы стереотипы тут ломаете и кому? — Для меня остается загадкой.
И ответ:
Какие вы стереотипы тут ломаете и кому? — Для меня остается загадкой.
Для меня остается загадкойоок ) На такое количество крепко засаженных шаблонов у меня не хватит сил, пожалуй. Сдаюсь, ты выиграл.
Для меня больше становится очевидным другое, что MS что на уровне пользователей — прививало идею о том, что «корень диска — это рабочий стол», то и на уровне админов я вижу, все больше уход в абстракции и клибельное админство. Я как-то еще склонен верить в фон Неймановскую архитектуру PC и понимание того, как это работает.
Это софт написанный на C/C++ под фон Неймановскую архитектуру PC.
И с этой позиции любая втираемая гламурщина, все равно укладывается ровными штабелями в теорию конечного автомата (КА на wiki)
и это позволяет более трезво смотреть на вещи, если знаний для этого хватает.
Это софт написанный на C/C++ под фон Неймановскую архитектуру PC.
И с этой позиции любая втираемая гламурщина, все равно укладывается ровными штабелями в теорию конечного автомата (КА на wiki)
и это позволяет более трезво смотреть на вещи, если знаний для этого хватает.
Быстрее, потому что легче, потому что надежнее. Такая логическая цепочка?
Во-первых, это исследование 5летней давности.
Во-вторых, количество системных вызовов никак не показатель производительности. Связанные вещи — да, но никак не показатель.
Так что давайте, пожалуйста, сравнение (а) свежее (б) про производительность.
Во-вторых, количество системных вызовов никак не показатель производительности. Связанные вещи — да, но никак не показатель.
Так что давайте, пожалуйста, сравнение (а) свежее (б) про производительность.
Я просто контраргументирую за то, почему я считаю, нгинкс или апач надежнее. Не надо быть прорицателем, чтобы понять что даже после 5 лет, IIS не стал более обезжиренным и легким, это как-то не в стиле MS, и пусть это стереотип, пока что он только годами подкрепляется этой конторой. Где каждый новый продукт требует все больше и больше «железа».
Про надежность мы ничего не говорили. Вы при помощи этих картинок пытались доказать, что Апач «шустрее» IIS. На отдаче статики.
А еще до этого — что ngnix якобы полезно поставить перед IIS.
Ну и понятно, что за прошедшие 5 лет Апач стал быстрее, а IIS — медленее, потому что Микрософт полон злых вредителей, так и думающих, как бы замедлить работу своих продуктов и сделать так, чтобы они потребляли больше ресурсов.
А еще до этого — что ngnix якобы полезно поставить перед IIS.
Ну и понятно, что за прошедшие 5 лет Апач стал быстрее, а IIS — медленее, потому что Микрософт полон злых вредителей, так и думающих, как бы замедлить работу своих продуктов и сделать так, чтобы они потребляли больше ресурсов.
Вообще, сбили тему, ветка тут разрослась на тему, зачем нгинкс впереди IIS,
ответ был дан:
habrahabr.ru/blogs/webstandards/137843/#comment_4594905
ответ был дан:
habrahabr.ru/blogs/webstandards/137843/#comment_4594905
И этот ответ «ибо будет быстрее таки, ибо windows server тяжелее обезжиренной под эти цели фрюхи или линукса, ибо судя по карте системных вызовов чисто математически надежнее. »
У меня эти словосочетания вообще никак не связываются друг с другом. В смысле, я тут причинности не вижу.
У меня эти словосочетания вообще никак не связываются друг с другом. В смысле, я тут причинности не вижу.
Ну что ж, учите устройство компьютера с позиции фон Неймановской архитектуры и частной реализации КА, и причинно-следственная связь станет понятной и очевидной. Хотя даже и без того понятно, что балансировщик на windows server это бред — в чем собственно и суть.
Пусщай хомячки дальше срут в карму, на то они и хомячки — не словом и аргументом, дак хоть в спину пырнуть разок :)
Пусщай хомячки дальше срут в карму, на то они и хомячки — не словом и аргументом, дак хоть в спину пырнуть разок :)
Учить что? Выражайте мысли связнее. Архитектура фон Неймана — это архитектура, при которой код и данные хранятся в общем адресном пространстве, в противоположность Гарвардской. Я это выучил в тринадцать лет, наверное. Теперь расскажите, какое это отношение имеет к обсуждаемой теме.
а давай померяемся. Я в этом обсуждении потерял 5 пунктов кармы, ты — один или максимум полтора (при этом я не ставил минус, минусы в карму ставлю только мудакам, которым ты не являешься). Так что не надо плакать )
leotsarev, очевидно и то, что вы не понимаете устройство компьютера на более низком уровне, раз предложение для вас безсвязное.
сорри *бессвязное.
На каком «более низком»? У меня есть опыт программирования на ассемблере х86, этого достаточно, чтобы получить честь разговаривать с вами?
Сосредоточьтесь, и объясните логический переход «надежнее->быстрее».
Сосредоточьтесь, и объясните логический переход «надежнее->быстрее».
Вы как-то сами себя зарываете, и минусую вас не я, у меня такой даже опции нет. Вверху вы говорите, что абстракция это базовый принцип устройства PC, что в принципе с точностью до наоборот, абстракция как раз удел высокоуровневых манипуляций, и вам как вы утверждаете человеку с опытом асма как-то стыдно даже такое говорить вслух.
Во-вторых, не надежнее > быстрее, а надежнее & быстрее.
Мне даже как-то неудобно перед хаброюзерами разжевывать детские вещи,
в стиле — почему при прочих равных спагетти-код менее надежен, почему большая программа занимает больше памяти, почему большое количество вызовов и операций ввода/вывода с памятью делает программу менее быстрой. Если это для вас что-то неочевидное, то у меня для вас плохие новости. Никто не отрицает, что короткая программа может иметь рекурсивный и тормозной путь исполнения с утчеками памяти, но об этом ли речь? Но это частные разницы, а с позиции мат.вероятности при прочих равных — будет так как я и говорю. И уж тем более в контексте Ngnix vs IIS. Бросье оправдываться.
Во-вторых, не надежнее > быстрее, а надежнее & быстрее.
Мне даже как-то неудобно перед хаброюзерами разжевывать детские вещи,
в стиле — почему при прочих равных спагетти-код менее надежен, почему большая программа занимает больше памяти, почему большое количество вызовов и операций ввода/вывода с памятью делает программу менее быстрой. Если это для вас что-то неочевидное, то у меня для вас плохие новости. Никто не отрицает, что короткая программа может иметь рекурсивный и тормозной путь исполнения с утчеками памяти, но об этом ли речь? Но это частные разницы, а с позиции мат.вероятности при прочих равных — будет так как я и говорю. И уж тем более в контексте Ngnix vs IIS. Бросье оправдываться.
Можно и короче выразиться с позиции сухой теории:
Спагетти код vs Бритва Окамма (или принцип KISS)
Спагетти код vs Бритва Окамма (или принцип KISS)
По вашей просьбе пытаюсь сосредоточиться и придумать еще примеры надежнее & быстрее, но готов даже апривести
надежнее > быстрее (хотя вы все равно полезете в частности — мат.вероятность вам не аргумент — я это понял уже):
итак, при прочих равных:
меньше кода > меньше вес программы => меньше занимаемой ей памяти
(особенно если куча форков процесса )
меньше кода > стастически меньше операций ввода/вывода, системных вызовов, обращений к bottle-neck'ам (узким местам), статистически меньший путь проходит указатель процессора (даже если если есть короткие пути типа кеша, все равно переходов по условиям будет много) => работает быстрее
меньше кода > статистически меньше верятность ошибки => надежнее
итого меньше кода => быстрее, ресурсолегче, надежнее
неужели я вынужден писать такое на хабре?
надежнее > быстрее (хотя вы все равно полезете в частности — мат.вероятность вам не аргумент — я это понял уже):
итак, при прочих равных:
меньше кода > меньше вес программы => меньше занимаемой ей памяти
(особенно если куча форков процесса )
меньше кода > стастически меньше операций ввода/вывода, системных вызовов, обращений к bottle-neck'ам (узким местам), статистически меньший путь проходит указатель процессора (даже если если есть короткие пути типа кеша, все равно переходов по условиям будет много) => работает быстрее
меньше кода > статистически меньше верятность ошибки => надежнее
итого меньше кода => быстрее, ресурсолегче, надежнее
неужели я вынужден писать такое на хабре?
хотя опять пример неудачный наверное, вас то какой-то специфический бред интересует… не готов помочь, это уже диагноз, а я не врач.
Да, только сложность алггоритмов обычно обратно пропорциональна объему реализующего их кода.
Пример: при хранении некой колекции в виде простого звязанного списка имеем сложность поиска О(n) но зато простейшую реализацию поиска и вставок, железобетонная надежность. Переходя к дереву получаем сложность от О(log n) в среднем до О(n) в отдельных вырожденных случаях, при этом реализация алгоритмов значительно сложнее, следовательно вероятность ошибок выше, надежность ниже. Переходя к сбалансированному дереву получаем гарантированную сложность поиска О(log n) взамен на дальнейшее усложнение кода — снижение надежности.
Так что «меньше кода => работает быстрее» в общем случае не верно.
Пример: при хранении некой колекции в виде простого звязанного списка имеем сложность поиска О(n) но зато простейшую реализацию поиска и вставок, железобетонная надежность. Переходя к дереву получаем сложность от О(log n) в среднем до О(n) в отдельных вырожденных случаях, при этом реализация алгоритмов значительно сложнее, следовательно вероятность ошибок выше, надежность ниже. Переходя к сбалансированному дереву получаем гарантированную сложность поиска О(log n) взамен на дальнейшее усложнение кода — снижение надежности.
Так что «меньше кода => работает быстрее» в общем случае не верно.
Да ладно, завязывайте уже с миром своих фантазий.
Кто вам сказал, что внутри IIS спагетти-код? На чем вы основываетесь, на картинке с неразличимыми подробностями пятилетней давности, оригинального исследования в интернете больше нет?
Замес в том, что эти картинки не помогут вам понять, почему Апачу нужен легковесный прокси типа nginx, а IIS — не нужен.
Если у вас несколько машин, то перед ними естественно нужен балансировщик, тут вопросов нет. Балансировщик вряд ли IIS, тут вы правы. (Но к IIS в мире кровавого энтерпрайз скорее всего поставят железку балансировщиком).
Но самом по себе IIS не нуждается в проксе, которая будет заниматься тем, что быстро получать ответ от фронтенда и отдавать его тормозному клиенту — потому что такая прокся в IIS уже есть.
Кто вам сказал, что внутри IIS спагетти-код? На чем вы основываетесь, на картинке с неразличимыми подробностями пятилетней давности, оригинального исследования в интернете больше нет?
Замес в том, что эти картинки не помогут вам понять, почему Апачу нужен легковесный прокси типа nginx, а IIS — не нужен.
Если у вас несколько машин, то перед ними естественно нужен балансировщик, тут вопросов нет. Балансировщик вряд ли IIS, тут вы правы. (Но к IIS в мире кровавого энтерпрайз скорее всего поставят железку балансировщиком).
Но самом по себе IIS не нуждается в проксе, которая будет заниматься тем, что быстро получать ответ от фронтенда и отдавать его тормозному клиенту — потому что такая прокся в IIS уже есть.
Минусующих отсылаю сразу в этот камент: habrahabr.ru/blogs/webstandards/137843/#comment_4594838
А IIS + MS более нежные создания, зато умеющие всякие абстракции и плюшки, поэтому такое «добро» чаще рассматривается как сервер приложений, который как бэкенд лучше спрятать за более суровым и аскетичным фронтэндом — даже по причине админской паранои. И да, нам помнятся те недалекие годы когда сайты MS отвечали в заголовках Server:Apache 1.3…
ну вот кроме админской паранойи я не вижу причин.
Постом выше написал про ресурсоемкость.
ага, я уже улыбнулся в монитор, спасибо.
улыбнитесь в этот камент
habrahabr.ru/blogs/webstandards/137843/#comment_4594838
habrahabr.ru/blogs/webstandards/137843/#comment_4594838
А можно пояснить, в чём выражается полудохлость лайти?
Слишком много багов, которые никто не исправляет. Чего только стоит феерический баг с нулевым размером отдаваемых файлов, от которого постоянно страдает тот же mirror.
Ещё забавляет баг с ajax-запросами по ssl из Хрома. Его пофиксили, правда, но только в последней ветке (на которую проще не переходить, а перейти сразу на nginx). Из-за этого на многих сайтов в 17м хроме не работает половина функционала.
Ещё забавляет баг с ajax-запросами по ssl из Хрома. Его пофиксили, правда, но только в последней ветке (на которую проще не переходить, а перейти сразу на nginx). Из-за этого на многих сайтов в 17м хроме не работает половина функционала.
А чем readfile в nginx хуже ядерного модуля IIS?
Отдача файла с диска в сеть выполняется без переброса данных в user-space, непосредственно в ядре.
Или этот IIS модуль умеет много всего? Но какова тогда цена стабильности работы.
Просто не работал с IIS. Интересно, какой профит от этой его архитектуры.
Отдача файла с диска в сеть выполняется без переброса данных в user-space, непосредственно в ядре.
Или этот IIS модуль умеет много всего? Но какова тогда цена стабильности работы.
Просто не работал с IIS. Интересно, какой профит от этой его архитектуры.
На RSDN.ru так.Причин уже не помню, если честно
У меня стоит на KVM гипервизоре nginx (Fedora 16), на котором есть:
1. сайт (PHP) <dyndns.name>,
2. редирект на другой сайт на виртуалку с 2к8 (там домен xxxx.ru на IIS),
3. редирект svn запросов к серверу SVN так же на виртуалке (другой).
ЗЫ: обычный домашний девелоп-серв.
1. сайт (PHP) <dyndns.name>,
2. редирект на другой сайт на виртуалку с 2к8 (там домен xxxx.ru на IIS),
3. редирект svn запросов к серверу SVN так же на виртуалке (другой).
ЗЫ: обычный домашний девелоп-серв.
Смысла как раз очень много: безопасность, failover, уменьшение тормозов за счёт настройки кеширования на Nginx.
Смысл такой связки конечно есть, но какой смысл использовать IIS вместо например Apache?
Безопасность? Какие угрозы можно митигировать, поставив nginx? Failover? Штатная функция IIS. Кеширование? Тоже штатная функция.
Слово-то какое прикольное: «митигировать» :-)
да, млеать, манера разговора радваревцев и арборовцев съедает мой мозг. Не могу найти хороший, ёмкий заменитеь на русском.
Лично я, выставляя closed-source сервер слушать внешние соединения чувствовал бы себя неуютно: одному БГу в достаточно полной мере известно как оно на самом деле работает и сколько там ещё багов…
не, ну можно подумать, ты сделал ревизию всего миллиона строк nginx и делаешь это перед каждым апдейтом?
Резонный вопрос, конечно. Лично я, как можно было ожидать, мягко говоря нет. Но есть обширное коммьюнити, непрестанно, вроде как, перемывающее ему косточки. С моей позиции это, разумеется, всё субъективно (так что я ничего и не утверждаю), но, согласитесь, логика в этом есть.
дада, стандартный ответ «сам не читал, но ведь кто-то читает», я сам так отвечаю всегда на этот вопрос и верю в это. Но это не мешает и в опенсорцные продукты втравливать все, что угодно, вплоть до троянов (вспоминаем историю с proftpd). Да и не делает более легким понимание «как оно на самом деле работает и сколько там ещё багов…» Так что это иллюзия чистой воды, некий аналог верования, дарующая душевное спокойствие, но не более.
К nginx пишут несколько десятков сторонних модулей. Их авторы тщательно отслеживают все изменения кода и api, хотя бы для того, чтобы их модули не переставали исправно работать. И ещё множество разработчиков работает в различных компаниях, пишут и поддерживают собственные, закрытые модули для нужд этих компаний. Про архитектуру и внутреннее устройство nginx рассказывают на конференциях.
Вы сами можете пойти и почитать коммит-логи, мы стараемся их по возможности хорошо документировать [E.G.].
Вы сами можете пойти и почитать коммит-логи, мы стараемся их по возможности хорошо документировать [E.G.].
Также можно подписаться на список рассылки nginx-devel и каждое изменение кода будет приходить сразу к вам на почту. На этот список рассылки подписаны десятки тысяч человек.
дарующая душевное спокойствие, но не более.
А я именно про это и писал, обозначив нехватку оного как «неуютно».
Где вы там миллион строк нашли? =) В nginx всего лишь около 100 тысяч строк кода на Си.
Очень интересная шляпа на графике Sun кстати нарисовалась между 2008 и 2010 годами… И Апач с ней так элегантно прокореллировал…
Я несколько далек от веб-серверов… Но чем так хорош Nginx что о нем с завидной периодичностью можно читать на Хабре? Под какими ОС он работает? На каком языке для него веб-приложения писать надо?
nginx.org/ru/
Великолепная вещь. Надо знать своих героев.
Великолепная вещь. Надо знать своих героев.
а писать под него не надо, это не динамический веб-сервер, это прокси-сервер (реверс). Он не выполняет внешний код.
Ээээ что вы сейчас сказали? Это только прокси-сервер? А FastCGI, а WSGI? А скрипты и правила урлов и поведения? Ну дак тогда и Апач тоже «прокси» сервер для CGI-приложений.
Или я неправильно понял что по-вашему динамический веб-сервер?
надо бы поставить себе веб-сервер Other посмотреть что за фичи у него есть =)
Да, как раз несколько дней назад под новый проект поставил чистый nginx без apache. Можно сказать внес лепту.
Доля на самом деле больше, за счет прозрачных прокси на nginx
Удивительно. Такое впечатление, что люди только-только открыли для себя Netcraft. Теперь каждый месяц будут отчеты про «доля nginx подросла»?
а чем смысл подобных постов? доля nginx ТАК важна?
Теперь вы о каждом изменении статистики на главную писать будете?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Доля Nginx снова немного подросла