New pull request: Streaming plugin and helper threads

[Lorenzo Miniero]

Hi all,

I just submitted a new pull request here:

https://github.com/meetecho/janus-gateway/pull/1316

As explained in more detail in the description, this is an attempt to increase the performance for RTP mountpoints in the Streaming plugins with a large audience (hundreds of viewers). It assumes you're already using a patched libnice (https://gitlab.freedesktop.org/libnice/libnice/merge_requests/12) or our experimental Jice stack (https://github.com/meetecho/janus-gateway/pull/1297) in order to overcome the stock libnice bottleneck, which would hinder performance before the point this patch can help.

In case you're indeed using the Streaming plugin in such a context, please test and help us merge this soon!
Lorenzo

[chen chen]

Hi,

  Have you considered to implement Janus as a single thread (at least, the streamings are in one thread). I think asynchronous IO (using libuv, libev, libevent, epoll, kqueue, IOCP, etc...) should be a good way to lower the CPU usage, any way streaming servers are IO-intensive programs, switching thread is very expensive.

  And it is hard for me (I think it is hard for most people) to manage objects' life cycle under a multithread environment.

Regards

[Lorenzo Miniero]

No, Janus will never be single thread. We're working to reduce the number of threads (and did a lot there already), but that's it.

Lorenzo

PS: the pull request this post references has been merged in the meanwhile.

[chen chen]

Thank you for your quick reply.

I am not sure if I am reckless, but, may I know your reason to choose multi-thread?

在 2018年9月6日星期四 UTC+8下午9:24:57，Lorenzo Miniero写道：

[Lorenzo Miniero]

While we prefer using single-thread for stuff like signalling (the recent changes, and the current PR for turning the HTTP plugin to single thread, are proof of that), we don't like the same approach for media. It's definitely helpful in some scenarios, and if fact we might work on aggregating threads for media to serve multiple users, but some performance and stress tests we carried on lately highlighted how a single thread is not satisfactory at all for some use cases. The helper threads in the Streaming plugin are a perfect example: we had a single thread receiving media for a mountpoint, and it failed to serve media when numbers increased. A single thread will typically only take advantage of a single CPU core, which means it will severely underperform in multicore environments. Anyway, I agree that too many threads can cause different issues, like the switching you mentioned: this is why we've worked so hard in reducing the number of threads recently; as a relevant example, just a few months ago we had three threads per participant (incoming media, outgoing media, SCTP), and now it's just one per participant, meaning we were able to remove a ton of locks from the code.

Lorenzo

[chen chen]

I see...

My goal is to build a server cluster based on Janus, because we can't serve all our customers with only one serve. We have more than 40,000 media streams , IPC is absolutely required, so single thread is fine for us, we just start more processes and they will communicate with each other if necessary.

Indeed in single point server situation, writing all logic in a single thread may cause lacking of CPU resource. As a compromice, I suggest that we can start a fixed number (may be the number of CPU cores) of threads, these threads are used to balance the load of receiving and relaying RTP packets, we don't need to start a thread for every RTP link, I guess this should save much CPU resources when increasing the number of media streams.

Regards.

在 2018年9月7日星期五 UTC+8下午5:27:17，Lorenzo Miniero写道：

[Lorenzo Miniero]

Il giorno venerdì 7 settembre 2018 13:17:00 UTC+2, chen chen ha scritto:

I suggest that we can start a fixed number (may be the number of CPU cores) of threads, these threads are used to balance the load of receiving and relaying RTP packets, we don't need to start a thread for every RTP link, I guess this should save much CPU resources when increasing the number of media streams.

This is what I meant by our idea of aggregating threads for media. Since media traffic for each user now lives in an event loop (the glib GMainLoop, which allowed us to do a single thread per user), it should be doable to host multiple loops on a limited number of threads instead, possibly configurable at startup (so that one can decide if it should be one thread per user, or 4 threads in total for instance). Anyway, this is not a high priority for us at the moment, so unless someone decides to sponsor the development of the functionality, I don't know when we'd be able to work on that.

Lorenzo

[chen chen]

Thanks, I got it. Sorry for my misunderstanding before.