前言碎语
昨日与一故人闲谈, 提到Node.js, 由于此君本是位资深.net码农, 对node的高并发性能却甚是崇拜, 被我泼了冷水后, 遂展开了一番舌战. 嘴遁无益, 今天就来实际验证一下.
由于之前也看到过几篇对比的文章, 结果貌似是dotnet core一边倒, 看到博客园中的一篇. 写的非常好, 而且对比全面. 再做同样的对比意义不大. 这里我决定换个方式.
测试准备
性能测试无非两个方向, 一个是吞吐量的测试, 一个是响应时间.
既然已经有前辈测试过吞吐量的能力对比, 这里我想测试一下响应时间的对比. 另外, 我参考TechEmpower, 会使用JSON和Plain Text两种请求对Web Server进行测试. 交代一下硬件配置, 我本机是一个i5的笔记本, 8G内存, Win10操作系统. 在物理机之上, 创建了一个2个虚拟核心, 2G内存的CentOS 64位虚拟机.
另外, 为了减小外界因素对性能的影响, 两种语言都没有用到任何框架, 没有任何的数据库操作, 都是简单的HTTP 请求并返回, 对于Plain Text直接返回, 对于JSON, 进行解析后返回其中的一个字段. 各位看官, 我尽量保证测试的客观公正, 如果你觉得有任何不公的地方, 期待您的指教, 提前说声谢谢.
Ready, Go!
搭建测试环境也花了我大半天的时间, 简单交代一下.
- 新建一个CentOS虚拟机
- 在虚拟机中安装Node.js
- 在虚拟机中安装dotnet core
- 用firewalld开放6600端口
- 编写Node代码
- 编写dotnet core代码
- 配置测试工具Jmeter
一切就绪, 我们开始.
第一项, 500并发数的对比
说实话, 测试结果出来川酷吃了一惊, 本来觉得两个语言应该不相上下, 结果却...
看官们自己看吧.
首先声明一下, 本来对于Linux半生不熟的我, 没有对这台服务器做任何优化, 另外我把代码贴在这, 如果有处理不妥的地方也请看官大大们纠正
Node.js
var http = require("http");
http.createServer(function(request, response) {
response.writeHead(200, {"Content-Type": "text/plain"});
request.setEncoding("utf8");
request.on("data", function(data) {
response.write(data);
response.end();
});
}).listen(6600);
dotnet core
app.Run(async context =>
{
Stream m = context.Request.Body;
StreamReader reader = new StreamReader(m);
string s=await reader.ReadToEndAsync();
await context.Response.WriteAsync(s);
});
先不要着急, 看看对于JSON的解析情况会不会有反转.
总体感觉JSON的解析对性能没什么影响, 看到这个结果的时候川酷开始怀疑这个测试的合理性. 无论如何, 先把代码贴出来.
Node.js
var http = require("http");
http.createServer(function(request, response) {
response.writeHead(200, {"Content-Type": "text/plain"});
request.setEncoding("utf8");
request.on("data", function(data) {
var d = JSON.parse(data)
response.write(d.message);
response.end();
});
}).listen(6600);
dotnet core
app.Run(async context =>
{
Stream m = context.Request.Body;
StreamReader reader = new StreamReader(m);
string s=await reader.ReadToEndAsync();
Message o =JsonConvert.DeserializeObject(s);
await context.Response.WriteAsync(o.message);
});
为了证明清白, 再贴一下测试时的具体结果.
第二项, 2000并发数的对比
直接上结果
这个结果看来差距并不大, dotnet core 略占优势.
事实如此?
经常看到大神们并发几万, 几十万, 我这里才并发2000就已经到了用户体验的临界值. 我不甘心, 实在不甘心, 接着做了5000并发. 然后就是大量的请求超时, Jmeter默认的超时时间貌似是10s, 我没有调整, 感觉调的多了对于实际场景中意义不大. 后来我又尝试在一个2核4线程8G的物理机上测试了一下, 性能有很大提升,
看来是我的硬件不够好.
有兴趣的, 或者对结果持怀疑态度的朋友, 欢迎讨论.