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

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

Open
ara4n opened this Issue Sep 10, 2016 · 4 comments

Comments

Projects
None yet
3 participants
@ara4n
Member

ara4n commented Sep 10, 2016

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

This comment has been minimized.

Show comment
Hide comment
@ara4n

ara4n Sep 12, 2016

Member

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

Member

ara4n commented Sep 12, 2016

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

@NegativeMjark

This comment has been minimized.

Show comment
Hide comment
@NegativeMjark

NegativeMjark Sep 14, 2016

Contributor

each new megolm session

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

Contributor

NegativeMjark commented Sep 14, 2016

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

This comment has been minimized.

Show comment
Hide comment
@ara4n

ara4n Sep 17, 2016

Member

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?

Member

ara4n commented Sep 17, 2016

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

This comment has been minimized.

Show comment
Hide comment
@richvdh

richvdh Sep 18, 2016

Member

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.
Member

richvdh commented Sep 18, 2016

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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment