代码之家  ›  专栏  ›  技术社区  ›  Chris

IIS6.0通配符映射基准?

  •  35
  • Chris  · 技术社区  · 16 年前

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

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

    问题的第二部分是关于我在我们的dev服务器上通过100mbs连接使用jmeter运行的两个负载测试。

    背景信息

    我们的主机提供商有一个4GB的可Burstable网管,为我们的VLAN提供了1GB的主干网,所以我在办公室局域网上生产的任何产品都可以很好地转化为主机环境。

    测试方案是加载多个images/css文件,因为在请求当前正在通过ASP.NET ISAPI过滤器(通常不会通过该过滤器)传递的文件时,会遇到假定的性能问题。每个测试包含50个线程(模拟用户),每个线程运行请求脚本1000次迭代。每个测试的结果发布在下面。

    试验结果

    不带通配符映射:

    Samples: 50,000
    Average response time: 428ms
    Number of errors: 0
    Requests per second: 110.1
    Kilobytes per second: 11,543
    

    使用通配符映射:

    Samples: 50,000
    Average response time: 429ms
    Number of errors: 0
    Requests per second: 109.9
    Kilobytes per second: 11,534
    

    两个测试都是热运行的(所有的东西都在内存中,没有初始的负载偏差),从我的角度来看,性能是差不多的。两次测试的CPU使用率约为60%,内存良好,网络使用率稳定在90-95%左右。

    这是否足以证明通过所有内容的ASP.NET筛选器的通配符映射不会 真的? 影响性能,还是我错过了什么?

    编辑:11个小时,不是一条评论?我希望有更多……大声笑

    5 回复  |  直到 13 年前
        1
  •  6
  •   Rudu Andrew Whitaker    15 年前

    克里斯,非常便利的帖子。

    许多提出性能劣势的人推断,在Web应用程序中处理的代码与在标准工作流中处理的代码有多大不同/差。基本代码类型可能不同,当然您需要MSIL解释器,但在许多情况下,MS显示.NET运行时的性能实际上比本机运行时有所提高。

    考虑到IIS必须是一个“万能工具”,允许各种配置和覆盖,这也是明智的。 即使在静态文件上 . 其中一些是为提高性能(缓存、压缩)而设计的,而且——实际上——除非您在代码中重新实现它们,否则将丢失它们,但其中许多都是用于其他目的,并且可能永远不会被使用。如果您是为自己的需要而构建的,那么您可以忽略其他部分,并且应该实现某种性能优势,即使存在潜在的ASP.NET劣势。

    在我的(非.NET)MVC测试中,我看到了比WebForms更大的(10倍或更多)性能优势。即使对静态内容有一点影响,也不难吞下。

    我并不惊讶在你的测试中差异几乎可以忽略不计,但是我很高兴看到它被备份了。

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

        2
  •  4
  •   joeysim    16 年前

    我认为还有几点需要检查:

    • 因为我们使用的是.NET ISAPI过滤器,所以我们可能正在使用用于运行应用程序的线程来提供静态资产服务。我将在查看线程的性能计数器时运行相同的负载测试- Review this link
    • 我将在运行Microsoft性能分析器时运行相同的负载测试,并比较这些报告。
        3
  •  1
  •   Hrvoje Hudo    16 年前

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

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

    但是,似乎你强调的是网络,而不是服务器。所以也许分数是如此相似,因为网络瓶颈?只是在想…

        4
  •  0
  •   Karl    15 年前

    那是一篇令人印象深刻的文章,非常感谢。

    我们还评估了安全性和性能方面的问题,删除了一个始终处于适当位置以过滤不需要的流量的软件。

    你方是否会通过进一步的基准测试?

    干杯,

    卡尔。

        5
  •  0
  •   Eitan Burcat    13 年前

    您的测试中的瓶颈似乎是网络利用率。如果性能下降预计是由于CPU使用率(我不确定这是合理的,但这是合理的),那么在进行测试时,您不会注意到这一点。

    因为这是一个复杂的系统,有许多变量——这并不意味着没有性能下降。这意味着在您的场景中,性能下降可能可以忽略不计。