換一個角度,在CPU密集的應用場景中,Node是否能勝任呢?實際上,V8的執行效率是十分高的。單以執行效率評判,V8的效率毋庸置疑。
我們將相同的裴波那契數列(F0=0,F1=1,Fn=F(n-1)+F(n-2)(n>=2))分別用各種腳本語言寫了算法實現,并進行了n=40的計算,以比較性能。這個測試主要偏重CPU棧操作,下表是其中一次運算耗時的排行。在這些腳本語言中(其中C和Go語言是靜態語言,用于參考),Node是足夠高效的,它優秀的運算能力主要來自V8的深度性能優化:

這樣的測試盡管并不能完全反映出各個語言的性能優劣,但已經可以表明Node在性能上不俗的表現。從另一個角度來看,這可以表明CPU密集型應用其實并不可怕。CPU密集型應用給Node帶來的挑戰主要是:由于JavaScript單線程的原因,如果有長時間運行的計算(比如大循環),將導致CPU時間片不能釋放,使得后續I/O無法發起。但是適當調整和分解大型運算任務為多個小任務,使得運算能夠適時釋放,不阻塞I/O調用的發起,這樣即可享受到并行異步I/O的好處,還能充分利用CPU。
關于CPU密集型應用,Node的異步I/O已經解決了在單線程上CPU與I/O之間阻塞無法重疊利用的問題,I/O阻塞造成的性能浪費遠比CPU的影響小。對于長時間運行的計算,如果它的耗時超過普通阻塞I/O的耗時,那么應用場景就需要重新評估,因為這類計算比I/O阻塞還影響效率,甚至說是一個純計算的場景,根本沒有I/O。此類應用場景或許應當采用多線程的方式進行計算。Node雖然沒有提供多線程用于計算支持,但是還是有以下兩個方式來充分利用CPU:
* Node可以通過編寫C/C++擴展的方式更高效的利用CPU,將一些V8不能做到性能極致的地方通過C/C++來實現。由上面的測試結果可以看到,通過C/C++擴展的實現裴波那契數列計算,速度比Java還快。
* 如果單線程的Node不能滿足需求,甚至用了C/C++擴展后還覺得不夠,那么通過子進程的方式,將一部分Node進程當作常駐服務進程用于計算,然后利用進程間的消息傳遞結果,將計算與I/O分離,這樣還能充分利用多CPU。
CPU密集不可怕,如何調度是訣竅。
- 目錄
- 第1章 Node 簡介
- 1.1 Node 的誕生歷程
- 1.2 Node 的命名與起源
- 1.2.1 為什么是 JavaScript
- 1.2.2 為什么叫 Node
- 1.3 Node給JavaScript帶來的意義
- 1.4 Node 的特點
- 1.4.1 異步 I/O
- 1.4.2 事件與回調函數
- 1.4.3 單線程
- 1.4.4 跨平臺
- 1.5 Node 的應用場景
- 1.5.1 I/O 密集型
- 1.5.2 是否不擅長CPU密集型業務
- 1.5.3 與遺留系統和平共處
- 1.5.4 分布式應用
- 1.6 Node 的使用者
- 1.7 參考資源
- 第2章 模塊機制
- 2.1 CommonJS 規范
- 2.1.1 CommonJS 的出發點
- 2.1.2 CommonJS 的模塊規范
- 2.2 Node 的模塊實現
- 2.2.1 優先從緩存加載
- 2.2.2 路徑分析和文件定位
- 2.2.3 模塊編譯
- 2.3 核心模塊
- 2.3.1 JavaScript核心模塊的編譯過程
- 2.3.2 C/C++核心模塊的編譯過程
- 2.3.3 核心模塊的引入流程
- 2.3.4 編寫核心模塊
- 2.4 C/C++擴展模塊
- 2.4.1 前提條件
- 2.4.2 C/C++擴展模塊的編寫
- 2.4.3 C/C++擴展模塊的編譯
- 2.4.2 C/C++擴展模塊的加載
- 2.5 模塊調用棧
- 2.6 包與NPM
- 2.6.1 包結構
- 2.6.2 包描述文件與NPM
- 2.6.3 NPM常用功能
- 2.6.4 局域NPM
- 2.6.5 NPM潛在問題
- 2.7 前后端共用模塊
- 2.7.1 模塊的側重點
- 2.7.2 AMD規范
- 2.7.3 CMD規范
- 2.7.4 兼容多種模塊規范
- 2.8 總結
- 2.9 參考資源
- 第3章 異步I/O
- 3.1 為什么要異步I/O
- 3.1.1 用戶體驗
- 3.1.2 資源分配
- 3.2 異步I/O實現現狀
- 3.2.1 異步I/O與非阻塞I/O
- 3.2.2 理想的非阻塞異步I/O
- 3.2.3 現實的異步I/O
- 3.3 Node的異步I/O
- 3.3.1 事件循環
- 3.3.2 觀察者
- 3.3.3 請求對象
- 3.3.4 執行回調
- 3.3.5 小結
- 3.4 非I/O的異步API
- 3.4.1 定時器
- 3.5 事件驅動與高性能服務器