脫離帶寬內(nèi)存與計算量來討論并發(fā)是沒有意義的。

因為并發(fā)數(shù)受帶寬及其它很多因素影響，不能單就node.js來說并發(fā)多高。

如果無限帶寬，無限計算力，無限存……你可以認(rèn)為node.js并發(fā)數(shù)也是無限的，但這沒有意義，在同樣的情況下，就算是IIS，并發(fā)數(shù)也可以認(rèn)為是無限的。

node.js的優(yōu)勢嚴(yán)格來說不是并發(fā)而是“非阻塞”。

它是通過非阻塞來達到高并發(fā)的目標(biāo)的，我們用node.js也是用它的非阻塞這個特點。

在優(yōu)化線程池，以及端口復(fù)用等技術(shù)的基礎(chǔ)上，對于簡單的業(yè)務(wù)處，使用其它的模型也可以達到高并發(fā)的目標(biāo)，但在面臨業(yè)務(wù)邏輯耗時長的問題時，node.js的優(yōu)勢就比較明顯。

如果一個事務(wù)請求涉及三個業(yè)務(wù)邏輯，比如登錄(login)這個事務(wù)，假設(shè)我們定義它有三個業(yè)務(wù)邏輯：

1. verify：驗證用戶是否合法（用戶名，密碼什么的）；

2. user:獲取身份信息（權(quán)限什么的）；

3. modules:返回他可用的業(yè)務(wù)接口列表(商品管理，用戶管理，訂單審核等）

我們假設(shè)：只有1完成了才可以進行2，2完成了才可以進行3，上述每個業(yè)務(wù)邏輯都需要1秒去完成（客戶的登錄請求這個事務(wù)需要3秒才能完成）。

同時，我們也假設(shè)，這三個業(yè)務(wù)邏輯服務(wù)都是在其它的服務(wù)器上，它們的并發(fā)數(shù)無上限。

然后，我們在“一瞬間”我向這個服務(wù)發(fā)出1000個login請求

那么，我們來看看node.js與純java的不同。

nodejs調(diào)用它們來完成,因為它是非阻塞的，它調(diào)了verify后，不再等待它返回結(jié)果，就可以處理另一個事務(wù)請求了，當(dāng)verify請求有返回結(jié)果時，它再來處理結(jié)果，決定是否調(diào)用user……，整個過程，只在一個進程中就完成了。

它收到這1000個請求后，在這個進程中向verify發(fā)出了1000個請求，過了一秒，收到回應(yīng)又有900個驗證成功，它返回了100個登錄失敗的信息，并向user發(fā)出了900個請求，又過了一秒，返回了900個modules的結(jié)果。

這樣的結(jié)果，在客戶端看來，發(fā)出請求后1秒，收到了100個登錄失敗，又過了兩秒，收到了900個可用功能列表（因為異步機制，它還會稍微長一點點，假設(shè)是3.003秒吧）

現(xiàn)在，在帶寬與計算力不受限的情況下，同樣的內(nèi)存，看看純Java是怎么個情況。如果使用純java來做這個事，java不使用異步模式的話，一個線程響應(yīng)一個請求。

java同樣“一瞬間”收到了1000個請求，java開啟了1000個線程去響應(yīng)它們,然后這1000個線程在第一秒里都在等待verify，第一秒結(jié)束時，返回100個登錄失敗，關(guān)閉了100個線程，又過了兩秒，900個線程得到了各自的modules結(jié)果，并返回給客戶端。

對于客戶端來說，感覺就是3秒，沒有那個0.003。

好，至此，node.js與純java的區(qū)別已經(jīng)很明顯了。純java在不使用非阻塞機制的情況下，它需要開啟1000個線程（或者進程，這個成本更高）而node.js則需要更多的時間。

在內(nèi)存受限的情況下，node.js就有優(yōu)勢了。

假設(shè)一個進程需要1M內(nèi)存，為了能同時開1000進程，你需要額外的1G內(nèi)存來給它。而對于node.js，它可能只需要20M來完成這個事，代價就是每個客戶端都需要多等那么一小會。

嚴(yán)格來說，并不提倡在node.js中實現(xiàn)業(yè)務(wù)邏輯，node.js最好是只用于以非阻塞模式連接多個阻塞模式的業(yè)務(wù)邏輯。

同一套業(yè)務(wù)邏輯，實現(xiàn)一個webservice中間接口，中間涉及memcached和mogodb的一些操作。
分別在Node.js和JAVA平臺實現(xiàn)，java代碼部署在Tomcat 7.0上，用Apache jmeter進行壓力測試。
得到的測試結(jié)果很是出乎意料，Node.js的高并發(fā)優(yōu)勢為什么沒有體現(xiàn)出來呢？？？
**操作系統(tǒng)：**CentOS 6.4（虛擬機）
**內(nèi)存：**1.5G
**CPU：**單核
并發(fā)數(shù) 100
**ramp-up period(in seconds)**1執(zhí)行次數(shù) 10
以下是測試結(jié)果：Lable #Sample Average Median 90%Line Min Max Error% Throughput KB/secNode.js HTTP請求 1000 333 369 485 1 956 0.0 183.3180568285976 40.995932630614114
Tomcat HTTP請求 1000 48 9 188 2 563 0.0 183.4862385321101 58.414564220183486
可以看到Node.js的平均執(zhí)行時間為333毫秒，Tomcat的執(zhí)行時間為48毫秒，Tomcat比Node.js快了近7倍！
補充1：即使是測試接口直接返回，不涉及后續(xù)的操作，Tomcat也比Node.js快了很多，求各位大神給個解釋。
補充2：修改jmeter 的 ramp-up period的測試條件，比如這個值增大（如10秒），node.js的執(zhí)行效率變高了，但這么想來也是違背了高并發(fā)的特性
拋磚引玉，一起探討問題。如果你也感興趣，不妨拿出點時間來寫一段程序測試一下，我希望能得到不一樣的結(jié)果。