为什么Linux+MONO性能这么差

.Net技术 码拜 8年前 (2016-07-12) 2106次浏览
花了两天时间折腾了一下MONO性能测试结果让人诅丧。
测试机是4核(i5-4570),测试项目是一个WEB服务网络通讯综合性能测试,先贴测试结果。
为什么Linux+MONO性能这么差
这是win7物理机的测试结果,可以看到TPS稳定在22K/s以上。
为什么Linux+MONO性能这么差
这是win7物理机下的MONO测试结果,很不错和.NET差不多;测到这里还高兴了一下:MONO性能没有别人说的那么差啊。
可是接下来在Unbuntu上的测试
为什么Linux+MONO性能这么差
这是4核win2008虚拟机的测试结果,相对于物理机有20%的性能损耗,这个倒是正常的。
为什么Linux+MONO性能这么差
这是4核Unbuntu虚拟机的测试结果,TPS竟然只剩下30%,有人能告诉本人为什么吗?
为什么Linux+MONO性能这么差
这是2核win2008虚拟机的测试结果,看起来没有什么太大的意外。
为什么Linux+MONO性能这么差
这是2核Unbuntu虚拟机的测试结果,竟然和4核的测试结果接近,有人能告诉本人为什么吗?
原因是没有在Unbuntu物理机上测试,所以CPU虚拟机可能是一个问题。另外莫非和IOCP有关?
测试中启动5个进程,1个客户端进程,1个HTTP服务进程,3个TCP负载均衡节点进程。
测试内容为计算两个整数的和或异或值,并在客户端验证计算结果。
测试流程为客户端进程启动 CPU数量*256 个HTTP客户端(由于4核MONO在测试环境中启动1024客户端会造成拒绝连接问题,所以只启动3*256个客户端),采用异步IO短连接模式对HTTP服务发起请求,随机访问HTTP服务端的8个调用接口,HTTP服务端把请求转发到3个TCP计算节点并在获取计算返回值以后返回给HTTP客户端。
HTTP服务器端支持 AJAX、WebView、WebCall、搜索引擎View 共4种访问模式,每种访问模式都同时支持同步与异步两种访问模式,所以有8个调用接口。
最后祭出测试项目fastCSharp中的demo.loadBalancingTcpCommandWeb,希望有高手能够指点一二。
解决方案

10

反正本人只是在 ubuntu 上玩一玩 并不关心他的效率问题

10

效率当然差了,本来可以直行,非要绕三圈

5

直接.net core吧。一秒90万请求。

5

引用:
Quote: 引用:

直接.net core吧。一秒90万请求。

你是单纯的TCP单个长连接测试吧,原生windows+.NET也远远达不到这个量。

哈,.net core 在windows 平台上一秒110万请求。

10

引用:
Quote: 引用:
Quote: 引用:
Quote: 引用:

直接.net core吧。一秒90万请求。

你是单纯的TCP单个长连接测试吧,原生windows+.NET也远远达不到这个量。

哈,.net core 在windows 平台上一秒110万请求。

跪求简单测试项目,这个量级根据本人个人的经验使用原生.NET仅仅Accept都困难。

https://github.com/aspnet/benchmarks

50

你先把测试平台统一再说,一个物理机,一个虚拟机,本人也不知道你的测试结果有什么参考的价值。

5

你非得用筷子喝粥那本人也没办法

5

引用:
Quote: 引用:
Quote: 引用:
Quote: 引用:
Quote: 引用:
Quote: 引用:

直接.net core吧。一秒90万请求。

你是单纯的TCP单个长连接测试吧,原生windows+.NET也远远达不到这个量。

哈,.net core 在windows 平台上一秒110万请求。

跪求简单测试项目,这个量级根据本人个人的经验使用原生.NET仅仅Accept都困难。

https://github.com/aspnet/benchmarks

看了一下,测试机是6核12线程服务器,测试的基本就是TCP长连接的纯收发操作,所谓的ASP.NET Core也都是套个HTTP壳的TCP长连接批量处理。
唯一有看头的就是RIO了。

什么是RIO?你想要什么样的性能呢?
同样的服务器,同样的code, asp.net core比linux平台上的任何其他web技术都要高。你还想怎么呢?

5

引用:
Quote: 引用:

什么是RIO?你想要什么样的性能呢?
同样的服务器,同样的code, asp.net core比linux平台上的任何其他web技术都要高。你还想怎么呢?

个人认为这种纯粹为了跑测试数据的固定的TCP长连接发送基本没有实用意义。16核的服务器不是为了32个客户端不断的输出同样的内容;抛开内容固定来说,这种需求直接上TCP不是更好?

你可以把你认为有用的测试代码用.net core在linux跑跑试试。
本人认为,同样的内容和不同的内容对于性能测试没有任何影响。这个只是针对框架怎么样构造request,怎么样构造response的性能测试。这种测试基于一种假设:就是从request生成response的时间为0. 原因是这个时间是你本人代码的运行时间,跟框架无关。
你觉得呢?

5

引用:
Quote: 引用:

你可以把你认为有用的测试代码用.net core在linux跑跑试试。
本人认为,同样的内容和不同的内容对于性能测试没有任何影响。这个只是针对框架怎么样构造request,怎么样构造response的性能测试。这种测试基于一种假设:就是从request生成response的时间为0. 原因是这个时间是你本人代码的运行时间,跟框架无关。
你觉得呢?

