feat(multiplexer): Use single channel for muxer #133
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The muxer loop uses a lock-free spin to iterate over available ingress channels to select the next payload to be muxed. This is not very efficient since we end up performing a lot of wasted cycles, even when using some backoff mechanism (such as the
snooze
function in the crossbeam crate).This PR resolves the problem by relying on a single ingress channel, which provides a blocking mechanism using OS-primitives. This removes the need for a loop altogether. After some initial testing, we see that an example chainsync process against a local node maintains the same throughput (~1.5k blocks / sec) while drastically reducing the amount of required CPU (<4%).
The downside (?) is that now the muxer messages will processed in a FIFO fashion, instead of the randomized approach used in the actual implementation. This seems like a valid trade-off, possible even better for certain use-cases.