Sending your first message from a new device in a megolm room can take 10s of seconds

[ara4n]

Erik saw a lockup of 20s when speaking from a new device in #megolm; I saw 8s. It looks like it takes 80-200ms to create each new olm session, and with 100 devices in the room that can take a while...

[ara4n]

As well as pruning devices, perhaps we could speed this up by using WebCrypto?

[NegativeMjark]

each new megolm session

I assume you mean olm session here? (We create olm sessions per recipient device, we create megolm session per room.)

[ara4n]

yes, corrected.

@richvdh presumably a quick win on this would be to be less aggressive about making new sessions - i.e. reuse them across browser restarts?

[richvdh]

reusing megolm sessions would mean also keeping track of who we had sent the session keys to, so it's not as quick a win as all that. In any case, it wouldn't do anything to reduce the number of Olm sessions we need to create, because we already reuse them across browser restarts.

For example, I just sent a message in #megolm, from a new browser instance (but an existing device, obviously). The time between me hitting enter, and making the "/send" request, was 1520ms, which was dominated by two round-trips to the server (one to download some keys (see #2275), and one to claim a bunch of one-time Olm keys). The longest frame was 312ms, when it was doing the encryption of the session key for each of the (120) devices in the room.

So, the problem here probably really only applies to the first message you send from a new device (as the title says); so reusing anything across browser restarts won't help us. When I tried that just now, it took about 10 seconds to send, which was dominated by two 5s js frames, which were verifying the Ed25519 signatures on the devices in the room, and creating Olm sessions for them, respectively.

Mitigation strategies probably include:

• downloading the device list, proactively (and doing the signature verification asynchronously), rather than waiting for the first send
• doing the session setup asynchronously rather than in one big loop
• seeing if we can optimise the session setup code
• consider setting up Olm sessions in the background proactively.

[uhoreg]

Since 2016, this is greatly improved, mostly by using a wasm version of olm. There is room for some more speedups (e.g. #11836 ), but I think that this issue can closed.