I’m not exactly sure how to interpret your heap sizes.
Nodejs allocates much more memory from the system than it needs. That’s a chrome-inspired feature. I’m also not a big fan of it.
Loading a huge document in Yjs will consume a lot of memory. You can optimize memory usage by reducing the number of writes you perform on a Yjs document. Try to make as few changes as possible. I’ve seen in the past that users make Yjs modifications for every single mouse movement, which will blow up the size of a Yjs document over time.
In y-websocket we keep the Yjs document in-memory until all clients disconnected. If you didn’t specify persistence, then the document will be kept in-memory forever.
y-redis is an alternative backend to y-websocket that doesn’t keep documents in-memory. However, it’s new and slightly harder to setup.
There are also other providers like y-sweet or hocuspoces that give you scaling options. With liveblocks as a backend for Yjs, you don’t have to think about memory usage on the server.
You can optimize memory usage by reducing the number of writes you perform on a Yjs document. Try to make as few changes as possible. I’ve seen in the past that users make Yjs modifications for every single mouse movement, which will blow up the size of a Yjs document over time.
I believe this would be a good solution. Based on what I’ve observed in my application, yMap tracks numerous changes when a node is just moved from its current position to another position. ( This is because I am creating an interactive diagram with nodes ). When building a collaborative diagram application, it’s necessary for other users to see nodes move when I move them.
In y-websocket we keep the Yjs document in-memory until all clients disconnected. If you didn’t specify persistence , then the document will be kept in-memory forever.