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

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

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

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

Фоновая информация

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

Сценарий тестирования заключался в загрузке нескольких изображений /css файлов, так как предполагаемое повышение производительности происходит при запросе файлов, которые теперь передаются через фильтр ASP.NET ISAPI, который обычно не проходит через него. Каждый тест содержал 50 потоков (имитированных пользователей), выполняющих запрос script для 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

Ответ 1

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

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

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

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

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

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

Ответ 2

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

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

Ответ 3

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

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

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

Ответ 4

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

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

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

Приветствия,

Карл.

Ответ 5

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

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