前言碎語
昨日與一故人閑談, 提到Node.js, 由于此君本是位資深.net碼農(nóng), 對node的高并發(fā)性能卻甚是崇拜, 被我潑了冷水后, 遂展開了一番舌戰(zhàn). 嘴遁無益, 今天就來實際驗證一下.
由于之前也看到過幾篇對比的文章, 結果貌似是dotnet core一邊倒, 看到博客園中的一篇. 寫的非常好, 而且對比全面. 再做同樣的對比意義不大. 這里我決定換個方式.
測試準備
性能測試無非兩個方向, 一個是吞吐量的測試, 一個是響應時間.
既然已經(jīng)有前輩測試過吞吐量的能力對比, 這里我想測試一下響應時間的對比. 另外, 我參考TechEmpower, 會使用JSON和Plain Text兩種請求對Web Server進行測試. 交代一下硬件配置, 我本機是一個i5的筆記本, 8G內(nèi)存, Win10操作系統(tǒng). 在物理機之上, 創(chuàng)建了一個2個虛擬核心, 2G內(nèi)存的CentOS 64位虛擬機.
另外, 為了減小外界因素對性能的影響, 兩種語言都沒有用到任何框架, 沒有任何的數(shù)據(jù)庫操作, 都是簡單的HTTP 請求并返回, 對于Plain Text直接返回, 對于JSON, 進行解析后返回其中的一個字段. 各位看官, 我盡量保證測試的客觀公正, 如果你覺得有任何不公的地方, 期待您的指教, 提前說聲謝謝.
Ready, Go!
搭建測試環(huán)境也花了我大半天的時間, 簡單交代一下.
- 新建一個CentOS虛擬機
- 在虛擬機中安裝Node.js
- 在虛擬機中安裝dotnet core
- 用firewalld開放6600端口
- 編寫Node代碼
- 編寫dotnet core代碼
- 配置測試工具Jmeter
一切就緒, 我們開始.
第一項, 500并發(fā)數(shù)的對比
說實話, 測試結果出來川酷吃了一驚, 本來覺得兩個語言應該不相上下, 結果卻...
看官們自己看吧.
首先聲明一下, 本來對于Linux半生不熟的我, 沒有對這臺服務器做任何優(yōu)化, 另外我把代碼貼在這, 如果有處理不妥的地方也請看官大大們糾正
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<Message>(s);
await context.Response.WriteAsync(o.message);
});
為了證明清白, 再貼一下測試時的具體結果.
第二項, 2000并發(fā)數(shù)的對比
直接上結果
這個結果看來差距并不大, dotnet core 略占優(yōu)勢.
事實如此?
經(jīng)?？吹酱笊駛儾l(fā)幾萬, 幾十萬, 我這里才并發(fā)2000就已經(jīng)到了用戶體驗的臨界值. 我不甘心, 實在不甘心, 接著做了5000并發(fā). 然后就是大量的請求超時, Jmeter默認的超時時間貌似是10s, 我沒有調(diào)整, 感覺調(diào)的多了對于實際場景中意義不大. 后來我又嘗試在一個2核4線程8G的物理機上測試了一下, 性能有很大提升,
看來是我的硬件不夠好.
有興趣的, 或者對結果持懷疑態(tài)度的朋友, 歡迎討論.
