Currently, the conferences will become quite unstable if we have more than 100 subscriptions. This happens since each conference has its own goroutine (or thread) which handles all events happening in the session, including handling of RTP packets received from the publishers and writing them to the subscribers. Essentially, this means that the main conference loop handles potentially [short] CPU-bound operations that at a certain point (when there are more than 100 down tracks / 100 subscriptions) start to lag behind due to this thing scaling linearly to the number of subscriptions. This means that if we have a machine with multiple cores, the SFU will scale horizontally well (each conference has its own goroutine), but not much vertically.
Since writing packets to tracks is an expensive thing by itself, we must utilize a more efficient work-stealing thread pool (a pool of workers to be more precise) to parallelize the handling of packets for independent subscriptions.
Currently, the conferences will become quite unstable if we have more than 100 subscriptions. This happens since each conference has its own goroutine (or thread) which handles all events happening in the session, including handling of RTP packets received from the publishers and writing them to the subscribers. Essentially, this means that the main conference loop handles potentially [short] CPU-bound operations that at a certain point (when there are more than 100 down tracks / 100 subscriptions) start to lag behind due to this thing scaling linearly to the number of subscriptions. This means that if we have a machine with multiple cores, the SFU will scale horizontally well (each conference has its own goroutine), but not much vertically.
Since writing packets to tracks is an expensive thing by itself, we must utilize a more efficient work-stealing thread pool (a pool of workers to be more precise) to parallelize the handling of packets for independent subscriptions.
Related articles: