Skip to content
This repository has been archived by the owner on Mar 13, 2024. It is now read-only.

MM-12630 Adding debounce to prevent client breaking for very high rate channels. #2041

Merged
merged 1 commit into from
Nov 20, 2018
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
57 changes: 56 additions & 1 deletion actions/websocket_actions.jsx
Original file line number Diff line number Diff line change
Expand Up @@ -373,7 +373,62 @@ function handleChannelMemberUpdatedEvent(msg) {
dispatch({type: ChannelTypes.RECEIVED_MY_CHANNEL_MEMBER, data: channelMember});
}

function handleNewPostEvent(msg) {
export function debouncePostEvent(func, wait) {
let timeout;
let queue = [];
let count = 0;

// Called when timeout triggered
const triggered = () => {
timeout = null;
if (queue.length > 0) {
const posts = {};
for (const queuedMsg of queue) {
const post = JSON.parse(queuedMsg.data.post);
if (!posts[post.channel_id]) {
posts[post.channel_id] = {};
}
posts[post.channel_id][post.id] = post;
}
for (const channelId in posts) {
if (!posts.hasOwnProperty(channelId)) {
continue;
}
dispatch({
crspeller marked this conversation as resolved.
Show resolved Hide resolved
type: PostTypes.RECEIVED_POSTS,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One other thing here, do we know how much of a difference this will have dispatching once vs dispatching repeatedly? I've changed the RECEIVED_POSTS action from the original code into a new action (something like RECEIVED_NEW_POST although that name is already taken) that only takes a single post with some of my scrolling-related changes, and I'm wondering if I'll need to add a new RECEIVED_NEW_POSTS action as well

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Batching was required to get the performance increases when this code actually fires. Otherwise you get lots of redux updates.

data: {posts: posts[channelId]},
channelId,
});
getProfilesAndStatusesForPosts(posts[channelId], dispatch, getState);
}
}
queue = [];
count = 0;
};

return function fx(msg) {
if (timeout && count > 2) {
// If the timeout is going this is the second or further event so queue them up.
if (queue.push(msg) > 200) {
// Don't run us out of memory, give up if the queue gets insane
queue = [];
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we do this without dumping the entire queue of posts when it becomes overloaded? It might be nice to only ignore any ones over the limit in that case

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This only happens when there are over 200 posts within 100ms of the previous post. Not really worried about not breaking the channel in that case.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah breaking the channel in this case is fine. The goal of this is to not break the entire app when one channel goes nuts.

console.log('channel broken because of too many incoming messages'); //eslint-disable-line no-console
}
clearTimeout(timeout);
timeout = setTimeout(triggered, wait);
} else {
// Apply immediately for events up until count reaches limit
count += 1;
func(msg);
clearTimeout(timeout);
timeout = setTimeout(triggered, wait);
}
};
}

const handleNewPostEvent = debouncePostEvent(handleNewPostEventWrapped, 100);

function handleNewPostEventWrapped(msg) {
const post = JSON.parse(msg.data.post);
dispatch(handleNewPost(post, msg));

Expand Down