-
Notifications
You must be signed in to change notification settings - Fork 984
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
Message history loading takes up to 20 sec #21456
Comments
Not sure if "wallet_fetchTokenDetails", "wallet_getWalletToken", "wallet_fetchPrices", and "wallet_fetchMarketValues" will affect the delay? Each of them took up around 6 seconds in the requests.log provided by @mariia-skrypnyk . And |
The following is the requests.log provided by @pavloburykh .
|
emm.. after investigating |
emm.. Status.log:
requests.log:
Look at the time. I would expect |
to be clear, I made a short simplified log for requests.log:
|
@qfrank, I can have a look yes, but at the moment, just looking at the code I don't see how the client could be the culprit of the delay.
I'll verify what's going on and share here 👍🏼 |
@qfrank I double-checked the code again and I'm sure now the reason for the 5-6s delay is caused by the status-go layer. When a signal This is exactly what I expected from this issue, no? The problem is not really about the message history or how many messages are sent, it's about the time to initialize the messenger. The same root cause of issue #20173. On the client side we already eliminated the freeze to load large communities in #20164. I think all there's left to do is see if we can optimize Alternative solutionIn case we get stuck and can't optimize the Go code, we could initialize filters in steps (as separate goroutines) and send signals to the client as the processing progresses. For example, community chats could be a separate part of the filter initialization, but the part initializing chats from the DB could finish earlier and be processed concurrently. Or another example, the filters for pub keys from contacts could be initialized separately. This would be a mitigation solution so that users of large communities can see other important data in the app before community filters are established. We could also consider processing communities concurrently to establish community filters (this could alleviate the problem for one of Status' users who is waiting for minutes and is part of multiple communities). The downside is in terms of complexity on the client to process the messenger initialization using multiple signals, but the upside for the user could be a reduction in perceived latency to load data in the app. |
Thank you for the investigation! But how can we explain the timestamp 🤔
then frontend received maybe we can draft a PR and add some log in frontend to see what the actual time when it start invoking |
This solution we definitely could try, but currently you can see that |
Doesn't hurt to ask, but are we sure the duration is calculated correctly? You can try to comment out the line that calls I see the response from
:js-response true to the place calling wakuext_startMessenger because otherwise the effect :json-rpc/call will automatically transform the response as CLJS data, but we don't need that.
Edit: adding
|
Bug Report
Follow up of #21411
In this 👆 PR perfomance issue with message loading was already improved but seems that there is a way to make it more faster.
Reproduction
Expected behavior
Message history loading takes less then 20 sec
Actual behavior
Message history loading takes up to 20 sec
Receiver_1.zip
Sender_1.zip
Additional Information
The text was updated successfully, but these errors were encountered: