Pools page, bring blocking queries earlier

[ValarDragon]

On the pools page, I see the following two queries taking a long time (180-200ms), and appear to be blocking more queries that are required for page stability.

Slow queries:

• ICNS query ( https://lcd.app.osmosis.zone/cosmwasm/wasm/v1/contract/osmo1xk0s8xgktn9x5vwcgtjdxqzadg88fgn33p8u9cnpdxwemvxscvast52cdd/smart )
• Balancer lockup query ( https://lcd.app.osmosis.zone/osmosis/lockup/v1beta1/account_locked_longer_duration )

These queries come after other queries on this page such as:

• epochs query
• Get osmo price
• get market pools ?

These slow queries block the following (much slower) queries, however there is no dependence and they should be parallelized:

• get user pools (https://app.osmosis.zone/api/edge-trpc-pools/pools.getUserPools ) -- 750ms
• get user positions (https://lcd.app.osmosis.zone/osmosis/concentratedliquidity/v1beta1/positions/{USER_ADDRESS}?pagination.limit=10000 ) -- 180ms
• The following 850ms query that I don't understand: https://app.osmosis.zone/api/edge-trpc-assets/assets.getUserMarketAsset,assets.getAssetHistoricalPrice,assets.getUserAsset?batch=1 -- (850ms) on input:
  • {"0":{"json":{"findMinDenomOrSymbol":"OSMO"}},"1":{"json":{"coinDenom":"OSMO","timeFrame":"1D"}},"2":{"json":{"findMinDenomOrSymbol":"OSMO","userOsmoAddress":"{USER_ADDRESS}"}}}

[jonator]

WDYM by blocking? The queries are dependent on the mounting of the component tree, which may have some serial properties but I'm not quite sure how the guts of the React engine layout the tree initially. Further, a pitfall of building a dapp is often you need to wait to get the user address from the wallet (which may be blocked on installing wallet client code) which often triggers a flurry of blocked queries once we get that address. In web2, we can normally get that user identifier on the initial query from a browser cookie. Perhaps that's what you're seeing? I'm spitballing and any other input would be appreciated here.

For expensive queries, we tell tRPC not to batch them with other tRPC queries (like you see with the last query, assets.getUserMarketAsset,assets.getAssetHistoricalPrice,assets.getUserAsset). So, expensive queries operate independently and should not be blocked or block any other queries.

The "idea" with batching is it justifies small cheap tRPC queries by automatically combining them at runtime and reducing total networking overhead. But, I'm not sure the observed performance benefits are there. I'd like to verify that it runs the batch in parallel in the server as well, it should. But, it could just be the multi region & edge problem.

[MaxMillington]

@jonator @Amosel was this solved at the offsite? If so, can we close?

[jonator]

We only made improvements to user positions. The user pools query will likely need to be moved to SQS to be optimized enough