Производительность ASP.net MVC с URL без расширения на IIS 6

Question

Мы готовимся к первоначальному развертыванию приложения ASP.net MVC на IIS 6 под управлением Windows Server 2003. Мы читали о проблемах производительности, связанных с использованием URL-адресов без расширений в приложениях MVC, особенно в случае удаления расширения «.aspx» из части контроллера URL.

Кто-нибудь, кто развертывал приложение MVC в прошлом, испытывал снижение производительности в этой области? Было ли это заметно, и стоило ли это иметь более чистые URL? Наше приложение редко будет иметь дело с более чем 1000 одновременно работающих пользователей.

Редактировать: Спасибо за все ответы, он работает довольно хорошо, хотя, как упоминали некоторые люди, есть несколько странных запросов, я думаю, что мы можем обойти их, используя предложения, упомянутые здесь.

Answer 1

Недавно мы развернули приложение, которое получило ок. 20 миллионов просмотров страниц в течение 3-месячного периода с использованием настройки сопоставления подстановочных знаков IIS 6 и проблем с производительностью не было. Мы разместили большинство наших изображений в CDN, но другой статический контент подавался прямо с сайта.

Во всяком случае, IIRC, обработчик asp.net будет передавать запросы на статические типы файлов обратно в IIS через обработчик по умолчанию для обработки. Единственное практическое снижение производительности - это время, в течение которого рабочий поток занят, идентифицируя и передавая запрос. Во всех случаях, кроме самых крайних, это слишком тривиально, чтобы иметь значение.

В качестве дополнительной заметки мы протестировали приложение, о котором я упоминал, до его запуска и обнаружили, что оно может обрабатывать почти 2000 статических запросов в секунду и около 700 запросов в секунду для страниц, связанных с работой базы данных. Сайт размещался на 4 серверах IIS 6 за балансировщиком нагрузки ZXTM с интернет-каналом 1 ГБ.

Вот ссылка с некоторыми полезными советами по всей статической обработке файлов:

http://msmvps.com/blogs/omar/archive/2008/06/30/deploy-asp-net-mvc-on-iis-6-solve-404-compression-and-performance-problems.aspx

Answer 2

Перезапись URL может помочь вам решить проблему. Я реализовал решение, позволяющее развернуть приложение MVC на любой версии IIS даже при использовании виртуального хостинга. http://www.codeproject.com/KB/aspnet/iis-aspnet-url-rewriting.aspx

Answer 3

Мы запустили довольно загруженный сайт с подстановочными знаками IIS6 для URL без расширений, и хотя мы никогда не замечали значительного снижения производительности, у нас был небольшой взлом, который работал довольно хорошо:

Для всех папок, которые содержат только статические файлы, такие как / css, / images, / scripts и т. Д., В IIS мы устанавливаем их как свое собственное приложение и отключаем параметр подстановочного знака, что означало, что IIS обрабатывал запросы, а не маршрутизация через ASP.Net.

Answer 4

Проблема с неиспользованием расширений в IIS 6 заключается в том, что вы не хотите, чтобы статические запросы проходили через стек ASP.NET. Если все ваши статические запросы поступают из одной (или двух ...) подпапок (папок), вы можете исключить их . Это должно исправить проблему производительности.

Цитата из связанного поста:

Теперь, чтобы удалить карту подстановки на / Подкаталог содержимого, откройте команду подскажите, перейдите в c: \ Inetpub \ AdminScripts, и запустить:

adsutil.vbs SET / W3SVC / 105364569 / root / Content / ScriptMaps ""

… замена 105364569 на «Идентификатор» номер вашего приложение. (Также вы можете заменить «Контент» с указанием пути к любому другому каталог.)

Answer 5

Вместо того, чтобы обслуживать все запросы ASP.NET, вы можете указать, например, mvc как расширение (скажем, index.mvc) и сопоставьте это расширение с aspnet_isapi.dll в IIS 6. Это означает, что asp.net будет обрабатывать только известные расширения, другие, такие как статические файлы, останутся такими же, как и прежде, т.е. обслуживаются самим IIS.