Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

perf: extremely high network usage (Yjs updates are redundant) #11

Open
WofWca opened this issue Nov 23, 2023 · 2 comments
Open

perf: extremely high network usage (Yjs updates are redundant) #11

WofWca opened this issue Nov 23, 2023 · 2 comments

Comments

@WofWca
Copy link

WofWca commented Nov 23, 2023

Hi! Great work on making the lib CRDT-compatible.

The problem

So, when I draw a line with the "D" tool, just scribbling around without stopping the mouse or releasing left mouse button, bandwidth usage goes up to about 1 Mbit / s. That is one megabyte every 8 seconds, which is comparable to streaming video, whereas I'm just drawing a line. Based on my testing, it appears that the number can vary depending on the device's performance (the better the performance, the higher the bandwidth).

How do I know that it's not supposed to be like this?

Well, if you go to the "network" tab in dev tools, select the WebSocket connection and filter with "ke", you can see that we send an update every few milliseconds with a constantly growing size (it then resets at about 10kB, because I believe the line gets split). If you look inside each update and compare them, you can see that they're nearly identical bit-wise.

image

Comparably, after 30 seconds of continuously drawing a line, the resulting document is just 30 kB, which is about 100 times smaller than the amount of data I upload while drawing it.

How I discovered it

I was working on porting this example to webxdc, using the webxdc-yjs-provider library. It records all the document updates for a couple of seconds, then Y.mergeUpdates() them and sends to other peers. See https://codeberg.org/WofWca/webxdc-yjs-provider/issues/7
For that use case such high network usage is not acceptable, because all the messages are non-ephemeral, they're stored on the email server and are handled each time a webxdc app gets opened. Megabytes of data for a small drawing is not good.

Potentially useful clues

This to me looks extremely like what would happen if we were to continuously delete and add the line being drawn instead of updating the existing one.

I have tried to Y.mergeUpdates() several of such updates together, but doesn't reduce the size of collected updates almost at all (it's around 1%).
However, if we send the data to other peers using diff like described here with a frequency of ~1 second, instead of sending each update immediately, such as the y-websocket library does, the updates are much smaller.

Also I noticed that simply moving such a line also creates pretty big updates.

WofWca added a commit to WofWca/tldraw-webxdc that referenced this issue Nov 23, 2023
WofWca added a commit to WofWca/tldraw-webxdc that referenced this issue Nov 23, 2023
@WofWca
Copy link
Author

WofWca commented Nov 28, 2023

Hey, good news. There is a fork of this example app adapted to Loro CRDT, and recently they apparently made performance improvements to it:

Maybe we could adapt them.

@steveruizok
Copy link
Collaborator

Oh, that's great! I'll check the example to see if they've come up with a better solution.

Our updates are very far from optimized, though luckily most people don't draw for eight seconds at a time. Still, there's a lot of room for improvement.

...and arguably yjs/CRDTs are not the right multiplayer solution for tldraw, given the contextual information that needs to be sent across. Now that the tldraw dot com is source available, you can check out our own sync solution which is much closer to our sockets example. https://github.com/tldraw/tldraw-sockets-example

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants