Slow app login

[pavloburykh]

App login has become very slow. Sometimes it is okay, but sometimes can take up to 5 seconds. Both platforms are affected.

Steps:

1. Try logging the app.
2. Perform re-logins until you face the issue.

Actual result:

We are facing login delay both after logout (re-login) and first login (when we open the app and login). Mind that login delay might have different rootcauses in case of login and re-login.

login.mp4

logs (2).zip

Additional Information

• Status version: nightly
• Operating System: Android, iOS

[Parveshdhull]

duplicate of #19992

[Parveshdhull]

or related to

[pavloburykh]

duplicate of #19992

thanks @Parveshdhull I have decided to log this issue separately and updated #19992 description.

[ilmotta]

Hi @pavloburykh. I could also reproduce this issue on Android, but only once in more than 30 full login/re-login runs. I tried to close the app as well and start from scratch a few times.

Given the low frequency of this problem and the fact that the user is still capable of logging in after waiting a few seconds, is this really a high-priority issue? cc @cammellos

[pavloburykh]

Hi @pavloburykh. I could also reproduce this issue on Android, but only once in more than 30 full login/re-login runs. I tried to close the app as well and start from scratch a few times.

Given the low frequency of this problem and the fact that the user is still capable of logging in after waiting a few seconds, is this really a high-priority issue? cc @cammellos

Hey @ilmotta! Thank you for testing the issue. Regarding frequency - we are actually facing it quite often. Maybe it depends on specific data of the account. I assume it might be related to communities/wallet accounts.

On the video below you can see me logging the user who is a member of Status community. 2 of 2 logins are very slow.

Status-debug-logs - 2024-05-16T150722.520.zip

telegram-cloud-document-2-5345893055427789349.mp4

[ilmotta]

Hi @pavloburykh. I could also reproduce this issue on Android, but only once in more than 30 full login/re-login runs. I tried to close the app as well and start from scratch a few times.
Given the low frequency of this problem and the fact that the user is still capable of logging in after waiting a few seconds, is this really a high-priority issue? cc @cammellos

Hey @ilmotta! Thank you for testing the issue. Regarding frequency - we are actually facing it quite often. Maybe it depends on specific data of the account. I assume it might be related to communities/wallet accounts.

On the video below you can see me logging the user who is a member of Status community. 2 of 2 logins are very slow.

Status-debug-logs - 2024-05-16T150722.520.zip

telegram-cloud-document-2-5345893055427789349.mp4

Great then @pavloburykh, if we can reproduce this often I think I'll try to reach the same state in the app as you in hopes of increasing the frequency and then I can try to fix.

[ilmotta]

@pavloburykh, @churik, could you share with me more details about the account you're using to reproduce this issue? I'm trying to force-logout as suggested by @churik, but even that is not causing abnormalities.

Just to confirm our suspicions, can you reproduce the issue in a fresh account, i.e. no extra data such as accounts/friends/etc?

• How many communities has the account joined?
• Which types of wallet accounts exist and how many?
• Which feature flags you have enabled?
• Any difference from the defaults in the advanced settings?

[pavloburykh]

@pavloburykh, @churik, could you share with me more details about the account you're using to reproduce this issue? I'm trying to force-logout as suggested by @churik, but even that is not causing abnormalities.

Just to confirm our suspicions, can you reproduce the issue in a fresh account, i.e. no extra data such as accounts/friends/etc?

• How many communities has the account joined?
• Which types of wallet accounts exist and how many?
• Which feature flags you have enabled?
• Any difference from the defaults in the advanced settings?

Hey @ilmotta! Let me share specific user for reproduction the bug (will send you seedphrase in DM).

This user has the following data:

1. Member of 1 community (Status community)
2. Has 1 default wallet account holding 2 Status community collectibles

The configuration of the account is default, i.e nothing has been changed in advanced settings, no feature flags have been enabled.

For reproduction on develop build:

1. Restore given user
2. Wait until Status community is restored
3. Close the app
4. Open the app
5. Login the app

[qoqobolo]

@ilmotta just tried this case (reproduced 2/2 times):

1. Created a brand new user
2. Received 0.000001 ETH on Mainnet to this user from another one
3. Closed the app (without manually logging out)
4. Opened the app

Actual result: login time increased

