[asterisk-dev] Asterisk Load Performance

[Michael Petruzzello]

On Tue, Jul 5, 2016 at 4:03 PM, Jonathan Rose <jonathan.rose at
motorolasolutions.com> wrote:

> If you don't need all of your participants actually to be speaking at a
> time (and I hope not with that kind of volume), you could use holding
> bridges for the vast majority of the partipants. Link the bridges using a
> local channel with the Hold bridge side being set to use the 'announcer'
> bridge role and the hold bridge will effectively just be voiceless
> conference participants. If you want, you can listen for DTMF events to
> move the participants back and forth between the different bridges.

Doing the conference this way results in the same kind of long voice queue
warnings/errors as before and eventually the DNS lookup for the server
fails. All 5,000 callers were able to get in though, which is a bit better
than before.

On Tue, Jul 5, 2016 at 5:09 PM, *Richard Mudgett <rmudgett at
digium.com <http://digium.com>*> wrote:

> The exceptionally long voice queue length messages can be a symptom of
> thread
> starvation as the Local channels frame queue has developed an excessive
> backlog.
>
> The forthcoming v13.10.0 release should indirectly take care of the
EEXISTS
> messages
> as part of the https://issues.asterisk.org/jira/browse/ASTERISK-26088 fix.
> Working on
> that issue I saw the EEXISTS messages for REGISTER and SUBSCRIBE message
> processing.  The issue was a result of the original message and
> retransmissions getting
> backlogged in the serializer/taskprocessor and responses sent using
another
> serializer.
>
> Looks like your system's DNS resolver has gotten overwhelmed.

Is there any configuration changes I can make to help alleviate the thread
starvation on the Local channels frame queue?

It does not make sense to me that the system's DNS resolver is getting
overwhelmed. When I have 10,000 calls in one bridge, this does not occur.
When I have multiple bridges with locally originated channels bridging them
then the DNS errors occur.

> Wow.  Thanks Jonathan.  I hadn't thought of doing it that way.  That
should
> really drop the mixing load.
> Probably should allow only ulaw or alaw (pick one) for all participants to
> minimize translation costs.
> One additional thing I should add is that those linking Local channel
> bridges should just allow the
> chosen alaw/ulaw to reduce translation to each participant in the holding
> bridge.  The forthcoming
> v13.10.0 adds the ability to specify formats when ARI originates a channel
> (Local in this case) and
> an originator channel is not available.  (See CHANGES file)

I have only been allowing ulaw. That is very interesting to note about the
Local channels. I'll keep that in mind.

Well, thank you Jonathan, Richard, and Matthew. You have all been really
helpful. This has been really interesting trying to get 10,000 callers on
one Asterisk server. As Asterisk is not capable on one server for what I am
trying to do, I am going to design a scalable, multi-server architecture
instead.


*Michael J. Petruzzello*
Software Engineer
P.O. Box 4689
Greenwich, CT 06831
203-618-1811 ext.289 (office)
www.civi.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20160706/296490f0/attachment.html>