Performance Question about rebus HOT 3 CLOSED

Is this perhaps something thats only relevent when running InMemory and gets replaced when for example using ServiceBus perhaps? (If so, then it's much less of a concern - I am seeing this class in local testing with an InMemory setup currently)

from rebus.

This design came from back when Rebus was originally built, and back then it used MSMQ, which did not have an asynchronous receive API that was easy to work with.

Rebus simply starts a number of dedicated "worker threads" (default: 1), which it will then use to begin the receive operation. How many receive operations will then be determined by the "max parallelism" (default: 5), and if the transport supports truly async Task-based receive, then message dispatch will continue on the thread pool.

TBH I've never tried to dive into the performance characteristics of this design beyond from a usage perspective, where it just seems that Rebus does not consume much memory, does not consume much CPU when running idle, seems to have a low latency when receiving messages, and seems to be well-behaved towards other things running in the same process and/or on the same machine.

If this is something that interests you, please feel free to tear it apart, if you can 😉

Oh, and please note: If it wasn't entirely clear, the "worker threads" are DEDICATED worker threads, which Rebus creates, and so it doesn't affect .NET's thread pool or anything else. And the threads are created when Rebus starts, and they're stopped again when Rebus shuts down, so once they're there, they will stay there until Rebus stops.

from rebus.

I found the docs saying that a TPL based approach is also provided and I think this makes a great deal of sense for transports that do support async receive, and it simplifies the concurrency setting by taking an option away :-)

https://github.com/rebus-org/Rebus/wiki/Workers-and-parallelism#tpl-based-workers

from rebus.