Dashboard choking with data
Dudemullet opened this issue · comments
We were theorizing that the dashboard was being choked by receiving so much data at the same time. I was thinking maybe the amount of data isn't the problem maybe it's how we're trying to act on request.
Maybe if on-update-player we add the data to a queue instead of acting upon request. And just have a different process that tends to the queue (requestAnimationFrame maybe?).
Just putting this down so we have a task to fix the dashboard.
I think you're right. We were sending the leaders vector to the dashboard everytime a player board updated. So the dashboard was trying to re-render the canvases and DOM elements at ~1000 Hz if we had 100 players updating at 10 fps.
I think we should have an atom on the server for the current leaders. This will allow us to only emit changes to the dashboard when we detect them on-update-player. This means we'll need to only emit the entire leaders state when the dashboard first connects.
On the server, I imagine we can just emit the board changes directly to the dashboard on-update-player only if the player is a displayed leader. Then only emit the score and rank updates when they change, which should be intermittent.
On the dashboard client, we just batch the canvas drawing on requestAnimFrame. The score and rank updates are already batched on the server, so we can just react to them immediately in the dashboard.
Rushed this during lunch: fbf533e
Dashboard video: http://youtu.be/I1-aBSUztkk