[Freeswitch-users] Question about large confeerence

[Duvid Rottenberg]

I believe the main bottleneck of mod_conference is on the input thread.

Regardless of which approach you take, you still need CPU capacity to push
out the audio to all listeners. I don't think that mod_conference is any
less efficient than any other module is at doing that.

On Mon, Apr 23, 2018 at 10:46 AM, Abaci B <abaci64 at gmail.com> wrote:

> Agree that mod_conference should probably be optimized to only loop
> unmuted members, but that only applies to the input thread the thread
> handling the output still needs to exist for everybody (except maybe for
> deaf members) but it would still be a savings since right now each
> conference member uses at least 3 threads if i understand correctly (1 for
> the channel, 1 for the input and another one for the output).
> the most optimal solution would probably be to either use shoutcast to
> stream for conferences where the latency isn't critical, and develop a
> streaming option for conferences, maybe something like
> conference_stream://conf_name that would be like local_stream and not like
> additional conference members with high overhead. I hope to 1 day either
> develop or sponsor development of such a feature, if there are others
> interested in the same functionality we maybe able to sponsor it together,
> I would offer $500 as a starter.
>
> On Mon, Apr 23, 2018 at 10:28 AM, Duvid Rottenberg <adrottenberg at gmail.com
> > wrote:
>
>> I have a similar scenario, and my solution was to create several
>> conferences. I have one master conference, that serves to connect all
>> sub-conferences. So when a user calls in to the conference I add him to a
>> sub conference, then I do an outdial to an extension that joins the sub
>> conference to the master conference (this connection should not be muted).
>> Once the sub conference has 250 participants, I create a new sub
>> conference. I control all of this via ESL, this also requires some
>> additional logic to handle conference commands, as I need to make sure it
>> propogates to all sub conferences.
>>
>> The advantage of this approach is that instead of having one loop running
>> on 1 CPU core looping through all listeners we now have multiple conference
>> loops running on different cores. The issue with large conferences is that
>> the conference loop runs every 20 ms by default and the main conference
>> loop is not (and probably can't be) multi-threaded.
>>
>> Since on any large conference, there will most likely be only a handful
>> of speakers, the best solution would probably be to optimize mod_conference
>> to have a separate list of unmuted participants and only loop through
>> those, but I was afraid to undertake such a change myself.
>>
>>
>>
>> On Thu, Apr 19, 2018 at 12:09 PM, Abaci B <abaci64 at gmail.com> wrote:
>>
>>> Hi,
>>> I'm trying to set up a large audio conference of over 1000 users where
>>> only 1 or 2 users are talking and the rest are just listening, but after
>>> 600-700 users the CPU usage gets too high and the audio gets choppy, I
>>> understand that mod_conference is not optimized for my use case but was
>>> wondering if someone has any suggestions on what can be done to optimize
>>> for my use case.
>>> I was also thinking that maybe there is a  better alternative for what I
>>> look for, such as having just the talkers on the conference and the
>>> listeners should listen to it via mod_local_stream or maybe use something
>>> like eavesdrop for the listeners but not sure if and how much performance I
>>> would gain.
>>> Thanks for any help or input
>>>
>>>
>>> ____________________________________________________________
>>> _____________
>>> Professional FreeSWITCH Consulting Services:
>>> consulting at freeswitch.org
>>> http://www.freeswitchsolutions.com
>>>
>>> Official FreeSWITCH Sites
>>> http://www.freeswitch.org
>>> http://confluence.freeswitch.org
>>> http://www.cluecon.com
>>>
>>> FreeSWITCH-users mailing list
>>> FreeSWITCH-users at lists.freeswitch.org
>>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>>> http://www.freeswitch.org
>>>
>>
>>
>> _________________________________________________________________________
>> Professional FreeSWITCH Consulting Services:
>> consulting at freeswitch.org
>> http://www.freeswitchsolutions.com
>>
>> Official FreeSWITCH Sites
>> http://www.freeswitch.org
>> http://confluence.freeswitch.org
>> http://www.cluecon.com
>>
>> FreeSWITCH-users mailing list
>> FreeSWITCH-users at lists.freeswitch.org
>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>> http://www.freeswitch.org
>>
>
>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org
> http://www.freeswitchsolutions.com
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://confluence.freeswitch.org
> http://www.cluecon.com
>
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20180423/deec2207/attachment.html>