What is the performance impact of running webrtc-issue-detector in a prod environment?

[kelvin2200]

We're thinking of implementing this as a means to detect slow networks in our WebRTC app and was wondering what the performance impact is, especially on slow/older devices or devices that are under heavy load due to other tasks/apps running at the same time

[evgmel]

Hi @kelvin2200 ! Actual performance impact depends on the amount of RTP senders/receivers, as long as getStats() is executed for each of them (for those with media tracks enabled).
You could measure the impact on a slow/older device with & without of WID library with your app layout / consumed tracks to understand the difference on the specific device/context.
In our roadmap checklist there is such line: Adaptive getStats() call interval based on last getStats() execution time. That's what will be useful in cases when we understand that the statistics was not parsed/analysed for the expected time interval.
But if you implement it, you can always open a PR. Any useful changes are welcome!

[kelvin2200]

thank you @evgmel

[kelvin2200]

@evgmel may I ask how the stats are computed?
What does avgJitter mean exactly?
payloads that signal an issue, have a property named avgJitterBufferDelay
but the scoring callback has scores.statsSamples.inboundStatsSample.avgJitter without the avgJitterBufferDelay.

Im trying to figure out how to use the lib to have at least a semi-accurate detection, but I don't understand the jitter part.
Info found on the web says the average jitter is accepable while under 30ms. If one is to compare to that metric, what would be considered? the avgJitter? or the avgJitterBufferDelay....

[desher]

Hi @kelvin2200,
avgJitter is an average jitter value of all RTCPeerConnection active streams and that's one of the most important network quality indicators. You can just watch network scores (onNetworkScoresUpdated) because the score calculation also takes jitter into account as well as other important network metrics.