Azure for Owin/IIS应用程序的性能不佳
ste*_*tej 15 c# performance cpu-usage azure
我们测量了一些执行测试,我注意到CPU在内核模式下运行了很多时间.我想知道为什么会这样.
应用程序:它是经典的Azure云服务Web角色,其中Owin正在IIS下监听,而Owin本身只提供缓存在内存中的静态文件(因此应该只有一点性能损失,而且每个都应该非常快).内容将复制await stream.CopyToAsync(response.Body)到输出流.
测试本身在加特林看起来像这样:
val openLoginSet = exec(http("ROOT")
.get("/")
.headers(Headers105Test2.headers_0)
.resources(
http("MED: arrow-down-small.png").get(uriIconAssets + "/arrow-down-small.png").headers(Headers105Test2.headers_1),
http("MED: arrow-up-small.png").get(uriIconAssets + "/arrow-up-small.png").headers(Headers105Test2.headers_1),
http("MED: close-medium.png").get(uriIconAssets + "/close-medium.png").headers(Headers105Test2.headers_1),
http("MED: decline-medium.png").get(uriIconAssets + "/decline-medium.png").headers(Headers105Test2.headers_1),
http("MED: help-medium.png").get(uriIconAssets + "/help-medium.png").headers(Headers105Test2.headers_1),
http("MED: submit-medium.png").get(uriIconAssets + "/submit-medium.png").headers(Headers105Test2.headers_1),
http("MED: delete-medium.png").get(uriIconAssets + "/delete-medium.png").headers(Headers105Test2.headers_1),
http("MED: en-us.js").get("/en-us.js").headers(Headers105Test2.headers_8),
http("MED: cloud_logo_big.png").get("/assets/cloud_logo_big.png").headers(Headers105Test2.headers_1),
http("MED: favicon.ico").get("/favicon.ico").headers(Headers105Test2.headers_0))
val httpProtocol = http
.baseURL("https://myurl.com")
.inferHtmlResources()
val openLoginSenario = scenario("OpenOnly").exec(repeat(400, "n") {
exec(openLoginSet).pause(3,6)
})
setUp(openLoginSenario.inject(rampUsers(150) over (3 minutes)))
.protocols(httpProtocol)
.maxDuration(3 minutes)
(我将测试缩短为运行3分钟只是为了捕获这里显示的数据)有3台计算机运行此gatling测试,每个计算机最多150个并发线程,总共450个线程.
我看到内核中运行的代码很多,而W3wp进程并没有占用大部分CPU:
测试刚刚启动时捕获的CPU(添加新线程时cpu正在上升):
当测试几乎在结束之前捕获CPU:
内核模式看起来很糟糕,我不确定是什么原因造成的.应该几乎没有涉及锁.当阅读其他可能导致高内核模式的内容时,我发现DPC可能会导致它.所以我也捕获了一些DPC数据,但我不确定什么是正常的,什么不是.无论如何,具有DPC最大时间的图表也包括在sshot中.
vmbus.sys从所有DPC中获取最重要的时间.这意味着Azure实例不是任何裸机(并不令人惊讶),并且该实例与其他实例共享它的计算能力.据我了解,vmbus.sys负责网卡本身与托管的HyperV实例之间的通信.可能在HyperV中运行是低性能的主要原因？
我想知道在哪里查看,以及如何在我的情况下找出导致内核模式的原因.
更多数据:
测试开始时的部分DPC数据(在30秒内拍摄):
Total = 17887 for module vmbus.sys
Elapsed Time, > 0 usecs AND <= 1 usecs, 137, or 0.77%
Elapsed Time, > 1 usecs AND <= 2 usecs, 2148, or 12.01%
Elapsed Time, > 2 usecs AND <= 4 usecs, 3941, or 22.03%
Elapsed Time, > 4 usecs AND <= 8 usecs, 2291, or 12.81%
Elapsed Time, > 8 usecs AND <= 16 usecs, 5182, or 28.97%
Elapsed Time, > 16 usecs AND <= 32 usecs, 3305, or 18.48%
Elapsed Time, > 32 usecs AND <= 64 usecs, 786, or 4.39%
Elapsed Time, > 64 usecs AND <= 128 usecs, 85, or 0.48%
Elapsed Time, > 128 usecs AND <= 256 usecs, 6, or 0.03%
Elapsed Time, > 256 usecs AND <= 512 usecs, 1, or 0.01%
Elapsed Time, > 512 usecs AND <= 1024 usecs, 2, or 0.01%
Elapsed Time, > 1024 usecs AND <= 2048 usecs, 0, or 0.00%
Elapsed Time, > 2048 usecs AND <= 4096 usecs, 1, or 0.01%
Elapsed Time, > 4096 usecs AND <= 8192 usecs, 2, or 0.01%
Total, 17887
测试结束时的部分DPC数据(在30秒内拍摄):
Total = 141796 for module vmbus.sys
Elapsed Time, > 0 usecs AND <= 1 usecs, 7703, or 5.43%
Elapsed Time, > 1 usecs AND <= 2 usecs, 21075, or 14.86%
Elapsed Time, > 2 usecs AND <= 4 usecs, 17301, or 12.20%
Elapsed Time, > 4 usecs AND <= 8 usecs, 38988, or 27.50%
Elapsed Time, > 8 usecs AND <= 16 usecs, 32028, or 22.59%
Elapsed Time, > 16 usecs AND <= 32 usecs, 11861, or 8.36%
Elapsed Time, > 32 usecs AND <= 64 usecs, 7034, or 4.96%
Elapsed Time, > 64 usecs AND <= 128 usecs, 5038, or 3.55%
Elapsed Time, > 128 usecs AND <= 256 usecs, 606, or 0.43%
Elapsed Time, > 256 usecs AND <= 512 usecs, 53, or 0.04%
Elapsed Time, > 512 usecs AND <= 1024 usecs, 26, or 0.02%
Elapsed Time, > 1024 usecs AND <= 2048 usecs, 11, or 0.01%
Elapsed Time, > 2048 usecs AND <= 4096 usecs, 10, or 0.01%
Elapsed Time, > 4096 usecs AND <= 8192 usecs, 53, or 0.04%
Elapsed Time, > 8192 usecs AND <= 16384 usecs, 3, or 0.00%
Elapsed Time, > 16384 usecs AND <= 32768 usecs, 1, or 0.00%
Elapsed Time, > 32768 usecs AND <= 65536 usecs, 5, or 0.00%
Total, 141796
%DPC从测试开始到结束的时间
我们还怀疑我们达到了网络限制 - 因此测试"下载"了如此多的数据,以达到网络适配器的限制.在测试结束时(当有最大线程数时),这可能是真的,但这并不能解释为什么即使在测试开始时内核模式时间也很多.
只是为了显示发送了多少数据 - 发送数据量(青色线)比网络适配器的容量低2个数量级.
自 IIS 6 起，许多请求都是在内核模式下处理的，这通常比用户模式更快。
在您的情况下，静态内容很可能由内核模式缓存处理，因此这些请求不涉及用户模式代码。在大多数情况下，由于更好的性能等，这是可取的。
有关配置/监视 IIS 输出缓存以验证其在测试中的使用的更多信息
祝你好运！
| 归档时间： |
|
| 查看次数： |
397 次 |
| 最近记录： |