Skip to content
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

Enable fast (pipelined) synchronization in TypeScript client #30

Closed
KtorZ opened this issue Apr 22, 2021 · 1 comment · Fixed by #37
Closed

Enable fast (pipelined) synchronization in TypeScript client #30

KtorZ opened this issue Apr 22, 2021 · 1 comment · Fixed by #37
Assignees

Comments

@KtorZ
Copy link
Member

KtorZ commented Apr 22, 2021

Describe your idea, in simple words.

We could have a 'startSync' / 'stopSync' functions which would use requestNext & findIntersect under the hood to run a fast asynchronous synchronization.

Why is it a good idea?

The thing is (and I should document that better in the user-manual for it's only barely mentioned in a note) that consuming the entire chain using non-pipelined request is slow (about ~3h for the whole chain). But, Ogmios and WebSocket supports pipelining (up to a certain level) to make this much better.

So, typically when syncing a large number of blocks, one would want to make sure to always have some messages in flights. I haven't really tested much what's the best settings are, mostly because it also depends on the underlying connection and network latency. But as a rule of thumb, starting with a burst of requestNext and then, yielding a new requestNext on each event makes better use of the network bandwidth (bringing a full sync down to ~15 minutes).

There's some example of that in the chain-sync smoke tests in vanilla-js: https://github.com/KtorZ/cardano-ogmios/blob/master/server/static/tests/chain-sync.js#L82-L93

Are you willing to work on it yourself?

👍

@rhyslbw
Copy link
Member

rhyslbw commented Apr 23, 2021

Understood. I can work on this in a follow-up PR.

@rhyslbw rhyslbw self-assigned this Apr 23, 2021
rhyslbw added a commit that referenced this issue May 4, 2021
Closes #30

Adds a function to handle the sync setup, including request pipelining
to optimize performance. The default is 1000 requests, but it's a configurable
argument. The `ChainSyncClient` no longer exposes findIntersect, and the awkward
'initialIntersection' logic removed.
rhyslbw added a commit that referenced this issue May 4, 2021
Closes #30

Adds a function to handle the sync setup, including request pipelining
to optimize performance. The default is 1000 requests, but it's a configurable
argument. The `ChainSyncClient` no longer exposes `findIntersect`, and the awkward
'initial intersection' logic removed.
@rhyslbw rhyslbw linked a pull request May 4, 2021 that will close this issue
3 tasks
rhyslbw added a commit that referenced this issue May 5, 2021
Closes #30

Adds a function to handle the sync setup, including request pipelining
to optimize performance. The default is 100 requests, but it's a configurable
argument. The `ChainSyncClient` no longer exposes `findIntersect`, and the awkward
'initial intersection' logic removed.
rhyslbw added a commit that referenced this issue May 5, 2021
Closes #30

Adds a function to handle the sync setup, including request pipelining
to optimize performance. The default is 100 requests, but it's a configurable
argument. The `ChainSyncClient` no longer exposes `findIntersect`, and the awkward
'initial intersection' logic removed.
rhyslbw added a commit that referenced this issue May 5, 2021
Closes #30

Adds a function to handle the sync setup, including request pipelining
to optimize performance. The default is 100 requests, but it's a configurable
argument. The `ChainSyncClient` no longer exposes `findIntersect`, and the awkward
'initial intersection' logic removed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants