IIS 6.0通配符映射基准？ [英] IIS 6.0 wildcard mapping benchmarks?

问题描述

我很快爱上了ASP.NET MVC的测试版，和的事情我已经决定，我不会在部署到我IIS 6宿主环境牺牲一个是扩展名的URL。因此，我权衡考虑增加一个通配符映射，但使用这种方法时，一切我读暗示潜在的性能问题。但是，我找不到任何实际的基准！

I'm quickly falling in love with ASP.NET MVC beta, and one of the things I've decided I won't sacrifice in deploying to my IIS 6 hosting environment is the extensionless URL. Therefore, I'm weighing the consideration of adding a wildcard mapping, but everything I read suggests a potential performance hit when using this method. However, I can't find any actual benchmarks!

这个问题的第一部分，你知道我在哪里可以找到这种基准，或者是它只是一个未经测试的假设？

The first part of this question is, do you know where I might find such benchmarks, or is it just an untested assumption?

问题的第二部分是关于2负载测试我们的我过的100Mbs连接开发服务器上使用JMeter的跑了。

The second part of the question is in regards to the 2 load tests I ran using jMeter on our dev server over a 100Mbs connection.

背景信息

我们的托管服务提供商，拥有4Gbs破裂的管道网络与1Gbs骨干VLAN我们，所以什么可以产生超过办公局域网应该很好的转化到托管环境。

Our hosting provider has a 4Gbs burstable internet pipe with a 1Gbs backbone for our VLAN, so anything I can produce over the office lan should translate well to the hosting environment.

测试场景是加载多个图像/ css文件，因为所谓的性能损失来要求，目前正在通过ASP.NET ISAPI筛选器通常不会通过它传递文件时。每个测试包含50个线程（模拟用户）运行的每个1000次迭代请求脚本。每一个测试的结果如下帐

The test scenario was to load several images / css files, since the supposed performance hit comes when requesting files that are now being passed through the ASP.NET ISAPI filter that would not normally pass through it. Each test contained 50 threads (simulated users) running the request script for 1000 iterations each. The results for each test are posted below.

测试结果

如果没有通配符映射：

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％。

Both tests were run warm (everything was in memory, no initial load bias), and from my perspective, performance was about even. CPU usage was approximately 60% for the duration of both tests, memory was fine, and network utilization held steady around 90-95%.

这是足以证明，通过ASP.NET的滤波器通的所有内容通配符映射没有的真正的影响性能，还是我失去了一些东西？

Is this sufficient proof that wildcard mappings that pass through the ASP.NET filter for ALL content don't really affect performance, or am I missing something?

编辑：11小时不是一个单一的评论？我希望的更多......哈哈

11 hours and not a single comment? I was hoping for more.. lol

推荐答案

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

Chris, very handy post.

许多谁主张推断，在Web应用程序处理code是一个性能劣势一些如何不同的/逊色于标准的工作流程处理code。该基地code型可能不同，相信你会需要的MSIL间preTER，但MS已经显示出在很多情况下，你会真正看到了一个原生之一的.NET运行时的性能提升。

Many who suggest a performance disadvantage infer that the code processed in a web application is some how different/inferior to code processed in the standard workflow. The base code type maybe different, and sure you'll be needing the MSIL interpreter, but MS has shown in many cases you'll actually see a performance increase in a .NET runtime over a native one.

这也是明智的考虑如何IIS已成为一个的所有行业插孔 - 允许各种配置和覆盖的即使在静态文件即可。其中有些是专为性能提升（高速缓存，玉米pression）和 - 实际上 - 将会丢失，除非你在code重新实现它们，但其中不少是用于其他目的，不得被使用。如果你建立你的需要（只），你可以忽略其他部分，应实现某种性能优势，即使有一个潜在的ASP.NET的缺点。

It's also wise to consider how IIS has to be a "jack of all trades" - allowing all sorts of configuration and overrides even on static files. Some of those are designed for performance increase (caching, compression) and - indeed - will be lost unless you reimplement them in your code, but many of them are for other purposes and may not ever be used. If you build for your needs (only) you can ignore those other pieces and should be realising some kind of performance advantage, even though there's a potential ASP.NET disadvantage.

在我的（non-.NET）MVC的测试，我看到大量的（10倍以上）在网络表单的性能优势。即使出现了一个小砸在静态内容 - 这不会是一个艰难的药丸吞下

In my (non-.NET) MVC testing I'm seeing considerable (10x or more) performance benefits over webforms. Even if there was a small hit on the static content - that wouldn't be a tough pill to swallow.

我并不感到惊讶的区别是在你的测试几乎可以忽略，但我很高兴看到它进行备份。

I'm not surprised the difference is almost negligible in your tests, but I'm happy to see it backed up.

请注意：您可以禁用从静态目录（我把所有的静态文件在/静态/（图片样式| ...））通配符映射在IIS中。文件夹切换到某个应用程序，请删除通配符映射，并切换从应用程序和背部 - 瞧 - 静态文件由IIS处理，而不纠缠着你的ASP.NET

NOTE: You can disable wildcard mapping from static directories (I keep all static files in /static/(pics|styles|...)) in IIS. Switch the folder to an application, remove the wildcard mapping, and switch it back from an application and - voilà - static files are handled by IIS without pestering your ASP.NET.

这篇关于IIS 6.0通配符映射基准？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！