.NET core固然在性能方面表现很不错,但是也没必要带有神化的眼镜。
本人下面只说正常的网站应用:
1.长连接的平均复用次数大致不到8次,而且时间跨度大,对于单个客户端的队列处理是没有意义的,每秒N万次请求为什么不考虑TCP呢(莫非HTTP Header真的不需要解析)?
2.服务器端并不能使用1线程对1客户端的同步模式处理,这种模式只有在本地测试的低并发环境才有优势。
3.HTTP Header不仅仅是解析一个Uri,连Header正确性与数据包的完整性都不验证,甚至都不解析的测试能叫HTTP吗?
4.对于测试构造request没有任何问题,原因是它是客户端;但是手动构造固定的response那不是在测试TCP?
5.对于32个客户端,而且还是固定数据,这是在故意构造CPU高速缓存命中环境,以及故意回避线程并发问题。
你说的本人没有测试环境,fastCSharp的web服务端在128并发的长连接下使用2核也能稳定到26W+/s,不需要手动构造response,即使是完整的简单动态请求也能稳定在15W+/s。
最后还是要说一下,这样的测试结果基本等价于Socket的收发接口的调用次数测试,对于实际项目真的没有什么意义。

1. 为什么要扯到tcp?
2. 为什么要讨论同步模式处理? 这个测试asp.net不用同步模型。
3. http的header就是一堆key value,莫非这会造成性能瓶颈?
4. request怎么就在客户端了? 一个http请求过来,任何web 框架都需要构造一个request对象(包含了读取http header),并创建一个response对象。
5. 这个测试是公平的,又不是只有asp.net在高命中缓存的下。全部的web框架不都享有相同的测试环境吗?然而asp.net还是非常不错的。
6. 你那里看出本人神话asp.net了?本人只是引用:

Quote: 引用:

3. http的header就是一堆key value,莫非这会造成性能瓶颈?

在本人给出的测试数据中,简单的动态请求15W+/s相对于静态文件请求26W+/s,至少有40%的差距,而这个差距仅仅就是Header解析+动态Response。而且这两个过程是没有new任何对象的,假如要生成一堆string这个开销是不容忽视的。

本人还没有在任何关于性能的文章中看到header解析成为性能瓶颈的。
就算解析header会影响性能,任何web框架都有这个问题,也不可能解决这个问题。所以纠结header解析造成的性能影响根本是毫无意义的。

5

引用:
Quote: 引用:

什么是RIO?你想要什么样的性能呢?

本人认为RIO是这个项目中提到唯一有看头的东西,你竟然视而不见。

哈,你看得确实比本人仔细, 而本人只是领会精神而已。 看看这篇文章,使用asp.net core支撑高性能游戏服务器:
http://web.ageofascent.com/asp-net-core-exeeds-1-15-million-requests-12-6-gbps/
本人觉得你遇到的性能问题不至于用asp.net core解决不了吧?

5

引用:
Quote: 引用:

什么是RIO?你想要什么样的性能呢?

本人认为RIO是这个项目中提到唯一有看头的东西,你竟然视而不见。

asp.net core只提供了两个server,一个weblistener ,基于http.sys;一个kestrel,基于libuv。前者只能用于windows,后者可以跨平台。基本上你想用现成的,你应该没有什么别的选择。
当然了,你可以写封装本人的server。反正本人是不会, 就算是会,本人也不想去做。

50

比较性能应该在对等的环境中进行
虚拟机中可使用的资源明显要少的多,出现悲观的结果是很正常的

10

引用:
Quote: 引用:

本人还没有在任何关于性能的文章中看到header解析成为性能瓶颈的。
就算解析header会影响性能,任何web框架都有这个问题,也不可能解决这个问题。所以纠结header解析造成的性能影响根本是毫无意义的。

本人并不是说Header解析成为性能瓶颈,本人只是强调这样的测试数据没有现实意义。

引用:

哈,你看得确实比本人仔细, 而本人只是领会精神而已。 看看这篇文章,使用asp.net core支撑高性能游戏服务器:
http://web.ageofascent.com/asp-net-core-exeeds-1-15-million-requests-12-6-gbps/
本人觉得你遇到的性能问题不至于用asp.net core解决不了吧?

本人并没有说ASP.NET core性能差,本人只是觉得这种测试环境产生的测试数据仅仅是个噱头,不现实。
本人觉得任何web服务器在windows下使用IOCP+缓存池的模式(不在应用层new对象),精简定制化的长连接测试应该都可以达到这个量级(而且游戏更可能采用websocket除了握手都不存在Header解析一说)。

老的asp.net 就达不到这个要求。现在的论题是什么?
We are building Age Of Ascent – an ultra-MMO; a new scale of game. Born in the cloud, it enables tens of thousands of pilots to be in the same battle; and millions of players to be in the same single-sharded universe – which can be accessed anywhere at any time, on any device.
Our communication mechanism between these micro-services is entirely ASP.NET Core based on David Zhao’s excellent Service Fabric ASP.NET Core Hosting example.
This means our entire system’s responsiveness and performance hinges on the performance of ASP.NET Core. This is why it is important; and why we strive for performance. The more we can do; the richer an experience we can create for our players – at a lower cost.
.NET Core and ASP.NET Core are really shaping up to be the frameworks that we not only want, but also need.

5

引用:
Quote: 引用:

现在的论题是什么?

本人现在可不想花时间在HTTP在长连接处理大批量请求的问题上,原因是本人的TCP服务能更好的解决这个问题,而不是HTTP。

按你本人的测试用例测试一下asp.net core不就可以了?
Mono + ASP.net 跟 .NetFramework + ASP.net。差别很大,根本就是两拨人开发的。
ASP.net core就不一样了。 .net core 跟asp.net core是一拨人开发的。
所以还是别纠结MONO + asp。net的方案了。

50

虚拟机肯定是有损失。mono性能也是个问题。

CodeBye 版权所有丨如未注明 , 均为原创丨本网站采用BY-NC-SA协议进行授权 , 转载请注明为什么Linux+MONO性能这么差
喜欢 (0)
[1034331897@qq.com]
分享 (0)