So to me, it looks like as soon as at least one transaction appears in the user’s activity history, this affects the login time.
Attaching logs and two videos: the first one with a login that became longer after one transaction;
and the second with a user without transaction history (completely empty)

Status-debug-logs (1).zip

1. user with one incoming tx (please pay attention to the spinner duration)

video_2024-05-17_11-04-31.mp4

2. fresh user without any activity

video_2024-05-17_11-04-56.mp4

[ilmotta]

Thanks a lot 💯 @qoqobolo and @pavloburykh! I'm going to try your reproduction steps today.

[flexsurfer]

all my local accounts for development are slow now, so I looked at it, but unfortunately, there is not much info in geth.log, so it seems like the only way is to look into status-go code and analyze what's happening there, or add more debug data, for my accounts I receive login signal in 15sec

[ilmotta]

Thanks for investigating @flexsurfer! I'm already working on this issue, and I could pinpoint a few causes, it's all related to status-go as you said and how the backend login code works until the login signal is finally emitted and the user is redirected to the home screen.

[ilmotta]

Hey @qoqobolo, @pavloburykh, @cammellos, I have a few updates deserving your attention. I'll try to give all the context that I have, but I reached a point where we will need to make a decision about the next steps.

First and foremost, I could reproduce the slow behavior on a real device Galaxy A71 and in the Android emulator.

Right after the user presses the "Login" button, status-go takes over and until it emits a signal node.login, the mobile client will appear frozen, with the button "Login" disabled. This is the expected behavior. Important to say, the status-go login process does many things that aren't necessarily mandatory to establish a session.

I focused my investigation in the case that appeared to be the worst. On Galaxy A71, logging in takes 17+ seconds with an account that has joined the Status community and nothing else (see video). Same in the emulator, but in the emulator it's ~5 seconds (still bad and we shouldn't rely anyway on emulators for this analysis). The slowdown is not random and happens 100% of the time because it's caused by the number of chats the user has. 90% of the time to login (14s+) is spent processing chats in the messenger initialization. The reason the emulator is faster is because each chat is processed in ~40ms, but in the emulator it's more like ~120ms. Okay, so we found the problem, or at least for this particular case :)

I investigated slowdowns caused by having transactions in wallet accounts, but I couldn't see any major issue. Additionally, reading the login source code doesn't show any part that blocks node.login from being emitted due to wallet transactions or having collectibles. I understand this contradicts the evidence. Please, keep reading :)

1. Speaking of solutions now. I then attempted to entirely remove chat processing from login in status-go so that the login signal could arrive as fast as possible to the client. I just wanted to see how fast we could go theoretically. See video here, login is now always fast as if the user had just created an empty account. And the user can still use the community and chats (more about this below). This solution is not a valid one yet, because I just removed the slow code, but what it does is still important.

2. The other solution I tried, which can be promoted to a quick fix in status-go, is that community instances were being cached incorrectly in a map because the map was being reconstructed within the chat loop. This fix makes login around 40% faster and saves ~7 seconds from the Galaxy A71.

3. I timeboxed a solution where only one call to communitiesManager.GetByID was done per community. This is the main cause of the slowdown according to profiling. I tried to fully cache the community and pass it downstream as an argument, but this solution is risky because the community is mutated on every iteration of chats (specifically within initChatFirstMessageTimestamp > communitiesManager.EditChatFirstMessageTimestamp). So I abandoned this idea, but this can theoretically be done.

4. The ideal solution to me is to actually take away chat processing as much as possible from the login. That way, right after status-go emits node.login the client can immediately redirect the user to the home screen as usual, and then the client can request status-go to process chats in the background. It would still be desirable to optimize the internal processing of chats, but there's only so much we can do. With this solution, users will login with 0, 1, or 1k community chats just as fast. The tradeoff with this solution is that the user might see stale data until all chats are processed (couldn't verify this in practice, but better be careful and there might be other side-effects of this solution I'm not aware of).

---

Edit: We aligned the following steps in a call:

1. Implement solution 2 because it's quite cheap and ask QAs to see if or how much it helps. In my tests it's always around 40% less.
2. Implement solution 4, i.e. remove chat processing from the messenger initialization. Create a "dirty" (lower quality) build for mobile so that QAs can check if users can successfully login without delays. If this works well, then we know it's worth implementing up to our code standards.