Providing from bitswap slows down the gateways over time.

[Stebalien]

We currently send out provider records whenever we fetch a block from bitswap. Unfortunately, when under constant load, our provider record queue can back up quite a bit. This:

1. Slowly (over weeks) eats up gigabytes of memory.
2. Blocks up the dialer queue. This ends up making it really hard to actually fetch content via the gateway because the gateway is busy working through a massive queue of DHT requests.

---

Proposed solution: In addition to all the provider record work being done in #5774, we should consider adding an option to simply disable provider records (at least for files fetched via the gateway).

[michaelavila]

@Stebalien is the proposal to allow the daemon to run in such a way that provider records are not created/announced specifically when fetching? Does that mean we want to continue to create/announce provider records when doing add like things in that daemon?

[Stebalien]

That's my thinking but I haven't thought through it fully. This would also be fixed by:

1. Having an option to turn off providing globally.
2. Obeying reprovider strategies on provide as well and configuring the gateway with a "pin-only" provider strategy.
3. Reducing the number of blocks we end up providing and making providing "lazy" (that is, write down somewhere, e.g. in a database, that we want to provide some block and then work through the provider backlog as a background idle task).

(in order of increasing complexity)

---

Really, I just filed this issue to track the issue (so we can keep track of what's currently killing our gateways 😞).

[michaelavila]

Understood. It's closely related to what I'm doing so I want to at least have it in mind. Thanks.

[Stebalien]

This has been fixed. We still have the large queue but it's manageable and we've reduced the number of workers.