這篇文章主要介紹“EventLoop如何測(cè)試Node或頁(yè)面的性能”，在日常操作中，相信很多人在EventLoop如何測(cè)試Node或頁(yè)面的性能問(wèn)題上存在疑惑，小編查閱了各式資料，整理出簡(jiǎn)單好用的操作方法，希望對(duì)大家解答”EventLoop如何測(cè)試Node或頁(yè)面的性能”的疑惑有所幫助！接下來(lái)，請(qǐng)跟著小編一起來(lái)學(xué)習(xí)吧！
專(zhuān)注于為中小企業(yè)提供網(wǎng)站制作、成都做網(wǎng)站服務(wù),電腦端+手機(jī)端+微信端的三站合一,更高效的管理,為中小企業(yè)五原免費(fèi)做網(wǎng)站提供優(yōu)質(zhì)的服務(wù)。我們立足成都，凝聚了一批互聯(lián)網(wǎng)行業(yè)人才，有力地推動(dòng)了上千余家企業(yè)的穩(wěn)健成長(zhǎng)，幫助中小企業(yè)通過(guò)網(wǎng)站建設(shè)實(shí)現(xiàn)規(guī)模擴(kuò)充和轉(zhuǎn)變。
Event Loop 機(jī)制大家應(yīng)該都有了解。我先重復(fù)總結(jié)一下。
Node.js 和 Javascript 的 Event Loop 不太一樣，直觀上是多了 setImmediate 和 process.nextTick 兩個(gè) API。其次是由于運(yùn)行時(shí)不一樣，Html Standrad 里面會(huì)考慮多頁(yè)面、DOM操作等不同來(lái)源會(huì)有不同的 task queue 。而 Node.js Event Loop 中需要考慮的沒(méi)這么多。
按照我的理解，雙方在概念上是一致的，可以如此概括（或者看這里）：
task queue 任務(wù)隊(duì)列。一些事件等會(huì)被定義為任務(wù)，很多時(shí)候會(huì)被稱(chēng)為 MacroTask（宏任務(wù)）與 MicroTask 進(jìn)行對(duì)應(yīng)。每次會(huì)獲取隊(duì)頭的 task 進(jìn)行執(zhí)行。
microtask queue 微任務(wù)隊(duì)列。會(huì)有一個(gè)微任務(wù)隊(duì)列，一個(gè) Task 內(nèi)一般會(huì)執(zhí)行清空微任務(wù)隊(duì)列。
如此往復(fù)。
在上面的了解之后，有一個(gè)簡(jiǎn)單的對(duì)性能進(jìn)行測(cè)量的方法：每秒內(nèi)完成了多少次 Event Loop 循環(huán)，或者說(shuō)執(zhí)行了多少個(gè) MacroTask，這樣我們大致就能知道代碼中同步的代碼的執(zhí)行情況。
測(cè)試函數(shù)
class MacroTaskChecker {
constructor(macroTaskDispatcher, count = 1000, cb = () => { }) {
this.macroTaskDispatcher = macroTaskDispatcher
this.COUNT = count
this.cb = cb
}
start(cb) {
this.cb = cb || this.cb
this.stop = false
const scope = () => {
let count = this.COUNT
const startTime = performance.now()
const fn = () => {
count--
if (count > 0) this.macroTaskDispatcher(fn)
else {
const endTime = performance.now()
// 執(zhí)行 COUNT 次宏任務(wù)之后 計(jì)算平均每秒執(zhí)行了多少個(gè)
this.cb({
avg: this.COUNT / (endTime - startTime) * 1000,
timestamp: endTime
})
!this.stop && this.macroTaskDispatcher(scope)
}
}
this.macroTaskDispatcher(fn)
}
scope()
}
stop() {
this.stop = true
}
}
之后，執(zhí)行一些死循環(huán)去測(cè)試是否能檢測(cè)到密集同步代碼執(zhí)行。
function meaninglessRun(time) {
console.time('meaninglessRun')
for (let i = time; i--; i > 0) {
// do nothing
}
console.timeEnd('meaninglessRun')
}
setTimeout(() => {
meaninglessRun(1000 * 1000 * 1000)
}, 1000 * 5)
setTimeout(() => {
checker.stop()
console.log('stop')
}, 1000 * 20)
setTimeout
const checker = new MacroTaskChecker(setTimeout, 100)
checker.start(v => console.log(`time: ${v.timestamp.toFixed(2)} avg: ${v.avg.toFixed(2)}`))
從輸出中能明顯看到同步阻塞的時(shí)候avg是下降的。不過(guò)在 browser 和 node.js 上測(cè)試兩邊會(huì)有明顯差距。
// node.js
time: 4837.47 avg: 825.14
time: 4958.18 avg: 829.83
meaninglessRun: 918.626ms
time: 6001.69 avg: 95.95
time: 6125.72 avg: 817.18
time: 6285.07 avg: 635.16
// browser
time: 153529.90 avg: 205.21
time: 154023.40 avg: 204.46
meaninglessRun: 924.463ms
time: 155424.00 avg: 71.62
time: 155908.80 avg: 208.29
time: 156383.70 avg: 213.04
雖然達(dá)成我們的目的，但是使用 setTimeout 是不完全能準(zhǔn)確記錄下每一個(gè)任務(wù)的。根據(jù) HTML Standrad 和 MDN 的說(shuō)法，setTimeout 最少的會(huì)等待4ms。從這個(gè)角度看 browser avg * 4ms ≈ 1000ms。而 node.js 應(yīng)該是沒(méi)有遵循 browser 那邊的約定，但是也沒(méi)有執(zhí)行到記錄每一個(gè)loop。
setImmediate
如果使用 node.js 的 setImmediate：
const checker = new MacroTaskChecker(setImmediate, 1000 * 10)
可以看到執(zhí)行次數(shù)大概高出 Node.js setTimeout 一個(gè)量級(jí)：
time: 4839.71 avg: 59271.54
time: 5032.99 avg: 51778.84
meaninglessRun: 922.182ms
time: 6122.44 avg: 9179.95
time: 6338.32 avg: 46351.38
time: 6536.66 avg: 50459.77
按照 Node.js 文檔中的解釋?zhuān)?code>setImmediate 會(huì)在每一個(gè) loop (phase) 的 check 階段執(zhí)行。使用 setImmediate 應(yīng)該是能準(zhǔn)確記錄每一次 Loop 的。我這臺(tái)機(jī)器大概是 40000 到 60000 之間的循環(huán)次數(shù)。
window.postMessage
在 browser 上由于沒(méi)有 setImmediate 我們可以按照 MDN 上的指引使用 window.postMessage 實(shí)現(xiàn)一個(gè)。
如果想在瀏覽器中實(shí)現(xiàn) 0ms 延時(shí)的定時(shí)器，你可以參考這里所說(shuō)的
window.postMessage()
const fns = []
window.addEventListener("message", () => {
const currentFns = [...fns]
fns.length = 0
currentFns.forEach(fn => fn())
}, true);
function messageChannelMacroTaskDispatcher(fn) {
fns.push(fn)
window.postMessage(1)
}
可以看到和 node.js setImmediate 量級(jí)是一致的。
time: 78769.70 avg: 51759.83
time: 78975.60 avg: 48614.49
meaninglessRun: 921.143 ms
time: 80111.50 avg: 8805.14
time: 80327.00 avg: 46425.26
time: 80539.10 avg: 47169.81
MessageChannel
理論上 browser 使用 MessageChannel 應(yīng)該也是可以的，還避免了無(wú)效的消息被其他 window.addEventListener("message", handler) 接收：
const { port1, port2 } = new MessageChannel();
const fns = []
port1.onmessage = () => {
const currentFns = [...fns]
fns.length = 0
currentFns.forEach(fn => fn())
};
function messageChannelMacroTaskDispatcher(fn) {
fns.push(fn)
port2.postMessage(1)
}
不是很懂為啥會(huì)比 window.postMessage 頻繁一點(diǎn)，同時(shí)啟動(dòng)兩個(gè) checker 的話可以看到 log 是成對(duì)出現(xiàn)的，也就是說(shuō)一個(gè)loop內(nèi)大家都只執(zhí)行了一次。我猜測(cè)是 window.postMessage 的實(shí)現(xiàn)方式消耗會(huì)大一些。
time: 54974.80 avg: 68823.12
time: 55121.00 avg: 68493.15
meaninglessRun: 925.160888671875 ms
time: 56204.60 avg: 9229.35
time: 56353.00 avg: 67430.88
time: 56503.10 avg: 66666.67
// 一起執(zhí)行 wp=window.postMessage mc=MessageChannel
wp time: 43307.90 avg: 25169.90
mc time: 43678.40 avg: 27005.13
wp time: 43678.60 avg: 26990.55
mc time: 44065.80 avg: 25833.12
wp time: 44066.00 avg: 25819.78
mc time: 44458.40 avg: 25484.20
在 node.js 上也有 MessageChannel ，是否也可以用來(lái)測(cè)量loop次數(shù)呢？
mc time: 460.99 avg: 353930.80
mc time: 489.52 avg: 355088.11
mc time: 520.30 avg: 326384.64
mc time: 551.78 avg: 320427.29
量級(jí)很不正常。理論上不應(yīng)該超過(guò) setImmediate 的。如果同時(shí)啟動(dòng) setImmediate 和 setTimeout 的 checker:
...
(messagechannel) time: 1231.10 avg: 355569.31
(messagechannel) time: 1260.14 avg: 345825.77
(setImmediate) time: 1269.95 avg: 339.27
(setTimeout) time: 1270.09 avg: 339.13
(messagechannel) time: 1293.80 avg: 298141.74
(messagechannel) time: 1322.50 avg: 349939.04
...
很明顯跟不是宏任務(wù)了。我猜測(cè) MessageChannel 在 node.js 被歸入到跟 socket 等同級(jí)別了，就是超出閾值之后的任務(wù)會(huì)移動(dòng)到下一個(gè)loop中。
到此，關(guān)于“EventLoop如何測(cè)試Node或頁(yè)面的性能”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實(shí)踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識(shí)，請(qǐng)繼續(xù)關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編會(huì)繼續(xù)努力為大家?guī)?lái)更多實(shí)用的文章！
重慶分公司
重慶分公司
