IIS 6.0 通配符映射基准？

Question

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

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

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

背景信息

我们的托管服务提供商有一个 4Gbs 的可突发互联网管道和一个用于我们 VLAN 的 1Gbs 骨干网，因此我可以通过办公室局域网生成的任何内容都应该很好地转换为托管环境。

测试场景是加载多个图像/css 文件，因为当请求现在通过 ASP.NET ISAPI 过滤器而通常不会通过它的文件时，假定的性能会受到影响。每个测试包含 50 个线程（模拟用户），每个线程运行 1000 次迭代的请求脚本。每个测试的结果都发布在下面。

测试结果

没有通配符映射：

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

使用通配符映射：

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

两个测试都运行正常（一切都在内存中，没有初始负载偏差），从我的角度来看，性能差不多。在两次测试期间，CPU 使用率约为 60%，内存正常，网络使用率稳定在 90-95% 左右。

这是否足以证明通过所有内容的 ASP.NET 过滤器的通配符映射不会真的影响性能，还是我遗漏了什么？

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

Answer 1

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

许多提出性能劣势的人推断，Web 应用程序中处理的代码与标准工作流程中处理的代码有一些不同/劣势。基本代码类型可能不同，而且您肯定需要 MSIL 解释器，但 MS 已经表明，在许多情况下，您实际上会看到 .NET 运行时的性能比本机运行时有所提高。

考虑 IIS 如何成为“多面手”也是明智的 - 允许各种配置和覆盖即使在静态文件上。其中一些是为提高性能（缓存、压缩）而设计的，并且 - 实际上 - 除非您在代码中重新实现它们，否则它们会丢失，但其中许多是用于其他目的，可能永远不会被使用。如果您（仅）为您的需求而构建，您可以忽略其他部分，并且应该实现某种性能优势，即使存在潜在的 ASP.NET 劣势。

在我的（非 .NET）MVC 测试中，我发现与 Web 表单相比具有相当大的（10 倍或更多）性能优势。即使静态内容受到轻微打击 - 这也不是难以下咽的药丸。

我并不惊讶您的测试中的差异几乎可以忽略不计，但我很高兴看到它得到支持。

注意：您可以在 IIS 中禁用静态目录的通配符映射（我将所有静态文件保存在 /static/(pics|styles|...) 中）。将文件夹切换到应用程序，删除通配符映射，然后将其从应用程序切换回来 - 瞧 - 静态文件由 IIS 处理，而不会打扰您的 ASP.NET。

Answer 2

我认为还有几件事需要检查：

• 由于我们使用的是 .Net ISAPI 过滤器，我们可能会使用线程来运行应用程序以提供静态资产。我会在查看线程的性能计数器时运行相同的负载测试 - Review this link
• 我会在运行 Microsoft Performance Analyzer 的同时运行相同的负载测试并比较报告。

Answer 3

我一直在寻找这样的基准。谢谢！

在我的公司，我们在几个网站（标准 Web 表单、.net1.1 和 2、iis6）上进行了通配符映射，系统管理员对我说他们没有注意到任何性能问题。

但是，您似乎强调的是网络，而不是服务器。所以也许分数如此相似是因为网络瓶颈？只是想...

Answer 4

那里的帖子令人印象深刻，非常感谢。

我们还在评估删除一直存在的用于过滤不需要流量的软件的安全性和性能问题。

您是否会进一步进行基准测试？

干杯，

卡尔。

Answer 5

您的测试中的瓶颈似乎是网络利用率。如果性能下降预计会出现在 CPU 使用率上（我不确定是否如此，但这是合理的），那么您在进行的测试中不会注意到它。

由于这是一个复杂的系统，具有许多变量 - 这并不意味着没有性能下降。这意味着在您的场景中 - 性能下降可能可以忽略不计。