<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><br></div>2. Every time a channel joins the bridge, the websocket responsible for that channel is then subscribed to the bridge. Then any events that occur on that bridge (such as another channel entering or exiting it) are sent to that websocket. Because every websocket then ends up receiving these messages, it defeats the point of having multiple websockets. To get around this I have been unsubscribing the websockets from the bridge anytime a channel from that websocket enters the bridge, but this isn't perfect as timing is an issue.<br><br></div>Is there anyway to disable this automatic subscription behavior to a bridge?<br></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><font color="#888888"><font color="#20124d" size="1" face="verdana, sans-serif"><b>Michael J. Petruzzello<br></b></font><div><font color="#20124d"><font size="1" face="verdana, sans-serif">Software Engineer</font><span style="font-family:verdana,sans-serif;font-size:x-small"></span></font></div><div><font color="#20124d" size="1" face="verdana, sans-serif">P.O. Box 4689</font></div><div><font color="#20124d" size="1" face="verdana, sans-serif">Greenwich, CT 06831</font></div><div><font color="#20124d" size="1" face="verdana, sans-serif">203-618-1811 ext.289 (office)</font></div><div><a href="https://www.civi.com" target="_blank"><font color="#20124d" size="1" face="verdana, sans-serif">www.civi.com</font></a><br></div><div><img src="https://docs.google.com/uc?export=download&id=0B0HCum2HXqBfbHdjd2Q2SU8wMDA&revid=0B0HCum2HXqBfVTArMEFSMGs0MlYzR1I5c3NrRnFGbzE2WkpJPQ" height="38" width="96"></div></font></div></div></div>
<br><div class="gmail_quote">On Tue, Jun 21, 2016 at 3:29 PM, 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>On Tue, Jun 21, 2016 at 12:16 PM, Richard Mudgett <rmudgett at <a href="http://digium.com" target="_blank">digium.com</a>> wrote:<br>> The subm:devService-test-00000038 taskprocessor is servicing the stasis<br>> message bus<br>> communication with your devService-test ARI application.  Since each<br>> taskprocessor is<br>> executed by one thread, that is going to be a bottleneck.  One thing you<br>> can try is to<br>> register multiple copies of your ARI application and randomly spread the<br>> calls to the<br>> different copies of the application.  (devService-test1,<br>> devService-test2,...)<br><br></div>Ah, that explains it! Everything else has been running well in Asterisk as far as handling the actual channels and the SIP messaging with the large calls / second.<br></div><div><br></div><div>I was thinking about the potential of parallelizing the stasis message bus communication to use multiple task processors, but that would introduce other issues. Messages would be sent out of order, and the ARI application would need to handle that. <br></div></div><div> <br><div><div>Your suggestion sounds like the best approach. That way I still have only one application with multiple connections to Asterisk. No need to have multiple applications and servers that would need to communicate together.<br><br></div><div>Thank you for the insight.<br></div><div><br>On Tue, Jun 21, 2016 at 1:03 PM, Matthew Jordan<mjordan at <a href="http://digium.com" target="_blank">digium.com</a>> wrote:<br></div><div>> To follow up with Richard's suggestion:<br>> <br>> Events being written out (either over a WebSocket in ARI or over a<br>> direct TCP socket in AMI) have to be fully written before the next<br>> event is written. That means that the client application processing<br>> the events can directly slow down the rate at which events are sent if<br>> the process that is reading the event does not keep reading from the<br>> socket as quickly as possible. You may already be doing this - in<br>> which case, disregard the suggestion - but you may want to have one<br>> thread/process read from the ARI WebSocket, and farm out the<br>> processing of the events to some other thread/process.<br><br></div><div>I am already doing this, but thank you for the suggestion. Database access really slows down the processing of events so I have had to do this from the start of my project.<br></div><span class=""><div><br clear="all"><div><div><div data-smartmail="gmail_signature"><div dir="ltr"><font color="#888888"><font color="#20124d" face="verdana, sans-serif" size="1"><b>Michael J. Petruzzello<br></b></font><div><font color="#20124d"><font face="verdana, sans-serif" size="1">Software Engineer</font><span style="font-family:verdana,sans-serif;font-size:x-small"></span></font></div><div><font color="#20124d" face="verdana, sans-serif" size="1">P.O. Box 4689</font></div><div><font color="#20124d" face="verdana, sans-serif" size="1">Greenwich, CT 06831</font></div><div><font color="#20124d" face="verdana, sans-serif" size="1">203-618-1811 ext.289 (office)</font></div><div><a href="https://www.civi.com" target="_blank"><font color="#20124d" face="verdana, sans-serif" size="1">www.civi.com</font></a><br></div><div><img src="https://docs.google.com/uc?export=download&id=0B0HCum2HXqBfbHdjd2Q2SU8wMDA&revid=0B0HCum2HXqBfVTArMEFSMGs0MlYzR1I5c3NrRnFGbzE2WkpJPQ" height="38" width="96"></div></font></div></div></div>
</div></div></span></div></div></div>
</blockquote></div><br></div>