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

Question

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

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

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

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

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

В тестовом сценарии было загружено несколько изображений/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. Переключите папку в приложение, удалите сопоставление подстановочных знаков и переключите его обратно из приложения, и - voilà - статические файлы обрабатываются IIS без приставания к ASP.NET.

Answer 2

Я долгое время искал такой тест. Thanx!

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

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

Answer 3

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

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

Answer 4

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

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

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

Cheers,

Karl.

Answer 5

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

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