Throttling updates to reduce server load

[matsuyama-k1]

Checklist

[ x] Are you reporting a bug? Use github issues for bug reports and feature requests. For general questions, please use https://discuss.yjs.dev/ [ x ] Try to report your issue in the correct repository. Yjs consists of many modules. When in doubt, report it to https://github.com/yjs/yjs/issues/

Is your feature request related to a problem? Please describe. Every time a user makes an update, an update is sent to the server. As a result, a large number of database writes occur, which can put significant strain on the server and database. When central server is written in serverless environment, db writes becomes costly due to the high volume of write operations.

Describe the solution you'd like I would like to add a throttling option for updates.

Additional context I customized y-websocket in my project, and it works well. Below is the code I added to y-websocket:

const THROTTLE_TIME_MS = 5000
// y-websocket
export class WebsocketProvider extends Observable<string> {
  constructor(doc, ...) {
    // ...

    this._updates = [];

    this._batchBroadcastUpdates = () => {
      const mergedUpdate = Y.mergeUpdates(this._updates)
      // refresh queue when updates sent
      this._updates = [];

      const encoder = encoding.createEncoder();
      encoding.writeVarUint(encoder, messageSync);
      syncProtocol.writeUpdate(encoder, mergedUpdate);

      broadcastMessage(this, encoding.toUint8Array(encoder), false);
    };

    this._throttledBroadcast = throttle(() => {
      this._batchBroadcastUpdates();
    }, THROTTLE_TIME_MS);

    this._updateHandler = (update, origin) => {
      if (origin !== this) {
        // add update queue
        this._updates.push(update);
        this._throttledBroadcast();
      }
    };

    this.doc.on('update', this._updateHandler);
  }
  disconnect() {
    this._batchBroadcastUpdates();
    // ...
  }
}

• [x] I'm a sponsor 💖
• [ ] This feature is critical for my project.

[dmonad]

Wouldn't it be better to cache server operations? I currently see no reason to throttle client-distributed operations.

• The clients broadcast every individual change
• The server distributes all messages received by the clients
• The server stores all received updates after a debounce. It can use Y.mergeUpdates(updates) to merge all received updates into a single entry.

[matsuyama-k1]

@dmonad Actually. I might not be in common situation. Since I set up yjs server in AWS Lambda functions, I cant throttle in the server side due to their stateless nature. In this case we have to implement throttling on the client side. I realized that if this is not common situation we do not have to implement this feature in y-websocket.

[martinwcf]

I can give a second scenario.

Dragging 50 elements by changing x and y positions takes almost half the frame time making everything choppy, even on a new MacBook Pro M4.

My understanding is the overhead of the actual sending call, for multiple tiny ~13B payloads instead of one, at high frame rates, is degrading the performance.

We don't control Y.js calls because they're immediately fired from using Mobx-keystone with a middleware binding between Yjs/y-websocket. We do want immediate reaction for the UI but would benefit from network throttling to avoid this slow down and to avoid having to discard Mobx which is a solution the team feels confortable with, to implement a custom solution that handles throttling.

Thank you @matsuyama-k1 for providing a working workaround on the original message. I'll see if this is enough for our case.

EDIT: Tested something similar to the example and still get's choppy, now from mergeUpdatesV2 instead of send. But still opens the possibility to pausing/unpausing during operations while holding the mouse button down, and could broadcast on mouse up. So, pause/unpause could also be a nice feature to have.