IIS 6.0通配符映射基准？
我很快就爱上了ASP.NET MVCtesting版，而且我决定在部署到我的IIS 6宿主环境中不会牺牲的一个东西是无扩展名的URL。 因此，我正在考虑添加通配符映射，但是我读到的所有内容都暗示了使用此方法时潜在的性能问题。 但是，我找不到任何实际的基准！
这个问题的第一部分是，你知道我在哪里可以find这样的基准，还是只是一个未经考验的假设？
问题的第二部分是关于在我们的开发服务器上通过100Mbs连接使用jMeter运行的2个负载testing。
背景信息
我们的托pipe服务提供商有一个4Gbs的可突破的互联网pipe道，为我们的VLAN提供了1Gbs的骨干网，所以任何可以通过办公室局域网产生的东西都应该很好地转化为托pipe环境。
testing场景是加载多个图像/ css文件，因为当请求正在通过ASP.NET ISAPI筛选器传递的文件时，会出现所谓的性能问题。 每个testing包含50个线程（模拟用户），每个线程运行请求脚本1000次迭代。 每个testing的结果都张贴在下面。
检测结果
没有通配符映射：
样品：50,000 平均响应时间：428ms 错误数量：0 每秒请求数：110.1 每秒千字节：11,543
使用通配符映射：
样品：50,000 平均响应时间：429ms 错误数量：0 每秒请求数：109.9 每秒千字节数：11,534
两个testing都运行良好（一切都在记忆中，没有初始负载偏差），从我的angular度来看，性能差不多。 在两次testing期间，CPU使用率约为60％，内存很好，networking利用率稳定在90-95％左右。
这足以certificate通过所有内容的ASP.NETfilter的通配符映射不会真正影响性能，还是我错过了一些东西？
编辑：11小时，而不是一个单一的评论？ 我希望更多..大声笑
克里斯，非常方便的职位。
许多build议性能劣势的人推断，在Web应用程序中处理的代码与标准工作stream程中处理的代码有些差异/差异。 基本代码types可能不同，并确定您将需要MSIL解释器，但MS已经显示，在许多情况下，实际上您会看到.NET运行时性能提高了。
考虑IIS如何成为所有行业的“杰作”也是明智之举 – 即使在静态文件上也可以进行各种configuration和覆盖。 其中一些是为提高性能（caching，压缩）而devise的，实际上，除非在代码中重新实现它们，否则它们将会丢失，但其中许多是用于其他目的的，可能永远不会被使用。 如果你只是为了自己的需求而构build，那么你可以忽略其他的部分，并且应该实现某种性能优势，即使ASP.NET有潜在的劣势。
在我的（非.NET）MVCtesting中，我看到了相当大的（10倍或更多）性能优势。 即使静态内容有一些小小的变化，这也不是一个难以忍受的难题。
我并不感到惊讶，你的testing几乎可以忽略不计，但我很高兴看到它的备份。
注：您可以从静态目录禁用通配符映射（我将所有静态文件保存在/静态/（图片|样式| …））在IIS中。 切换到一个应用程序的文件夹，删除通配符映射，并从应用程序切换回来 – 静态文件是由IIS处理，而不用纠缠你的ASP.NET。
我认为还有几件事要检查：
- 由于我们使用.Net ISAPI筛选器，因此我们可能会使用用于运行应用程序的线程来提供静态资产。 我将在审查线程的性能计数器时运行相同的负载testing – 查看此链接
- 我将运行Microsoft性能分析器运行相同的负载testing并比较报告。
我一直在寻找这样的基准。 感谢名单！
在我的公司，我们在几个网站（标准的Web表单，.net1.1和2，iis6）上做了通配符映射，系统pipe理员对我说，他们没有注意到任何性能问题。
但是，你似乎强调networking，而不是服务器。 所以也许分数是如此相似，因为networking瓶颈？ 只是想…
这是一个相当令人印象深刻的职位，非常感谢。
我们也在评估安全性和性能方面的问题，删除一直存在的软件以过滤掉不需要的stream量。
请问你有没有进一步的基准？
干杯，
卡尔。
看来你testing中的瓶颈是networking利用率。 如果性能降低预计会在CPU使用率上（我不确定是否合理），那么您将不会注意到您所做的testing。
由于这是一个复杂的系统，有许多variables – 这并不意味着性能不会下降。 这意味着在你的情况下 – 性能下降可能可以忽略不计。
