Comments 46
О, IIS похоже на извилины мозга. Может это, наоборот, хорошо?
Чем больше вызовов всяких тем больше надо процессорного времени и памяти, а эти ресурсы крайне ограничены при хостинге. Сейчас многие сайты уже отказываются или уменьшают нагрузку на апач т.к. он потребляет больше ресурсов чем альтернативные серверы при отдаче информации пользователю.
Именно Апач? А IIS?
Apache заменяют обычно там, где идет жестокая раздача статики. Т.е. динамику направляем через Apache+PHP, а статику — через что-нибудь быстрое и легкое.
В случае Microsoft выбора веб-сервера на замену IIS просто нет. Так что стандартно рекомендуется использовать Microsoft'овский же HTTP-акселератор между IIS и внешней сетью.
В случае Microsoft выбора веб-сервера на замену IIS просто нет. Так что стандартно рекомендуется использовать Microsoft'овский же HTTP-акселератор между IIS и внешней сетью.
Что значит выбора веб-сервера нет? Куда задевался выбор?
Ok. На что стоит заменить IIS на Windows-хостинге для отдачи статики.
Никогда не задумывался честно говоря... Даже на нагруженных сиджах при правильном подходе к разработке движка, а именно при грамотном использовании встроенного в asp.net кеширования, ни разу не приходилось разносить математику и статику...
Я бы кстати переделал под свои цели какой-нибудь web-сервер из болванки с codeproject.com... Например этот: http://www.codeproject.com/cs/internet/C…
Продолжу мысль: IIS похож на логотип Habrahabr!
Хотя материал и не потерял свою актуальность, но уже достаточно обсуждался прошлой весной.
Пока нет крупных картинок, на которых можно проверить правильность выкладок или хотя бы сам принцип, все это - просто маркетинговый треп.
Картинки, конечно, красивые. Но реально только на их основании нельзя делать выводов о надежности того или иного решения.
Ни о чём не говорит. От апача всё равно отказываются выдаче большого кол-ва контента. Знакомый держит 300 сиджей на одном серваке, дык недавно разделил на два сервака: один apache, другой lighthttpd для статики. А вот iis на таком же серваке в том же датацентре вполне сносно переносит в 1.5 раза большую нагрузку (по хитам)... Хзтул(С) короче все эти сравнения. Никогда не знаешь что есть труъ.
Hint: ни в исходной статье, ни в моем рассказе о ней не рассматривается вопрос производительности. Вообще. :)
И производительность, разумеется, не зависит напрямую от количества вызовов.
И производительность, разумеется, не зависит напрямую от количества вызовов.
За кроссплатформенность всегда приходится платить производительностью. Ну нету у Apache ни цели, ни возможности затачивать сервер только под Win или только под *nix.
ЗЫ Хотя насчет того что производительнее, действительно ХЗ :)
ЗЫ Хотя насчет того что производительнее, действительно ХЗ :)
IMHO, дело здесь не в кроссплатформенности. Просто у Apache уже давно есть живующие бок-о-бок с ним конкуренты, которые радикально лучше выполняют специфическую задачу раздачи статики. Так что на месте разработчиков было бы неразумно тратить время на то, чтобы занять и эту нишу. Возни много, а смысла нет.
Я конечно вижу, что у IIS больше вызовов, но картинка выглядит особенно пугающей, за счет связей на ней. Так вот, мне чего-то кажеться, что упорядочив расположения вызовов на картинке, можно было бы добиться и менее пугающего вида. А так, тут уже многими сказано об отсутствии картинок с нормальным размером, я тоже сделаю вывод, что это ничего не представляющее из себя исследование.
Сделал бы он ещё карту для nginx.
Интересно, а на чем основаны эти картинки? Конкретно интересует IIS. Т.е. как автор этих шедевров выявил все связи и вызовы?
Было бы так же интересно взглянуть на полноразмерные изображения.
Было бы так же интересно взглянуть на полноразмерные изображения.
Оригинал: http://blogs.zdnet.com/threatchaos/?p=31…
Чуть большие картинки: Apache, IIS
К сожалению названий функций всё равно не видать ):
Чуть большие картинки: Apache, IIS
К сожалению названий функций всё равно не видать ):
Thanks to Sana Security for generating and providing these images.
непонятно как графическая карта вызовов показывает безопасноть. вся фильтрация может производиться и в одном модуле, и тогда получится ровная прямая линия.
помоему, все что она показывает - это карту вызовов, не больше ;))
помоему, все что она показывает - это карту вызовов, не больше ;))
"Аргументация автора звучит разумно: каждый лишний вызов представляет собой дополнительную точку, в которой может возникнуть ошибка. Неправильная передача параметра, недостаточный контоль за диапазоном значений, переполнение стека и т.п. — все это те потенциальные проблемы, которые должны быть подвергнуты тестированию и анализу. И это те проблемы, которые потенциально могут быть использованы при взломе."
вы признаете одинаковое качество кода?
Лично я считаю, что качество кода Apache и качество кода IIS, как давно существующих и развивающихся продуктов, определяется не личными качествами какого-либо выдающегося или отстающего программиста, а средними по отрасли характеристиками кода.
Соответственно, в пределах точности, необходимой для данного обсуждения, :) я считаю качество кода в обоих случаях одинаковым.
Соответственно, в пределах точности, необходимой для данного обсуждения, :) я считаю качество кода в обоих случаях одинаковым.
Это не так.
Код Апаче доступен для изучения и критики сотням миллионов желающих в силу его открытости.
Код IIS доступен лишь небольшой группе строго ограниченных товарищей в пределах одной компании, и шансы его небезошибочности во столько же раз выше. Что, между прочим, неоднократно доказывалось практикой, то бишь историй обнаружения уязвимостей в обоих продуктах. IIS был просто притчей во языцех в этом смысле, вспомните Code Red (кто помнит 2001 год).
Код Апаче доступен для изучения и критики сотням миллионов желающих в силу его открытости.
Код IIS доступен лишь небольшой группе строго ограниченных товарищей в пределах одной компании, и шансы его небезошибочности во столько же раз выше. Что, между прочим, неоднократно доказывалось практикой, то бишь историй обнаружения уязвимостей в обоих продуктах. IIS был просто притчей во языцех в этом смысле, вспомните Code Red (кто помнит 2001 год).
http://blogs.zdnet.com/Ou/index.php?page…
Note that IIS 6.0 since 2003 has only had two moderately critical flaws which is really quite amazing for a web server. Apache 2.0 has had more than 10 times the number of flaws in the same time period and some of which were more critical.
Note that IIS 6.0 since 2003 has only had two moderately critical flaws which is really quite amazing for a web server. Apache 2.0 has had more than 10 times the number of flaws in the same time period and some of which were more critical.
Очень показательное сравнение. В том плане, что в списке апачевских дефектов есть дефекты функционала, которые в случае Microsoft реализованы не в IIS. Например, проблемы, связанные с работой http-акселератора. У Microsoft, если мне память не изменяет, за это отвечает ISA. И патчи секьюрити к нему выпускались.
Кроме того, в этой заметке применен и другой демагогический прием: игра на том факте, что у Apache и IIS совершенно разный подход к нумерации версий. Сравнивается одна лишь шестая версия со всем семейством Apache 2.x на всех платформах.
Нет, я согласен, что подход MS к безопасности в последние 5 лет стал радикально более серьезным. Но когда дело доходит до пиара, то основным инструментом опять становится демагогия.
Кроме того, в этой заметке применен и другой демагогический прием: игра на том факте, что у Apache и IIS совершенно разный подход к нумерации версий. Сравнивается одна лишь шестая версия со всем семейством Apache 2.x на всех платформах.
Нет, я согласен, что подход MS к безопасности в последние 5 лет стал радикально более серьезным. Но когда дело доходит до пиара, то основным инструментом опять становится демагогия.
А какая разница что стоит на backend'e?
На frontend выставляем Squid соответственно настроеный и он будет замечательно заниматся раздачей всего чего душе угодно: статику, динамику.
Динамику он частично закэширует, статику - полностью. И при большой нагрузке backend будет работать на несколько порядков реже, что приведёт к уменьшению нагрузки.
В отличии от Apache IIS позволяет особо тяжёлые страницы выкладывать на отдельный сервер для обработки и становится в кластер.
Скажем мы имеем портал, который обновляется раз в 5 минут при 100 тыс запросов в минуту - 499 тыс. уйдёт в Squid (или какой другой прокси-сервер), а только 500.000 запрос уйдёт в backend.
При этом результат осядет в прокси-сервере и следующие 499 тыс будут нормально работать.
P.S.
Стараницы с какой-то уж. очень тяжёлой нагрузкой - выносим на отдельные сервера.
На frontend выставляем Squid соответственно настроеный и он будет замечательно заниматся раздачей всего чего душе угодно: статику, динамику.
Динамику он частично закэширует, статику - полностью. И при большой нагрузке backend будет работать на несколько порядков реже, что приведёт к уменьшению нагрузки.
В отличии от Apache IIS позволяет особо тяжёлые страницы выкладывать на отдельный сервер для обработки и становится в кластер.
Скажем мы имеем портал, который обновляется раз в 5 минут при 100 тыс запросов в минуту - 499 тыс. уйдёт в Squid (или какой другой прокси-сервер), а только 500.000 запрос уйдёт в backend.
При этом результат осядет в прокси-сервере и следующие 499 тыс будут нормально работать.
P.S.
Стараницы с какой-то уж. очень тяжёлой нагрузкой - выносим на отдельные сервера.
баян, читал уже на лоре с год назад
Какие крупные порталы типа, скажем, Яндекса, юзают IIS?
Sign up to leave a comment.
Apache vs IIS