咱們使用nodejs寫好了程序以後,要是想對該程序進行性能分析的話,就須要用到profile工具了。html
雖然有不少很方便和強大的第三方profile工具,可是咱們這裏主要講解V8和node自帶的profile,由於他們已經足夠簡單和強大了。使用他們基本上能夠知足咱們的平常分析須要。node
下面就一塊兒來看看吧。linux
nodejs是運行在V8引擎上的,而V8引擎自己就提供了內置的profile工具,要想直接使用V8引擎,我須要下載V8源代碼,而後進行build。通常來講咱們有兩種build V8的方法。git
gm是一個很是方便的all-in-one的腳本,能夠用來生成build文件,觸發build過程和運行測試用例。web
通常來講,gm腳本的位置在:/path/to/v8/tools/dev/gm.pyshell
咱們能夠爲其建立一個alias,方便後面的使用:json
alias gm=/path/to/v8/tools/dev/gm.py
build V8:segmentfault
gm x64.release
build以後進行用例驗證:windows
gm x64.release.check
是否是很簡單?app
手動build V8就比較麻煩了,咱們也能夠分爲三步,1.生成build文件,2.觸發build,3.運行測試用例
咱們可使用gn來爲out/foo生成build文件:
gn args out/foo
上面的命令將會開啓一個編輯窗口,用來輸入gn的參數。
咱們能夠添加list來查看全部的參數描述:
gn args out/foo --list
固然咱們也能夠直接指定參數,來建立build文件:
gn gen out/foo --args='is_debug=false target_cpu="x64" v8_target_cpu="arm64" use_goma=true'
除了gn以外,咱們還可使用v8自帶的v8gen來建立build文件:
alias v8gen=/path/to/v8/tools/dev/v8gen.py v8gen -b 'V8 Linux64 - debug builder' -m client.v8 foo
建立好build文件以後,咱們就能夠進行編譯了。
build全部的V8:
ninja -C out/x64.release
只build d8:
ninja -C out/x64.release d8
最後咱們運行測試,來驗證是否構建成功:
tools/run-tests.py --outdir out/foo //或者 tools/run-tests.py --gn
build好V8以後,咱們就可使用其中的命令來生成profile文件了。
找到d8文件:
d8 --prof app.js
經過添加 --prof 參數,咱們能夠生成一個v8.log文件,這個文件中包含了profiling數據。
注意這時候的v8.log文件雖然不是二進制格式的,可是閱讀起來仍是有難度的,由於它只是簡單的作了log操做,並無進行有效的統計分析。
咱們看下生成的文件:
... profiler,begin,1000 tick,0x7fff688bbe36,839,0,0x0,6 tick,0x7fff688bc2d2,2081,0,0x0,6 tick,0x100373430,3263,0,0x0,6 code-creation,Builtin,3,3746,0x1008aa020,1634,RecordWrite code-creation,Builtin,3,3766,0x1008aa6a0,457,EphemeronKeyBarrier code-creation,Builtin,3,3773,0x1008aa880,44,AdaptorWithBuiltinExitFrame code-creation,Builtin,3,3781,0x1008aa8c0,294,ArgumentsAdaptorTrampoline code-creation,Builtin,3,3788,0x1008aaa00,203,CallFunction_ReceiverIsNullOrUndefined code-creation,Builtin,3,3796,0x1008aaae0,260,CallFunction_ReceiverIsNotNullOrUndefined code-creation,Builtin,3,3804,0x1008aac00,285,CallFunction_ReceiverIsAny code-creation,Builtin,3,3811,0x1008aad20,130,CallBoundFunction ...
能夠看到日誌文件中只記錄了事件的發生,可是並無統計信息。
若是想要生成咱們看得懂的統計信息,則可使用:
//windows tools\windows-tick-processor.bat v8.log //linux tools/linux-tick-processor v8.log //macOS tools/mac-tick-processor v8.log
來生成能夠理解的日誌文件。
生成的文件大概是下面樣子的:
Statistical profiling result from benchmarks\v8.log, (4192 ticks, 0 unaccounted, 0 excluded). [Shared libraries]: ticks total nonlib name 9 0.2% 0.0% C:\WINDOWS\system32\ntdll.dll 2 0.0% 0.0% C:\WINDOWS\system32\kernel32.dll [JavaScript]: ticks total nonlib name 741 17.7% 17.7% LazyCompile: am3 crypto.js:108 113 2.7% 2.7% LazyCompile: Scheduler.schedule richards.js:188 103 2.5% 2.5% LazyCompile: rewrite_nboyer earley-boyer.js:3604 103 2.5% 2.5% LazyCompile: TaskControlBlock.run richards.js:324 96 2.3% 2.3% Builtin: JSConstructCall ...
用慣的IDE的同窗可能在想,能不能有個web頁面來統一展現這個結果呢?
有的,V8提供了profview工具,讓咱們能夠從web UI來分析生成的結果。
profview是一個html工具,咱們能夠從 https://chromium.googlesource... 下載。
若是要使用profview,咱們還須要對第一步生成的v8.log文件進行預處理:
linux-tick-processor --preprocess > v8.json
而後在profview頁面上傳v8.json進行分析便可。
--prof 還能夠接其餘參數,好比 --log-timer-events, 經過使用這個參數能夠用來統計V8引擎中花費的時間。
d8 --prof --log-timer-events app.js tools/plot-timer-events v8.log
第一個命令生成v8.log文件,第二個命令會生成一個timer-events.png圖形文件,更加直觀的展現數據。
由於生成日誌實際上對程序的性能是有必定的影響的,咱們還能夠爲plot-timer-events添加失真因子,來糾正這個問題。若是咱們沒有指定糾正因子,腳本會自動進行查找。固然,咱們也能夠向下面這樣手動指定:
tools/plot-timer-events --distortion=4500 v8.log
在nodejs 4.4.0以前,只能下載V8的源代碼進行編譯,才能進行profile。 而在nodejs 4.4.0以後,node命令已經集成了V8的功能。
咱們可使用 node --v8-options 來查看 node中可用的V8參數:
node --v8-options SSE3=1 SSSE3=1 SSE4_1=1 SAHF=1 AVX=1 FMA3=1 BMI1=1 BMI2=1 LZCNT=1 POPCNT=1 ATOM=0 Synopsis: shell [options] [--shell] [<file>...] d8 [options] [-e <string>] [--shell] [[--module] <file>...] -e execute a string in V8 --shell run an interactive JavaScript shell --module execute a file as a JavaScript module Note: the --module option is implicitly enabled for *.mjs files. The following syntax for options is accepted (both '-' and '--' are ok): --flag (bool flags only) --no-flag (bool flags only) --flag=value (non-bool flags only, no spaces around '=') --flag value (non-bool flags only) -- (captures all remaining args in JavaScript) Options: --use-strict (enforce strict mode) type: bool default: false --es-staging (enable test-worthy harmony features (for internal use only)) type: bool default: false ...
參數不少,一樣的咱們可使用 --prof 參數:
node --prof app.js
會在本地目錄生成一個相似 isolate-0x102884000-14025-v8.log 的文件。
文件的內容和V8生成的一致,這裏就不列出來了。
要想分析這個文件,可使用:
node --prof-process isolate-0x102884000-14025-v8.log > processed.txt
看下生成的分析結果:
Statistical profiling result from isolate-0x102884000-14025-v8.log, (296 ticks, 4 unaccounted, 0 excluded). [Shared libraries]: ticks total nonlib name 6 2.0% /usr/lib/system/libsystem_pthread.dylib 6 2.0% /usr/lib/system/libsystem_kernel.dylib 2 0.7% /usr/lib/system/libsystem_malloc.dylib 1 0.3% /usr/lib/system/libmacho.dylib 1 0.3% /usr/lib/system/libcorecrypto.dylib [JavaScript]: ticks total nonlib name ... [Summary]: ticks total nonlib name 0 0.0% 0.0% JavaScript 276 93.2% 98.6% C++ 24 8.1% 8.6% GC 16 5.4% Shared libraries 4 1.4% Unaccounted [C++ entry points]: ticks cpp total name 142 63.1% 48.0% T __ZN2v88internal21Builtin_HandleApiCallEiPmPNS0_7IsolateE 82 36.4% 27.7% T __ZN2v88internal40Builtin_CallSitePrototypeGetPromiseIndexEiPmPNS0_7IsolateE 1 0.4% 0.3% T __ZN2v88internal36Builtin_CallSitePrototypeGetFileNameEiPmPNS0_7IsolateE ...
和V8的也很相似。
從Summary和各個entry points中,咱們能夠進一步分析程序中到底哪一塊佔用了較多的CPU時間。
上面的百分百的意思是,在採樣的這些數據中,有93.2%的都在運行C++代碼。那麼咱們接下來就應該去看一下,究竟是哪些C++代碼佔用了最多的時間,並找出相應的解決辦法。
本文做者:flydean程序那些事本文連接:http://www.flydean.com/nodejs-profile/
本文來源:flydean的博客
歡迎關注個人公衆號:「程序那些事」最通俗的解讀,最深入的乾貨,最簡潔的教程,衆多你不知道的小技巧等你來發現!