The rule seems to be to create one worker per core, and then come up with some load-balancing algorithm for distributing routers. This is what I’ve see in all the example code, and the scalability docs.
This makes sense to me if you plan on maxing out each worker, like you might do in a one-to-many, live streaming setup.
But in a multi-party conference room setup, you might have many routers with various different and fluctuating loads. The flexibility to schedule them on any core would be advantageous. Limiting workers to the number of cores might unnecessarily
couple routers together.
In an ideal scenario, I would create a new worker for every new router. In that scenario, I wouldn’t load balance anything and just let the kernel sort it out. Or maybe I would cap workers at CPU cores x 2 or some reasonable constant.
Is anyone running a configuration like this? Thanks!
It’s a good rule, and yes routing is what makes this a true beast.
It makes sense in both a one-to-many and many-to-many perspective. This comes down to your design.
I use single-core machines and each machine either gets a producer server or consumer server. The servers only get one router/worker and the chat-server or broker-server will make the decisions. So if I need to get a broadcast from producer #20 and send it to consumer #10 because consumer #2 is full, no issues and it makes it to the right user. This setup too will utilize 100% of the performance unless you strictly dedicate the resources to a room instead of pooling.
If I run on a 4 core machine, I will run 4 consumer servers or 3 of them and 1 producer server (or sort what I need).
I’d never favor a worker out competing another, but that’s my two cents. In testing do what you want you feel? But production I run about 50 servers and growing it’d not make sense to do this at all; imagine a worker failed do you shut all workers down? Do you assume the error wasn’t big?
To me managing 50 servers is a lot, if I had to do that + manage all this worker activity ouuuwwwie… Cheers!
