feat(replay): Handle large amounts of consecutive events#7211
Closed
feat(replay): Handle large amounts of consecutive events#7211
Conversation
We've seen problems when a lot of events are happening at the same time. E.g. when thousands of mutation observer events are triggered at the same time, this can lead to very poor performance. With this change, we detect if more than 2000 events happen in a rolling time window of 100ms. If so, we pause the replay, wait for 100ms, and resume it (which will trigger a full snapshot).
Contributor
Replay SDK metrics 🚀
develop |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Revision | LCP | CLS | CPU | JS heap avg | JS heap max | netTx | netRx | netCount | netTime |
|---|---|---|---|---|---|---|---|---|---|
| 1cf8988 | +53.81 ms | -0.00 ms | +4.80 pp | +929.88 kB | +1.05 MB | +2.22 kB | +41 B | +1 | +91.07 ms |
| 68655e3 | +72.60 ms | +0.00 ms | +7.90 pp | +922.72 kB | +1.04 MB | +2.22 kB | +41 B | +1 | +109.40 ms |
| a8449de | +58.27 ms | -0.00 ms | +7.12 pp | +927.42 kB | +1.05 MB | +2.2 kB | +41 B | +1 | +98.31 ms |
| 79babe9 | +58.69 ms | -0.00 ms | +4.40 pp | +927.46 kB | +1.06 MB | +2.23 kB | +41 B | +1 | +103.20 ms |
| 5359ba9 | +55.62 ms | -0.00 ms | +4.29 pp | +935.26 kB | +1.05 MB | +2.2 kB | +41 B | +1 | +79.05 ms |
*) pp - percentage points - an absolute difference between two percentages.
Last updated: Fri, 17 Feb 2023 08:57:44 GMT
Last updated: Fri, 17 Feb 2023 08:57:44 GMT
Contributor
size-limit report 📦
|
billyvg
reviewed
Feb 17, 2023
Member
billyvg
left a comment
There was a problem hiding this comment.
This is not going to help in our particular case because the issue is in the rrweb library before an event is even emitted/processed.
Member
Author
|
Closing this in favor of #7314 and other approaches following this. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
We've seen problems when a lot of events are happening at the same time. E.g. when thousands of mutation observer events are triggered at the same time, this can lead to very poor performance.
With this change, we detect if more than 2000 events happen in a rolling time window of 100ms. If so, we pause the replay, wait for 100ms, and resume it (which will trigger a full snapshot).
Note: I've selected the values 2000 & 100ms completely random. We can think about what reasonable amounts are here.
This is not a perfect fix, but IMHO it is a better experience to have a 100ms gap in your replay (and afterwards it should continue normally), than to freeze your page.
@billyvg can you try this with the repro app you've got?