Set ConnectionStrategy.ClosestFirst for initialization chronik-client will start asynchronously and others will wait.
Details
Details
- Reviewers
Fabien bytesofman - Group Reviewers
Restricted Owners Package (Owns No Changed Paths) Restricted Project - Commits
- rABC973fbe8030ca: [Cashtab] Set ConnectionStrategy.ClosestFirst for initialization
npm test and test it manually in the local demo
Diff Detail
Diff Detail
- Repository
- rABC Bitcoin ABC
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
Comment Actions
Build Bitcoin ABC Diffs / Diff Testing (preview-cashtab) passed.
Preview is available at http://51.89.41.69:41339 for the next 60 minutes.
| cashtab/src/index.tsx | ||
|---|---|---|
| 40 ↗ | (On Diff #53828) | Client initialization errors are material enough to be rendered for the user in the frontend rather than a silent console msg. |
| cashtab/src/index.tsx | ||
|---|---|---|
| 40 ↗ | (On Diff #53828) | gm. the console of initialization failure here is my "imagination" because with the current node selection strategy, the worst case scenario is failure after 1000ms, followed by using the default order. So the worst case is consistent with the "original" method. Therefore, the "initialization" failure here might be redundant, or there should be a better description. |
Comment Actions
at the moment this is not worth implementing in cashtab
it guarantees a ~600ms delay on all startups in exchange for ... potentially faster websocket times.
i have never felt the websocket in cashtab was too slow. from the user perspective there is no noticeable difference in the server response times. but extra startup time is an issue.
ideally cashtab bootup would have no locktime, we should just load from storage and sync in the background. imo it's more important to get that right than to roll out this kind of optimization, which is solving a problem that (at the moment) does not exist.
If we were dealing with the top chronik server constantly going down, the optimized local connection here might be worth it. But we're not.
so, it doesn't make sense to do this before the app loads instantly with no locktime. this is esp annoying when opening txs with the extension.
Comment Actions
My view is that this approach is worthwhile.
Although the asynchronous task itself takes 600ms, it does not block the main loading process, so its impact on the overall load time is minimal. The main benefit is that every subsequent request after loading becomes faster—each request gains a few milliseconds in speed. The more requests there are, the greater the cumulative benefit. For example, a URL that responds in 50ms instead of 300ms will save 2,500ms over 10 requests. Based on my actual experience, this makes interactions noticeably smoother. Of course, it would be even better if this optimization didn’t require the initial 600ms cost, but avoiding that would necessarily conflict with the principle of “not switching nodes,” since adhering to that principle inherently requires some initialization time.
Do you have any better suggestions on how to move forward with this diff, or should we consider close it for now?
Comment Actions
I tried shortening the timeout to 500ms and performed some tests. I found that the selection strategy doesn't slow down the user's startup experience; instead, it might make it faster. The user's actual complete loading occurs when the "loading" state disappears, which is loadCashtabState in useWallet.ts. Through adding a timer for simple testing, taking my Hong Kong IP as an example, useWallet.ts:969 shows Cashtab startup duration: 2583ms. This is the time actually perceived by users. However, when using the "selection strategy" and changing the timeout from 1000ms to 500ms, the test result is 620ms for Cashtab startup duration. Therefore, finding a faster node within 500ms and establishing a connection is often faster than choosing a default one. Furthermore, this 500ms could potentially be adjusted to 400ms or 300ms, meaning "if we can't find a faster node within 300-400ms, it doesn't matter anymore." WebSocket connection establishment speed is 2-3 times that of ping, and it's easy to prove through testing that lower WebSocket latency means lower query latency.
Comment Actions
My main objection here
- imo startup time delay is readily noticeable, it happens every time for 100% of users, no matter what they are trying to do. Particularly this is an issue for users that just want to open the extension to complete a tx
- optimized server selection is not readily noticeable, it's an issue, but really only for users getting into agora
So, I think 1 should be fixed before 2.
This tho does improve things and prob doesn't make 1 noticeably worse, so let's go ahead and get it in.