準備階段

首先是在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的性能，就必須要考慮到開放文件數量這一問題。                                                                                                                        

原文來自：