Measure DHT Resource Consumption
iand opened this issue · comments
ETA: 2023-08-31
Description: Currently when the Bitswap ProviderSearchDelay is set to 0, the Time To First Byte is worse than when the ProviderSearchDelay is set to 1 second, which doesn’t make sense from a protocol perspective. When the ProviderSearchDelay is set to 0, all requests go through the DHT (compared with only 5% when the ProviderSearchDelay is set to 1 second). One theory that could explain these strange results, is that the DHT implementation is slowing down Kubo.
We need to investigate around parallel requests in the DHT, and try to understand any resource limitation that the implementation may have. The DHT is much less chatty than Bitswap, hence there must be a way to have a more efficient use of resources (even tough the DHT opens more new connections than Bitswap).
Upon completion
Once we are satisfied with the DHT performances, we can set the Bitswap ProviderSearchDelay to 0 (unless we encounter new problems). This is a good step to get rid of Bitswap dumb broadcast!