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

[ipfs/go-bitswap] provider performance issue #87

Open
kingwel-xie opened this issue Mar 18, 2021 · 3 comments
Open

[ipfs/go-bitswap] provider performance issue #87

kingwel-xie opened this issue Mar 18, 2021 · 3 comments
Labels
need/triage Needs initial labeling and prioritization

Comments

@kingwel-xie
Copy link

Currently the bitswap provider is responsible for announcing all content blocks to the DHT network. Also I can see there is a rate limiter which only takes 6 Cid at one time to avoid overwhelming the DHT.

Thus, I'm wondering it might be too slow to announce the content blocks. Assuming there are 1000 blocks, and it would take the provider 1000/6 = 166 rounds to process all blocks. It could be 166 minutes if each DHT providing takes 1 minutes in average.

Furthermore, I don't really get why we have to announce the content blocks? Is that not good enough if only doing for the root block? I notice there is no reprovide mechanism for content blocks, so I tend to believe it doesn't make sense to do providing for them.

Any comments?

@kingwel-xie kingwel-xie added the need/triage Needs initial labeling and prioritization label Mar 18, 2021
@welcome
Copy link

welcome bot commented Mar 18, 2021

Thank you for submitting your first issue to this repository! A maintainer will be here shortly to triage and review.
In the meantime, please double-check that you have provided all the necessary information to make this process easy! Any information that can help save additional round trips is useful! We currently aim to give initial feedback within two business days. If this does not happen, feel free to leave a comment.
Please keep an eye on how this issue will be labeled, as labels give an overview of priorities, assignments and additional actions requested by the maintainers:

  • "Priority" labels will show how urgent this is for the team.
  • "Status" labels will show if this is ready to be worked on, blocked, or in progress.
  • "Need" labels will indicate if additional input or analysis is required.

Finally, remember to use https://discuss.ipfs.io if you just need general support.

@BigLep
Copy link
Contributor

BigLep commented May 24, 2021

Next step: @aschmahmann link this to the larger content routing issue and then close this out.

@Jorropo Jorropo changed the title provider performance issue [ipfs/go-bitswap] provider performance issue Jan 27, 2023
@welcome
Copy link

welcome bot commented Jan 27, 2023

Thank you for submitting your first issue to this repository! A maintainer will be here shortly to triage and review.
In the meantime, please double-check that you have provided all the necessary information to make this process easy! Any information that can help save additional round trips is useful! We currently aim to give initial feedback within two business days. If this does not happen, feel free to leave a comment.
Please keep an eye on how this issue will be labeled, as labels give an overview of priorities, assignments and additional actions requested by the maintainers:

  • "Priority" labels will show how urgent this is for the team.
  • "Status" labels will show if this is ready to be worked on, blocked, or in progress.
  • "Need" labels will indicate if additional input or analysis is required.

Finally, remember to use https://discuss.ipfs.io if you just need general support.

@Jorropo Jorropo transferred this issue from ipfs/go-bitswap Jan 27, 2023
guseggert pushed a commit that referenced this issue Mar 15, 2023
Jorropo pushed a commit to ipfs/go-libipfs-rapide that referenced this issue Mar 23, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
need/triage Needs initial labeling and prioritization
Projects
None yet
Development

No branches or pull requests

2 participants