我们正准备在 Windows Server 2003 上运行的 IIS 6 上进行 ASP.net MVC 应用程序的初始部署。我们一直在阅读有关在 MVC 应用程序中使用无扩展 url 的性能问题，特别是在这种情况下从 url 的控制器部分删除“.aspx”扩展名。
过去部署过 MVC 应用程序的人是否在这方面遇到过任何性能下降？它是否引人注目，是否值得拥有更清晰的 URL？我们的应用程序很少需要处理超过 1000 个左右的并发用户。
编辑：感谢所有回复，它工作得很好，虽然有些人提到了一些奇怪的请求，但我认为我们可以使用这里提到的建议来解决这些问题。
【问题讨论】：
标签： asp.net-mvc performance url iis-6 url-rewriting
在 IIS 6 上不使用扩展的问题是您不希望静态请求通过 ASP.NET 堆栈。如果您的所有静态请求都来自一个（或两个...）子文件夹，you can exclude them。这应该可以解决性能问题。
引用链接的帖子：
现在，要删除通配符映射 /Content 子目录，打开一个命令 提示，转到 c:\Inetpub\AdminScripts， 并运行：
adsutil.vbs SET /W3SVC/105364569/root/Content/ScriptMaps ""
… 将 105364569 替换为 您的“标识符”号码 应用。 （另外，你可以替换 “内容”与任何其他的路径 目录。）
【讨论】：
您可以指定例如，而不是通过 ASP.NET 处理所有请求mvc 作为扩展名（比如 index.mvc）并将该扩展名映射到 IIS 6 中的 aspnet_isapi.dll。 这意味着只有已知的扩展将由 asp.net 处理，其他静态文件如静态文件保持与以前相同，即由 IIS 本身提供服务。
【讨论】：
我们最近部署了一个应用程序，收到了大约。使用 IIS 6 通配符映射设置在 3 个月内有 2000 万次页面查看，没有性能问题。我们确实在 CDN 上托管了大部分图片，但其他静态内容是直接从该网站提供的。
对于它的价值，IIRC，asp.net 处理程序将通过默认处理程序将静态文件类型的请求传递回 IIS 进行处理。唯一实际的性能损失是在该过程中工作线程被占用识别和传输请求的时间。除了最极端的情况外，在所有情况下，这都是微不足道的。
作为额外说明，我们在上线之前对我提到的应用程序进行了负载测试，发现它每秒可以处理近 2000 个静态请求，并且每秒可以处理大约 700 个涉及数据库活动的页面请求。该网站托管在 ZXTM 负载平衡器后面的 4 台 IIS 6 服务器上，带有 1GB 互联网管道。
这是一个关于整个静态文件处理业务的一些好的建议的链接：
【讨论】：
我们运行了一个相当繁忙的网站，它为无扩展 URL 启用了 IIS6 通配符，虽然我们从未注意到性能受到太大影响，但我们确实有一个运行良好的小技巧：
对于所有包含仅静态文件的文件夹，如 /css、/images、/scripts 等，在 IIS 中我们将它们设置为自己的应用程序，并禁用通配符设置，这意味着 IIS 已处理请求而不是通过 ASP.Net 路由。
【讨论】：
网址重写可以帮助您解决问题。我已经实现了允许在任何 IIS 版本上部署 MVC 应用程序的解决方案，即使使用虚拟主机也是如此。 http://www.codeproject.com/KB/aspnet/iis-aspnet-url-rewriting.aspx
【讨论】：