当前位置:  开发笔记 > 后端 > 正文

IIS 6.0通配符映射基准测试?

如何解决《IIS6.0通配符映射基准测试?》经验,为你挑选了1个好方法。

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

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

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

背景资料

我们的托管服务提供商有一个4Gbs可突发的互联网管道,我们的VLAN有一个1Gb骨干,所以我可以通过办公室局域网生产的任何东西都可以很好地转换到托管环境.

测试场景是加载几个图像/ 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小时而不是一个评论?我希望更多..哈哈



1> Rudu..:

克里斯,非常方便的帖子.

许多建议性能劣势的人推断,在Web应用程序中处理的代码与标准工作流中处理的代码有些不同/差.基本代码类型可能不同,并确定您将需要MSIL解释器,但MS在许多情况下表明,您实际上会看到.NET运行时的性能比原生代的要高.

考虑IIS如何成为"所有交易的杰出"也是明智的 - 即使在静态文件上也允许各种配置和覆盖.其中一些是为性能提升(缓存,压缩)而设计的 - 实际上 - 除非您在代码中重新实现它们,否则将丢失,但其中许多用于其他目的,可能永远不会被使用.如果你的构建满足你的需求(只)你可以忽略那些其他的部分,并且应该实现某种性能优势,即使ASP.NET存在潜在的劣势.

在我的(非.NET)MVC测试中,我看到了相对于webforms的相当大(10倍或更多)的性能优势.即使静态内容受到轻微打击 - 这也不是一个难以吞咽的药丸.

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

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

推荐阅读
郑小蒜9299_941611_G
这个屌丝很懒,什么也没留下!
DevBox开发工具箱 | 专业的在线开发工具网站    京公网安备 11010802040832号  |  京ICP备19059560号-6
Copyright © 1998 - 2020 DevBox.CN. All Rights Reserved devBox.cn 开发工具箱 版权所有