[asterisk-users] ConfBridge performance problem...?

[Thorsten Göllner]

Did you watch the cpu usage (for example with top)?
You have a board installed which does use dahdi? Did you check the 
command "dahdi_test"?
Maybe a (performance) problem of the software ec?

Am 06.02.2013 11:13, schrieb Hristo Trendev:
> Hi,
>
> I have been experimenting with ConfBridge from the asterisk-11 stable 
> SVN branch (and with 11.2.0 also) for the last 3 weeks and I see a 
> problem, which what I believe is performance related. I just wanted to 
> ask if someone else has made any tests and what is the maximum number 
> of participants that they've seen in a conference.
>
> I was never able to get more than 8 participants (mixed G722 and 
> G711a) on a conference (actually that's per server limit) with almost 
> all settings on default, except for dsp_drop_silence and denoise which 
> are enabled.
>
> I tested on Debian squeeze, 64-bit, quad-core Xeon server @2.4GHz and 
> also on another virtual server with similar processor (just one core 
> available to the VM). While this is not the latest and greatest CPU, I 
> would certainly expect it to handle more than 8 calls.
>
> To be honest, I was in fact able to get it working for up to 20 
> participants (most with G711), when I switched from res_timing_timerfd 
> to res_timing_dahdi and turned off denoise, but that's still not 
> normal I believe, especially with most participants on mute and with 
> dps_drop_silence enabled and nothing else running on the server.
>
> The problem itself is, that once I get over the "critical" number of 
> participants, the voice starts to break up and it's impossible to 
> understand the person who's talking. This is certainly not bandwidth 
> related because all tests were made on the LAN and besides I could see 
> that the CPU was sometime close to 100%.
>
> Did someone observe something similar?
>
> BTW, once the first participant enters the conference I start seeing 
> probably over 50 messages per second saying:
>
> bridging.c:757 bridge_channel_join_multithreaded: Going into a 
> multithreaded waitfor for bridge channel 0x292d708 of bridge 0x28f3658
>
> Best,