Playlist: improve `claim_search` calls at bootup? #6241

New issue

Open

opened 2021-06-15 10:06:24 +02:00 by infinite-persistence · 2 comments

infinite-persistence commented

2021-06-15 10:06:24 +02:00

(Migrated from github.com)

In addition to homepage categories making lots of claim_search calls (lazy-loading coming soon), playlists now calls them too. If you have lots of playlists with lots of items each, the network load seems huge. Given that we don't need them immediately (I think), can we postpone the call?

11s for a claim_search to load the categories is bad (not sure if it's just today's network hiccup, or due to too many calls, though).

In addition to homepage categories making lots of `claim_search` calls (lazy-loading coming soon), playlists now calls them too. If you have lots of playlists with lots of items each, the network load seems huge. Given that we don't need them immediately (I think), can we postpone the call? 11s for a `claim_search` to load the categories is bad (not sure if it's just today's network hiccup, or due to too many calls, though). <img src="https://user-images.githubusercontent.com/64950861/122015288-8f9ad200-cdf2-11eb-856b-93ccf6b6ac6c.png" width="300">

tzarebczan commented

2021-06-15 17:13:09 +02:00

(Migrated from github.com)

I think that's related to your network / location in relation to the apis in the US. Hoping we can improve that soon.

Spoke with Jessop briefly and would require some redesign to make this work. Right now only non-published playlists are re-hydrated from the wallet data. At all times we need to know if something is in a playlist so the state reflects that.

I think that's related to your network / location in relation to the apis in the US. Hoping we can improve that soon. Spoke with Jessop briefly and would require some redesign to make this work. Right now only non-published playlists are re-hydrated from the wallet data. At all times we need to know if something is in a playlist so the state reflects that.

infinite-persistence commented

2021-08-03 10:41:34 +02:00

(Migrated from github.com)

On top of potentially stalling the important claim_searches for the homepages, it impacts the "Total Blocking Time" score for the amount of work that it does. Also, it feels odd to load this much data for Embeds (when I have a logged in session).

Without knowing the full constraints, and probably already covered by the "redesign" remark above, here are some random suggestions:

We are currently setting collection_list to resolve only 1 claim. ,It looks like it can resolve all claims for all published collections. Can save some overhead in creating connections and doing the manual batching of promises?
Delay all of this until few seconds after bootup?
- Judging from how the code only blocks the GUI until user/me is done, it doesn't seem like anything else is critical, so most likely we can delay this without significant impact.

On top of potentially stalling the important `claim_search`es for the homepages, it impacts the "Total Blocking Time" score for the amount of work that it does. Also, it feels odd to load this much data for Embeds (when I have a logged in session). Without knowing the full constraints, and probably already covered by the "redesign" remark above, here are some random suggestions: - We are currently setting `collection_list` to resolve only 1 claim. ,It looks like it can resolve all claims for all published collections. Can save some overhead in creating connections and doing the manual batching of promises? - Delay all of this until few seconds after bootup? - Judging from how the code only blocks the GUI until `user/me` is done, it doesn't seem like anything else is critical, so most likely we can delay this without significant impact.