Тесты сопоставления подстановочных знаков в IIS 6.0?

Question

Я быстро влюбляюсь в бета-версию ASP.NET MVC, и я решил, что не буду жертвовать развертыванием в своей среде размещения IIS 6, это URL-адрес без расширения. Поэтому я взвешиваю соображения о добавлении подстановочного сопоставления, но все, что я прочитал, предполагает потенциальное снижение производительности при использовании этого метода. Тем не менее, я не могу найти какие-либо фактические ориентиры!

Первая часть этого вопроса: знаете ли вы, где я могу найти такие критерии, или это просто непроверенное предположение?

Вторая часть вопроса касается двух нагрузочных тестов, которые я запускал, используя jMeter на нашем dev-сервере через соединение 100 Мбит / с.

Справочная информация

У нашего хостинг-провайдера есть доступная интернет-труба 4 Гбит / с с магистралью 1 Гбит для нашей VLAN, поэтому все, что я могу создать по локальной сети офиса, должно хорошо подходить для среды хостинга.

Тестовый сценарий состоял в том, чтобы загрузить несколько файлов images / css, так как предполагаемое снижение производительности происходит при запросе файлов, которые сейчас проходят через фильтр ASP.NET ISAPI, который обычно не проходит через него. Каждый тест содержал 50 потоков (симулированных пользователей), выполняющих скрипт запроса по 1000 итераций каждый. Результаты каждого теста размещены ниже.

Результаты испытаний

Без сопоставления по шаблону:

Samples: 50,000
Average response time: 428ms
Number of errors: 0
Requests per second: 110.1
Kilobytes per second: 11,543

с сопоставлением по шаблону:

Samples: 50,000
Average response time: 429ms
Number of errors: 0
Requests per second: 109.9
Kilobytes per second: 11,534

Оба теста были прогреты (все было в памяти, без смещения начальной нагрузки), и, с моей точки зрения, производительность была примерно одинаковой. Загрузка процессора составляла приблизительно 60% в течение обоих тестов, память была в порядке, а использование сети оставалось стабильным около 90-95%.

Является ли это достаточным доказательством того, что сопоставления с подстановочными знаками, которые проходят через фильтр ASP.NET для ВСЕГО контента, действительно не влияют на производительность, или я что-то упустил?

Редактировать: 11 часов и ни одного комментария? Я надеялся на большее .. LOL

Answer 1

Крис, очень удобный пост.

Многие, кто предлагает недостаток производительности, делают вывод, что код, обрабатываемый в веб-приложении, несколько отличается от кода, обрабатываемого в стандартном рабочем процессе, или уступает ему. Базовый тип кода может отличаться, и вам наверняка понадобится интерпретатор MSIL, но MS показала, что во многих случаях вы действительно увидите увеличение производительности среды выполнения .NET по сравнению с собственным.

Также целесообразно рассмотреть вопрос о том, как IIS должен быть «мастером на все руки», допускающим всевозможные конфигурации и переопределения даже для статических файлов . Некоторые из них предназначены для повышения производительности (кэширование, сжатие) и - действительно - будут потеряны, если вы не переопределите их в своем коде, но многие из них предназначены для других целей и могут никогда не использоваться. Если вы строите для своих нужд (только), вы можете игнорировать эти другие части и должны реализовать какое-то преимущество в производительности, даже если есть потенциальный недостаток ASP.NET.

В моем (не .NET) тестировании MVC я вижу значительные (в 10 и более раз) преимущества в производительности по сравнению с веб-формами. Даже если бы был небольшой удар по статическому контенту - это не будет жесткой пилюлей.

Я не удивлен, что разница в ваших тестах почти ничтожна, но я рад, что это подтверждается.

ПРИМЕЧАНИЕ. Вы можете отключить сопоставление по шаблону из статических каталогов (я храню все статические файлы в / static / (pics | styles | ...)) в IIS. Переключите папку на приложение, удалите сопоставление с подстановочными знаками и снова переключите его из приложения, и - вуаля - статические файлы обрабатываются IIS без приставания к ASP.NET.

Answer 2

Я думаю, что есть несколько дополнительных вещей, которые нужно проверить:

• Поскольку мы используем ISAPI-фильтр .Net, мы можем использовать потоки, используемые для запуска приложения для обслуживания статических ресурсов. Я бы запустил тот же нагрузочный тест при просмотре счетчиков производительности потоков - Просмотрите эту ссылку
• Я бы запустил тот же нагрузочный тест при запуске Microsoft Performance Analyzer и сравнил бы отчеты.

Answer 3

Я долго искал такой тест. Thanx!

В моей компании мы делали сопоставление с подстановочными знаками на нескольких веб-сайтах (стандартные веб-формы, .net1.1 и 2, iis6), и администраторы sys сказали мне, что не заметили каких-либо проблем с производительностью.

Но, похоже, вы подчеркнули сеть, а не сервер. Так что, может быть, оценки так похожи, потому что узкое место в сети? Просто думаю ...

Answer 4

Кажется, что узким местом в вашем тесте является использование сети. Если ожидается снижение производительности при загрузке процессора (я не уверен, что это так, но это разумно), то вы не заметите этого в тесте, который вы сделали.

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

Answer 5

Это довольно впечатляющий пост, большое спасибо за это.

Мы также оцениваем проблемы безопасности и производительности, удаляя часть программного обеспечения, которая всегда была в наличии для фильтрации нежелательного трафика.

Будут ли какие-либо дальнейшие измерения с вашей стороны?

Приветствия

Karl.