brave
September 8, 2024, 11:19am
1
Hi guys. We are trying to use threads feature in VR and the main challenge here is to know how many of them to use, since of cause they are not working for free, and use a lot of CPU.
So, my question is, are they shared between all publishers? Randomly? Fifo? If publisher published only audio, did he get his thread, or is it only for video publishers? If publisher joins without streams, and will start media publishing later, did he get his thread, or only publishers with media gets threads? Thanks.
lorenzo
September 9, 2024, 8:50am
2
The last comment of the original PR answers your questions:
meetecho:master â meetecho:videoroom-helper-threads
opened 03:02PM - 15 Sep 22 UTC
This patch adds support for the so-called "helper threads" to the VideoRoom. If ⌠you're familiar with the Streaming plugin, in that context helper threads allow mountpoints to leverage some threads to distribute the incoming RTP packets to the indended audience, rather than take care of the process in the same thread that receives the packets themselves: that feature was added a few years back in #1316, and helped the Streaming plugin greatly increase performance in the presence of a lot of subscribers.
The VideoRoom plugin, instead, never got the same treatment: as such, there's always been a critical path when handling incoming media packets from a publisher to relay to subscribers. More precisely, this was the path:
1. the publisher's ICE handle loop receives a packet, in `janus_ice_cb_nice_recv`;
2. from there, `incoming_rtp` is called on the VideoRoom plugin for that publisher;
3. that function, among other things, iterates on all subscribers to perform a `relay_rtp` of the packet for each of them;
4. for each subscriber, `relay_rtp` queues the packet for delivery in the Janus core.
All four steps happen within the context of the same thread (the one handling publisher's core loop). In case the publisher has too many subscribers, that sequence may take longer than it takes for the following packets to arrive, causing the thread to struggle. This was exactly the main cause of bottlenecks in the Streaming plugin, which led us to add helper threads: the moment helper threads are added, the only entities `incoming_rtp` must pass packets to are the helpers themselves, which will then take care of steps 3. and 4. on their own. As a consequence, the publisher's loop is never kept busy, and can keep on processing incoming packets in a timely way.
As it did for the Streaming plugin, this patch is supposed to increase the performance of the VideoRoom plugin in case a single publisher has a lot of subscribers. Notice that this doesn't magically allow infinite subscribers for a publishers: it just makes the process more efficient, allowing to better use the available CPU resources; leveraging multiple Janus servers (e.g., via #3014) is still needed in case you want to increase an audience beyond the capabilities of a single machine.
In this first iteration, I kept the configuration very simple: if you add a `threads: <number>` property when creating a room, then all publishers that connect to the room will automatically spawn that number of threads. This happens the moment a publisher joins, not when they publish, and they stay there until the publisher handle is closed: this means it's probably suboptimal as it is, because if you take into account users that will only subscribe, if they create a publisher handle to receive signalling events (as they should) helper threads will be created for them too, needlessly. I'll probably revisit this later on, before or after this is merged (possibly allowing only for specific publishers to have threads, e.g., those that will actually need them), but for the time being that's good enough to experiment with this feature.
I tested this briefly and it seems to be doing its job, but I haven't really stressed it out. I don't plan to merge really soon, so in case you're interested in increasing the performance of the VideoRoom because you'll have many users receiving media, please do take the time to test this and report problems.
1 Like
brave
September 9, 2024, 1:39pm
3
Sorry, Lorenzo, itâs still not perfectly clear for me. Maybe we can do some exercise?
If I have 5 publishers in room, every publisher subscribes everyone, so, I have 5 * 4 = 20 subscribers, and I set up 5 helper threads, who gets it? Helper threads âhelpsâ subscribers, right? So do I understand correctly, that 5 subscribers does get threads, and other 15 doesnât?
lorenzo
September 9, 2024, 1:42pm
4
No. The same helper thread will serve more subscribers. Thatâs exactly how it works in the Streaming plugin too.
1 Like