asp.net - IIS 6.0通配符映射基准？

Question

我很快就爱上了ASP.NET MVC beta，而我决定不为部署到IIS 6托管环境而牺牲的一件事就是无扩展URL。因此，我正在权衡添加通配符映射的考虑因素，但是我阅读的所有内容都表明使用此方法可能会对性能造成影响。但是，我找不到任何实际的基准!

这个问题的第一部分是，您知道我在哪里可以找到这样的基准，还是只是未经检验的假设？

问题的第二部分是关于我在开发服务器上使用jMeter通过100Mbs连接运行的2个负载测试。

背景信息

我们的托管服务提供商有一个4Gbs易爆互联网管道，其中一个VLAN用于1Gbs Backbone ，因此我在办公室局域网上可以生产的任何内容都应很好地转换为托管环境。

测试场景是加载多个图像/ css文件，因为当请求现在通过ASP.NET ISAPI筛选器传递的文件时，通常会无法通过该文件，因此性能会受到打击。每个测试包含50个线程(模拟用户)，每个线程运行请求脚本1000次迭代。每个测试的结果发布在下面。

测试结果

没有通配符映射:

样本:50,000
平均响应时间:428ms
错误数量:0
每秒请求数:110.1
每秒千字节:11,543

使用通配符映射:

样本:50,000
平均响应时间:429ms
错误数量:0
每秒请求数:109.9
每秒千字节:11,534

两项测试均运行良好(一切都在内存中，没有初始负载偏差)，并且从我的 Angular 来看，性能几乎是均匀的。在两个测试期间，CPU使用率约为60％，内存很好，网络利用率稳定在90-95％附近。

这是否足以证明通过ASP.NET筛选器传递所有内容的通配符映射并不会真正影响性能，还是我错过了一些东西？

编辑:11小时，没有一个评论？我希望有更多..大声笑

Answer 1

克里斯，非常方便的帖子。

许多提出性能劣势的人认为，Web应用程序中处理的代码与标准工作流中处理的代码有何不同/逊色。基本代码类型可能有所不同，并且确定您将需要MSIL解释器，但MS在许多情况下都表明，与本地版本相比，.NET运行时实际上可以提高性能。

考虑IIS如何成为“万事通”的想法也是明智的-允许进行各种配置并覆盖，即使在静态文件上也是如此。其中一些旨在提高性能(缓存，压缩)，并且确实会丢失，除非您在代码中重新实现它们，但其中许多用于其他目的，可能永远不会使用。如果您仅根据需要进行构建，则可以忽略其他部分，即使在ASP.NET可能存在缺点的情况下，也应该实现某种性能优势。

在我的(非.NET)MVC测试中，我发现相对于Web表单，性能可观的好处(十倍或更多)。即使静态内容有小小的损失-吞咽也不是一件容易的事。

我对您的测试中的差异几乎可以忽略不感到惊讶，但是我很高兴看到它得到了备份。

注意:您可以从IIS中的静态目录(我将所有静态文件保留在/ static /(pics | styles | ...)中)禁用通配符映射。将文件夹切换到应用程序，删除通配符映射，然后从应用程序切换回该文件夹，并且-静态文件由IIS处理，而不会影响您的ASP.NET。