From a0fda0c3ab3dfc81900e4e86c67462a7bc042414 Mon Sep 17 00:00:00 2001 From: RenaudS Date: Tue, 8 Nov 2016 14:16:59 +0800 Subject: [PATCH] Reduce tooBusy false-negative In my company we realize that toobusy.js generate a large amount of false-positive (Our settings are highWater = 80 & smootingFactor = 1/5). Event with this conservative factor, in a sudden load on the service would cause currentLag to jump from 0 to 200+ ms which triggered cause all consecutive requests to be rejected even the server has largely the resource to handle them. This commit bring a proposal that solve this situation: 1. Limit the maximum lag value: As highWater * 2 == (100% too busy) we want to avoid the current lag to suddenly jump to a stat of rejection all requests. Limiting the lag metric to highWater * 2 insure a smooth and coherent current Lag increase. 2. Inverse smoothfactor for decrementing the currentLag value: In a situation of a quick punctual overload of the system the recovery should be fast to avoid false-negative rejections when the resources are already available. Inverting the smoothfactor when the lag measure is smaller than the current lag insure full resources usage. --- toobusy.js | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/toobusy.js b/toobusy.js index 1f6f7ac..ae8e8ec 100644 --- a/toobusy.js +++ b/toobusy.js @@ -150,10 +150,14 @@ function start() { var now = Date.now(); var lag = now - lastTime; lag = Math.max(0, lag - interval); + + // Reverse the factor for lag decrement + var factor = lag < currentLag ? 1 - smoothingFactor : smoothingFactor; + // Dampen lag. See SMOOTHING_FACTOR initialization at the top of this file. - currentLag = smoothingFactor * lag + (1 - smoothingFactor) * currentLag; + currentLag = factor * Math.min(lag, highWater * 2) + (1 - factor) * currentLag; lastTime = now; - + if (lagEventThreshold !== -1 && currentLag > lagEventThreshold) { eventEmitter.emit(LAG_EVENT, currentLag); }