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

[crspeller]

Adds a queued denounce function to websocket event handling for new posts. This is an attempt to prevent very high rate channels from breaking the client by overloading it with posts.

[mattermod]

Setup Test Server label detected. Spinmint test server created if build succeeds (checks pass and no conflicts with base branch).

[mattermod]

Spinmint test server created at: https://i-0f957e01030fc6a87.test.spinmint.com

Test Admin Account: Username: sysadmin | Password: sysadmin

Test User Account: Username: user-1 | Password: user-1

Instance ID: i-0f957e01030fc6a87

[crspeller]

@lindy65 Can you take a look at this? Should be able to test this with /test posts like we discussed before.

[lindy65]

@crspeller - yep, will test this today using /test posts :)

[lindy65]

Hey @crspeller

Tested by enabling Developer Test Commands in System Console and using /test posts 100 ten times in a row. The channel broke.

Then tested /test posts 75 ten times in a row and the channel still broke.

Adding ten times /test posts 50 in a row didn't break the channel but I continued to 13 times and it broke on the twelfth post of /test posts 50

I am posting these test post commands very quickly one after the other with no pause inbetween so am not sure if this is a true simulation of user experience?

The channel does not break for over 30 continuous /test posts 5, /test posts 10, /test posts 15, test posts 20 posts at high speed.

It starts to break again at around 25 continuous /test posts 30 posts at high speed.

Let me know if you need me to test in a different way or whether these results are sufficient?

[crspeller]

@lindy65 That message is fine. The "break" is only for very high frequency channels. The important thing to test is if the client is still usable while the posts are incoming.

You can compare the behavior to the behavior on master and you should see the difference.

[lindy65]

Thanks @crspeller

Just compared the behavior on master and absolutely can see a huge difference! Performance on the spinmint is way, way better.

[hmhealey]

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

[crspeller]

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

[hmhealey]

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

[crspeller]

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.

[jwilander]

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.

[crspeller]

@hmhealey Ready for re-review.

[hmhealey]

The only thing I'm still a bit unsure about is how the batching will affect the changes to the post reducer will affect this, but I can deal with that when the time comes

[jwilander]

LGTM

[mattermod]

Spinmint test server destroyed