Тесты сопоставления подстановочных знаков IIS 6.0?
Я быстро влюбился в бета-версию ASP.NET MVC, и одна из вещей, которой я решил не жертвовать при развертывании в моей среде хостинга IIS 6, - это URL без расширений. Поэтому я взвешиваю возможность добавления сопоставления с подстановочными знаками, но все, что я читаю, предполагает потенциальное снижение производительности при использовании этого метода. Однако я не могу найти никаких реальных тестов!
Первая часть этого вопроса: знаете ли вы, где я могу найти такие тесты, или это просто непроверенное предположение?
Вторая часть вопроса касается двух нагрузочных тестов, которые я провел с помощью jMeter на нашем сервере разработки через соединение 100 Мбит / с.
Справочная информация
У нашего хостинг-провайдера есть разрывной интернет-канал на 4 Гбит / с с магистралью 1 Гбит / с для нашей 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 часов и ни одного комментария? Я надеялся на большее .. лол
Прошло довольно много времени, но у меня было 4-5 aspx-страниц, которые ссылались на 2-3 таблицы стилей и примерно 20 изображений. Я намеренно не выполнял никаких действий с базой данных на тестовых страницах, так как хотел протестировать только IIS на предмет узких мест.
Ответы 5
Давно искал такой бенчмарк. Спасибо!
В моей компании мы выполняли сопоставление с подстановочными знаками на нескольких веб-сайтах (стандартные веб-формы, .net1.1 и 2, iis6), и системные администраторы сказали мне, что они не заметили никаких проблем с производительностью.
Но, похоже, вы подчеркнули сеть, а не сервер. Так может быть, оценки так похожи из-за узкого места в сети? Просто думаю...
Думаю, есть еще несколько вещей, которые нужно проверить:
- Поскольку мы используем фильтр .Net ISAPI, мы можем использовать потоки, используемые для запуска приложения для обслуживания статических ресурсов. Я бы запустил тот же нагрузочный тест при просмотре счетчиков производительности потоков - Просмотрите эту ссылку
- Я бы запустил тот же нагрузочный тест при запуске Microsoft Performance Analyzer и сравнил отчеты.
Крис, очень удобный пост.
Многие, кто предполагает недостаток производительности, делают вывод, что код, обрабатываемый в веб-приложении, несколько отличается / уступает коду, обрабатываемому в стандартном рабочем процессе. Базовый тип кода может быть другим, и вам наверняка понадобится интерпретатор MSIL, но MS показала, что во многих случаях вы действительно увидите повышение производительности в среде выполнения .NET по сравнению с собственной.
Также разумно подумать о том, что IIS должен быть «мастером на все руки», позволяя любые конфигурации и переопределяя даже на статических файлах. Некоторые из них предназначены для повышения производительности (кеширование, сжатие) и действительно будут потеряны, если вы не переопределите их в своем коде, но многие из них предназначены для других целей и могут никогда не использоваться. Если вы строите для своих нужд (только), вы можете игнорировать эти другие части и должны осознавать какое-то преимущество в производительности, даже если есть потенциальный недостаток ASP.NET.
В моем (не .NET) тестировании MVC я вижу значительное (в 10 раз и более) повышение производительности по сравнению с веб-формами. Даже если статическое содержимое немного пострадает - эту пилюлю было бы не сложно проглотить.
Я не удивлен, что разница в ваших тестах почти ничтожна, но я рад, что она подкреплена.
ПРИМЕЧАНИЕ. Вы можете отключить отображение подстановочных знаков из статических каталогов (я храню все статические файлы в / static / (pics | styles | ...)) в IIS. Переключите папку в приложение, удалите сопоставление с подстановочными знаками и переключите его обратно из приложения, и - вуаля - статические файлы обрабатываются IIS, не приставая к вашему ASP.NET.
Это впечатляющий пост, большое спасибо за это.
Мы также оцениваем проблемы безопасности и производительности, удаляя всегда установленное программное обеспечение для фильтрации нежелательного трафика.
Будет ли проводиться с вашей стороны какое-либо дополнительное тестирование?
Ваше здоровье,
Карл.
Кажется, узким местом в вашем тесте является использование сети. Если ожидается, что снижение производительности будет связано с использованием ЦП (я не уверен, что это так, но это разумно), то вы не заметите этого с помощью теста, который вы сделали.
Поскольку это сложная система с множеством переменных, это не означает, что производительность не снижается. Это означает, что в вашем сценарии - снижение производительности, вероятно, незначительно.
«Сценарий тестирования заключался в загрузке нескольких файлов изображений / css». Не могли бы вы дать здесь более подробную информацию о "нескольких"?