Wire-webapp: Wire takes hours to load (slow to start)

[0ki]

Wire for web version

2017-12-07-11-13-prod

Browser version

Firefox Quantum 57.0.1 (64-bit)
Problem is appeared around version 55 or 56.

Installed browser addons

Adblock Plus, Ghostery, NoScript, Stylish

Operating system

Linux Mint (64-bit), 16GiB RAM, Intel® Core™ i5-3320M CPU @ 2.60GHz × 4

What steps will reproduce the problem?

1. Log in to wire account saving your session
2. Close the page and the browser
3. Open the browser again (preferably after a month of actively using wire on other devices) and open app.wire.com

What is the expected result?

Wire WebApp opens within a reasonable time (up to 10 minutes would work for me) and allows sending and receiving messages

What is the actual result?

Wire gets stuck at "decrypting messages" for tens of hours.

[ghost]

Confirmed similar issue on webapp (Firefox and Chrome) and desktop on Ubuntu 16.04 for me where about half the time the webapp hangs as decribed for long periods and the other half loads within 1-3min. The desktop app will not load at all even when left for hours. Related report here https://github.com/wireapp/wire-desktop/issues/1105

[0ki]

Could we have a numeric counter appear to loading messages when loading happens longer than 5 minutes? This might help debugging.

[gregor]

@0ki We have such a counter in our internal builds but so far have decided against putting it into the production builds as the counter is off sometimes and design wants to avoid confusing users even more. We are definitely aware of the performance issues at startup and are continuously looking into ways improving the situation.

[0ki]

I literally left the browser window active for 24 hours and it was still loading.
Are you saying you are able to reproduce this?

If so, I wish you luck pushing the fix!

[ghost]

@gregor could you make a blog post or address specifics here? This is a major issue and has been going on for at least a month and a half with no apparent resolution in sight from a user perspective. Most of my Wire converts have bailed on the service as a result of this bug.

[zx2c4]

If you release an open source native app written in something nice like Qt 5, you could avoid both: a) slow javascript crypto performance, b) poor javascript crypto security (side channels, etc), c) well-known security issues with electron.

(Writing this while I wait for messages to decrypt in my browser...)

[jocull]

Can I get any pointers into the code as to where the message decrypting happens? There's a lot to digest here, but I'd like to take a look at it if possible and see if I can't speed it up any.

[gregor]

Hi James,

sure you can.

On app start we eventually fetch and decrypt the stream of events you have missed while you were not logged in.

https://github.com/wireapp/wire-webapp/blob/dev/app/script/main/app.js#L333

All of the notifications get added to a queue which handles the events one by one. We cannot do this in parallel at least not without grouping the events by cryptographic session and handling at least those in the correct sequence.

https://github.com/wireapp/wire-webapp/blob/dev/app/script/event/EventRepository.js#L97-L135

The actual decryption is then handled https://github.com/wireapp/wire-webapp/blob/dev/app/script/cryptography/CryptographyRepository.js#L275-L315 and down the line in the cryptobox and proteus implementations.

There are two different issues with the decryption. First of all it is not the most performant to do cryptographic operations in the browser. When people see extremely long loading times though the queue does not process the events properly but is throttled by an unknown factor. There is a pause after each event decryption which we have not been able to explain.

[jocull]

@gregor Thanks so much for the direction. I wonder if the behavior you are seeing is part of new CPU throttling features browsers have implemented (especially when tabs are in the background). I had read at some point that a lot of that came about to block bitcoin miners.

[gregor]

Potentially. But we did not see any affects by the backgroundThrottling option in https://electronjs.org/docs/api/browser-window#new-browserwindowoptions. It might just be broken and being disregarded though.

But we should certainly test this with the webview changes again,

[gregor]

What is the size of your IndexedDB if loading of an account is very slow?

[0ki]

How do I see it?

[jocull]

This is how you see it in Firefox:
https://developer.mozilla.org/en-US/docs/Tools/Storage_Inspector

This is how you see it in Chrome:
https://developers.google.com/web/tools/chrome-devtools/manage-data/local-storage

[neonpixii]

I still have this issue even now. It's gotten to the point where i'd rather just revoke my laptop from my devices than wait an hour for it to decrypt the messages i sent that morning.

If y'all offered a native app that didn't suffer the long decryption times of javascript, that would probably be the best solution, and i'd use the heck out of it. The desktop electron app suffers essentially the same problem as the web app in my experience.

[iliana]

https://github.com/wireapp/wire-webapp/issues/2048#issuecomment-356257395:

There is a pause after each event decryption which we have not been able to explain.

Prior to clearing the indexed DB, I noticed that conversations with a particularly large number of messages were slower to display messages, compared to my phone (iOS).

In the most active conversation I had, I would get a notification on my phone about 6 seconds before I would get a notification on web. This time was significantly shorter for conversations with less history.

Is it possible that the unexplainable pause after each event decryption is related to the length of the conversation history stored locally?

(Fedora 27, Firefox 59, 64-bit)

[gregor]

Yes, this is definitely possible.