|
.NET VS Node.JS 到底誰快
訊光科技 / 蔡宏旻
前言
訊光在發展Node.JS之前就從網路的各種測試報告與文章中得知，Node.JS在單純作為網站服務的性能上會比.NET下的IIS效能還好，而且用戶的量越大，效果也越明顯。基於Node.JS的事件驅動與非阻塞式的I/O架構來思考，是可以理解為何會較快的原因，但是，若以EEP平台來思考，並非專門用來處理網站的功能，而需要再配合Application處理後端商業邏輯及資料庫的數據存取，這樣，Node.JS就會比較快嗎？如果快，會快多少呢？這些都令人充滿問號...
隨著EEP Node.JS平台開發完成，就可以實際的案例來做個效能比較，就是以同一個應用案例(前端一模一樣)，來分別測試EEP .NET與EEP Node.JS，並記錄測試的成果加以比較，供大家參考。
測試環境說明
●Server端主機規格：CPU 3.2GHz雙核，記憶體4GB，HD 500G 5400轉，作業系統Windows 7，.NET版本 4.0，IIS版本6.1。使用兩台主機，一台主機安裝好EEP2012 Application Server及Microsoft IIS，使用HeavyLoad的測試軟體做CPU及記憶體的消耗記錄；Database 則使用MS-SQL 2012，安裝在另一台上面，避免干擾測試結果。 此Server同時安裝了IIS + EEP Application Server 及 Node.JS + EEP Node.JS，並分開測試。
●Client端測試機規格：CPU 2.5GHz雙核，記憶體3GB，作業系統Windows 7，Browser為IE10。Client 端使用10台主機，使用LoadRunner壓力測試軟體，每台分別模擬25個 User，總共同時模擬250個USER同時作業。
●測試示意圖
測試方法及準備
● 測試主機Server每次測試前重新啟動，避免累積測試干擾。
●Client端壓力測試，啟動100個Users同一時間進行新增資料的壓力測試，同時啟動150個Users同一時間進行資料查詢測試。.NET與Node.JS的前端都是用EEP的JQuery模組所開發，開發的頁面內容完全一樣來達到測試準確性。
●新增資料測試方案，模擬單一表單資料新增，從Login登入到主畫面，進入新增作業，連續新增3筆資料後登出應用程式。(100個Users同時進行)。
●查詢資料測試方案，模擬單一表單資料查詢，資料量為10000筆資料，隨機查詢1筆資料結果。從Login登入到主畫面，進入查詢作業，隨機查詢3次資料後登出應用程式。
●測試取得主機 Server的CPU與記憶體平均負載狀況，Client端的平均回應時間及逾時錯誤數目。
.NET測試結果
首先針對EEP .NET進行測試，結果如下：
●10台Client測試機模擬登錄操作，每台主機模擬25個User，測試三次。
| Client端測試機 |
第一次測試結果 |
第二次測試結果 |
第三次測試結果 |
總體
反應時間 |
平均
反應時間 |
錯誤
數目 |
總體
反應時間 |
平均
反應時間 |
錯誤
數目 |
總體
反應時間 |
平均
反應時間 |
錯誤
數目 |
| A |
60 |
6 |
0 |
59 |
5.9 |
0 |
61 |
6.1 |
0 |
| B |
60 |
6.1 |
0 |
60 |
6 |
0 |
62 |
6.2 |
0 |
| C |
61 |
6.1 |
0 |
60 |
6 |
0 |
62 |
6.2 |
0 |
| D |
60 |
6 |
0 |
59 |
5.9 |
0 |
60 |
6.0 |
0 |
| E |
58 |
5.8 |
0 |
56 |
5.6 |
0 |
58 |
5.8 |
0 |
| F |
59 |
5.9 |
0 |
58 |
5.8 |
0 |
60 |
6.0 |
0 |
| G |
59 |
5.9 |
0 |
56 |
5.6 |
0 |
59 |
5.9 |
0 |
| H |
60 |
6.0 |
0 |
54 |
5.4 |
0 |
61 |
6.1 |
0 |
| I |
59 |
5.9 |
0 |
57 |
5.7 |
0 |
60 |
6.0 |
0 |
| J |
58 |
5.8 |
0 |
56 |
5.6 |
0 |
59 |
5.9 |
0 |
| 平均 |
59.4 |
59.4 |
0 |
57.4 |
5.74 |
0 |
60.0 |
6.0 |
0 |
Client端總平均回應時間為 5.89秒。
主機端的CPU與記憶體消耗：(EEP .NET A/P Server + IIS)。
| 次數 |
測試前
CPU平均% |
測試中
CPU最高 |
測試中
CPU平均 |
測試前
可用記憶體 |
測試後
可用記憶體 |
消耗記憶體 |
| 1 |
10% |
85% |
51% |
1468MB |
1326MB |
142MB |
| 2 |
10% |
75% |
48% |
1451MB |
1286MB |
165MB |
| 3 |
10% |
88% |
53% |
1472MB |
1301MB |
171MB |
| 平均 |
|
82% |
50.6% |
|
|
159.3MB |
Server端第一次結果(Update Chart every 3 seconds)。
Server端第二次結果(Update Chart every 3 seconds)。
(第三次結果略)。
Node.JS測試結果
接著針對EEP Node.JS測試結果如下：
●10台Client測試機模擬登錄操作，每台主機模擬25個User，測試三次。
| Client端測試機 |
第一次測試結果 |
第二次測試結果 |
第三次測試結果 |
總體
反應時間 |
平均
反應時間 |
錯誤
數目 |
總體
反應時間 |
平均
反應時間 |
錯誤
數目 |
總體
反應時間 |
平均
反應時間 |
錯誤數目 |
| A |
43 |
4.3 |
0 |
43 |
4.3 |
0 |
44 |
4.4 |
0 |
| B |
43 |
4.3 |
0 |
43 |
4.3 |
0 |
43 |
4.3 |
0 |
| C |
43 |
4.3 |
0 |
43 |
4.3 |
0 |
43 |
4.3 |
0 |
| D |
43 |
4.3 |
0 |
43 |
4.3 |
0 |
45 |
4.5 |
0 |
| E |
43 |
4.3 |
0 |
43 |
4.3 |
0 |
43 |
4.3 |
0 |
| F |
43 |
4.3 |
0 |
43 |
4.3 |
0 |
43 |
4.3 |
0 |
| G |
41 |
4.1 |
0 |
38 |
3.8 |
0 |
39 |
3.9 |
0 |
| H |
33 |
3.3 |
0 |
37 |
3.7 |
0 |
38 |
3.8 |
0 |
| I |
41 |
4.1 |
0 |
38 |
3.8 |
0 |
40 |
4.0 |
0 |
| J |
40 |
4 |
0 |
37 |
3.7 |
0 |
41 |
4.1 |
0 |
| 平均 |
41.3 |
4.13 |
0 |
40.8 |
4.08 |
0 |
41.9 |
4.19 |
0 |
Client端總平均回應時間為 4.13秒。
主機端的CPU與記憶體消耗：(EEP Node.JS Server)。
| 次數 |
測試前
CPU平均% |
測試中
CPU最高 |
測試中
CPU平均 |
測試前
可用記憶體 |
測試後
可用記憶體 |
消耗記憶體 |
| 1 |
10% |
95% |
67.14% |
1164MB |
1109MB |
55MB |
| 2 |
10% |
100% |
75% |
1306MB |
1223MB |
83MB |
| 3 |
10% |
95% |
69.5% |
1185MB |
1125MB |
60MB |
| 平均 |
|
96.6% |
70.5% |
|
|
66MB |
Server端第一次結果(Update Chart every 3 seconds)。
Server端第二次結果(Update Chart every 3 seconds)。
(第三次結果略)。
測試結果比較
| |
Client端反應時間 |
Server端CPU平均 |
消耗記憶體 |
| EEP.NET |
5.89秒 |
50.6% |
159.3MB |
| EEP Node.JS |
4.13秒 |
70.5% |
66MB |
| 結果 |
快了29% |
高了39% |
降了58.5% |
結論
從上表以.NET JQuery及Node.JS JQuery相同介面去分別測試了EEP.NET及EEP Node.JS的Server後所得的數據，得知EEP Node.JS比EEP .NET+IIS的表現還好一點，但並不是想像中有倍數的效能，其實.NET與IIS在CPU的表現反而比Node.JS來得好，這是當初意想不到的結果，當然主要是因為EEP是跟資料庫系統較為緊密的系統，非單純只是個網站系統，也許測試的數據也會大不同。另外針對耗用記憶體方面就與事先預測差不多，畢竟Node.JS是個輕量化的運行環境，會比IIS龐大的架構節省很多記憶體。
目前EEP Node.JS已經內建了多執行序(Multi-Thread)的機制在內，目的就是要來面臨高併發數與多工的處理，畢竟在商業領域當中，多工是必備的條件，暫時我們研發團隊還沒有針對EEP Node.JS的核心特別去優化，年底之前我們會全面優化一次，也許測試出來的數據會更為亮麗，值得大家去期待一下。
| 
