I am developing a 1- N broadcasting architecture with mediasoap, here are my questions:
If 1 router can handle 500 consumers (max), can I have 16 routers within same worker to handle my 8000+ consumers
The article on scalability suggests I open 1 worker & 1 router per consumer and pipe streams to the routers in their respective workers, meaning I will have 17 workers & 17 routers and 500 consumers goes to 1 router each and the producer takes its own as well
Pls I need advicse on what to do based on my taught process(1&2) above
I wouldn’t think so, once you exceed the core capability with the broadcasts you will need to further pipe them to other servers/cores. So to sum you won’t get 500 per core, you’ll probably have to assume less and designate weights so you don’t overwhelm things.
A user is expected to be piped to more than one server for fanning to viewers; it all depends but sort that logic.
Let’s go about requirements, I run many 4vCore @8GB RAM and all I can say is a machine at 60% overall usage isn’t using more than 2GB ram. Requirements can be quite low, as for the storage I use just OS and the service requirements which is a few GB’s.
Most processors run same instructions/speeds/etc these days so little difference but let’s sum this fast, the single broadcasts on a single worker (core) could be over consumed and take more than the worker and resolve adding latency and other defects to the real-time situation.
You would need to ensure that you understand what usage may be, weight it and set limits so like if you know you need to fan to other servers for viewers they can provide properly.
So to be easy on you, let’s say you set a single core to 15 broadcasts and you assume they will be piped 2-10 times, the core/server that consumes them will transmit to viewers and you’ll make sure not too many are over using the viewer server.
YOUR GOAL IS VERY POSSIBLE, I would say though have atleast 2Gbp/s network up/down; possibly better.
Do take my above specs as a real-time usage case, I don’t perform HLS or any recording, it’s live and not logs.
I think with the piping effort, implement HLS and some CDN. If you want real-time, it’ll cost CPU ten-folds serving hundreds-> thousands. If you can sacrifice some seconds for viewers you can HLS; I would suggest HLS for large audience like settings with some real-time; with that said you should weigh your usage and make sure you can do what it is you need, you may need to pipe a stream to many servers to be made into an HLS format for 10-50->100K viewers you design how crazy it gets just do good testing.
But if you need all real-time, sub-second latency; you will want to mix my above comment with some some transports for some sessions to consume otherwise have all viewers view a HLS-Playlist file/etc.
Yeah so get good with setting limits and auditing a server so that you can allow a user to broadcast with video and/or audio to be piped to many servers/cores where a user can view them.
Let’s be insane with it now, let’s say 1 broadcast used up an entire core fanning to viewer servers, we would need additional servers/cores to serve their stream out. It get complexed but if you can figure out all of that you should be fine. 1,000 viewers may be tough depending!
–
It’s quite a bit of work something doable but not easy.