本文作者Marc Fasel是一名高級顧問、架構師、
軟件開發者。他有著18年的構建大規模、高性能企業App的經驗。在這篇
文章里，他通過做
測試的方式（在Node.js App上和Java伺服器App上分別進行
性能測試），一步步將測試過程、結果、結論寫出來，分析兩者的性能區別。（以下是編譯內容）
本文是通過從CouchDB上讀取JSON數據來比較Node.js和Java EE之間的性能的。究竟誰的性能更好些？為了回答這一問題，只有在一系列的性能測試下運行Node.js App和Java EE App，才能得出最終結果來。
準備階段
首先是在Node.js App上和Java伺服器App上分別進行了性能測試。每個App上都是用了相同的后端作為初始Node.js App：CouchDB。除此還使用了CouchBase Single Server版本1.1.3。創造出一萬份大小4KB的隨機文本樣本文件。測試機器是配備2.4 GHZ、Intel Core 2 Duo、4 GB RAM和Mac OS X的iMac。另外，在一個獨立的機器上使用Apache JMeter作為測試驅動器。
Java EE
Java伺服器是運行在一個版本為7.0.21的Apache Tomcat上的，默認配置運行在Java 1.6上。
數據庫驅動程序是版本0.30的CouchDB4J，驅動程序沒有緩存選項，所以，沒有完成任何配置。
接下來的這個Java代碼是一個伺服器的代碼，可以通過CouchDB獲取文檔，將數據作為一個JSON對象來處理。
通過使用JMeter測試驅動器來測試伺服器在不同的并發性基礎之上，下面的表格數字就展現出不同的并發需求——平均的響應時間，和每秒相應的所對應的回復。
從表格里就可以看出，當并行需求在增加的時候，響應時間就會有所變化。每10個并行需求的響應時間平均起來是23毫秒，100個并行需求的響應時間平均起來就是243毫秒。
比較有趣的部分是，響應時間的平均數和并行需求的數量有著線性相關關系，所以，并行需求增長十倍就會導致每個需求的響應時間增長十倍。這使得在每秒鐘處理需求數量是相當恒定的，不管有10個并發請求或150個并發請求，都無所謂。在所有觀察到的并發服務請求數量大約為每秒420。
Node.js
Node.js App 使用Cradle CouchDB驅動程序0.57版本，運行在Node.js 0.10.20，為了給驅動程序創造相等的條件，運行時的緩存必須要關閉的。
接下來的數據顯示Node.js程序通過一個給定的ID從CouchDB里傳遞同樣的JSON文檔：
Node.js系統數目如下：
正如前面所說的一樣，平均的響應時間和并行需求數量呈線性相關關系，每秒鐘處理需求數量是相當恒定的。Node.js相對較快20%，例如，在10個并行需求里，509個需求/秒VS.422需求/每秒。
結論
Node.js解決問題的速度比Java EE快20%，這的確有點出乎意料——一種解釋語言和一種編譯語言在一個VM中的速度是一樣快的，這沒有多年的優化過程是絕對達不到的。
其實，Node.js和Java EE規模超出正常的服務器需求。每秒400-500的請求數量可以說是相當不錯。谷歌是世界上最大的網站，每天有大約50億個請求，如果換算成秒的話，也就是57870個請求/秒。這也是谷歌域名在世界范圍內的需求數量，所以如果你有一個運行在一臺機器上的、400需求/秒的網站的話，那你的這個網站可以說是相當的大了。平均每天100萬個需求也就意味著11.5需求/秒。這是一個很重要的數字。
在這個性能測試里，在單線程的Node.js和多線程的Java EE之間的采用不同的并發模型對最后的結果是沒有影響的。如果想要在更高并發水平里測試Node.js的性能，就必須要考慮到開放文件數量這一問題。