準(zhǔn)備階段

首先是在Node.js App上和Java伺服器App上分別進(jìn)行了性能測試。每個App上都是用了相同的后端作為初始Node.js App：CouchDB。除此還使用了CouchBase Single Server版本1.1.3。創(chuàng)造出一萬份大小4KB的隨機(jī)文本樣本文件。測試機(jī)器是配備2.4 GHZ、Intel Core 2 Duo、4 GB RAM和Mac OS X的iMac。另外，在一個獨(dú)立的機(jī)器上使用Apache JMeter作為測試驅(qū)動器。

Java EE

Java伺服器是運(yùn)行在一個版本為7.0.21的Apache Tomcat上的，默認(rèn)配置運(yùn)行在Java 1.6上。數(shù)據(jù)庫驅(qū)動程序是版本0.30的CouchDB4J，驅(qū)動程序沒有緩存選項，所以，沒有完成任何配置。

接下來的這個Java代碼是一個伺服器的代碼，可以通過CouchDB獲取文檔，將數(shù)據(jù)作為一個JSON對象來處理。

通過使用JMeter測試驅(qū)動器來測試伺服器在不同的并發(fā)性基礎(chǔ)之上，下面的表格數(shù)字就展現(xiàn)出不同的并發(fā)需求——平均的響應(yīng)時間，和每秒相應(yīng)的所對應(yīng)的回復(fù)。

從表格里就可以看出，當(dāng)并行需求在增加的時候，響應(yīng)時間就會有所變化。每10個并行需求的響應(yīng)時間平均起來是23毫秒，100個并行需求的響應(yīng)時間平均起來就是243毫秒。

比較有趣的部分是，響應(yīng)時間的平均數(shù)和并行需求的數(shù)量有著線性相關(guān)關(guān)系，所以，并行需求增長十倍就會導(dǎo)致每個需求的響應(yīng)時間增長十倍。這使得在每秒鐘處理需求數(shù)量是相當(dāng)恒定的，不管有10個并發(fā)請求或150個并發(fā)請求，都無所謂。在所有觀察到的并發(fā)服務(wù)請求數(shù)量大約為每秒420。

Node.js

Node.js App 使用Cradle CouchDB驅(qū)動程序0.57版本，運(yùn)行在Node.js 0.10.20，為了給驅(qū)動程序創(chuàng)造相等的條件，運(yùn)行時的緩存必須要關(guān)閉的。

接下來的數(shù)據(jù)顯示Node.js程序通過一個給定的ID從CouchDB里傳遞同樣的JSON文檔：

Node.js系統(tǒng)數(shù)目如下：

正如前面所說的一樣，平均的響應(yīng)時間和并行需求數(shù)量呈線性相關(guān)關(guān)系，每秒鐘處理需求數(shù)量是相當(dāng)恒定的。Node.js相對較快20%，例如，在10個并行需求里，509個需求/秒VS.422需求/每秒。

結(jié)論

Node.js解決問題的速度比Java EE快20%，這的確有點(diǎn)出乎意料——一種解釋語言和一種編譯語言在一個VM中的速度是一樣快的，這沒有多年的優(yōu)化過程是絕對達(dá)不到的。

其實(shí)，Node.js和Java EE規(guī)模超出正常的服務(wù)器需求。每秒400-500的請求數(shù)量可以說是相當(dāng)不錯。谷歌是世界上最大的網(wǎng)站，每天有大約50億個請求，如果換算成秒的話，也就是57870個請求/秒。這也是谷歌域名在世界范圍內(nèi)的需求數(shù)量，所以如果你有一個運(yùn)行在一臺機(jī)器上的、400需求/秒的網(wǎng)站的話，那你的這個網(wǎng)站可以說是相當(dāng)?shù)拇罅恕Ｆ骄刻?00萬個需求也就意味著11.5需求/秒。這是一個很重要的數(shù)字。

在這個性能測試?yán)铮趩尉€程的Node.js和多線程的Java EE之間的采用不同的并發(fā)模型對最后的結(jié)果是沒有影響的。如果想要在更高并發(fā)水平里測試Node.js的性能，就必須要考慮到開放文件數(shù)量這一問題。                                                                                                                        

原文來自：