準(zhǔn)備階段

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

Java EE

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

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

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

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

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

Node.js

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

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

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

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

結(jié)論

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

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

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

原文來自：