<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 29, 2016 at 9:55 AM, Michael Petruzzello <span dir="ltr"><<a href="mailto:michael.petruzzello@civi.com" target="_blank">michael.petruzzello@civi.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div>It is very interesting how threading issues on both a stasis application and Asterisk escalate each other. Using 15 websockets in one stasis application and removing all thread locking from the application have made the ARI messages flow smoothly. Right now I am using about 900 threads to process messages from Asterisk and Asterisk has at least 320 in stasis, though that can increase to infinity.<br><br></div>I have also disabled the channel_varset from stasis because it becomes really unwieldy. When having thousands of callers in a bridge, every time a channel is added to a bridge or removed, every channel receives a channel var set message because of the BridgePeer variable.<br><br></div>As of now, I have two remaining problems:<br><br></div>1. At around having 5,000 channels in a bridge (whether majority are muted or not), the audio breaks down. Anyone talking can only be heard in 3 second bursts approximately every 5-10 seconds. At 10,000 channels only static can be heard in these 3 second bursts.<br><br></div>Is there anything I can optimize so that Asterisk can handle all these channels in a bridge?<br></div></div></div></blockquote><div><br></div><div>Each softmix bridge has only one thread performing all of the media mixing for the bridge.  To<br>get better mixing performance for such a large conference, you will need to create several<br>softmix bridges in a hierarchy with the bridges linked by local channels.<br><br></div><div>Richard<br></div></div><br></div></div>