Summary:ASTERISK-22962: performance spike on Local channels originated using ARI
Reporter:Matt Jordan (mjordan)Labels:
Date Opened:2013-12-10 17:04:39.000-0600Date Closed:2014-01-07 12:52:13.000-0600
Status:Closed/CompleteComponents:Core/Bridging Resources/res_ari
Versions:12.0.0-beta2 Frequency of
Description:Using an AMI Originate with an optimizing Local channel:

action: Originate
Application: Dial
Data: Local/201@queue
Channel: SIP/200

Asterisk consumes about 6% cpu.

With a non-optimizing Local channel, the consumption goes up quite a bit:

action: Originate
Application: Dial
Data: Local/201@queue/n
Channel: SIP/200

Asterisk now consumes about 17% cpu.  This seems to run with g722 on both ends.  There isn't any transcoding stuff in the output of Action: Status.

With the call bridged via ARI, I see 57% cpu, with the transcoding stuff.

So it may be ARI specific, or I guess it could be something I'm doing wrong when we create the bridge.  My bridge creation is a POST to "http://localhost/ari/bridges?type=".

Action: BridgeList reports:

Event: BridgeListItem
BridgeUniqueid: 6d05c058-7ec4-47d7-a029-08dca733ddfe
BridgeType: basic
BridgeTechnology: simple_bridge
BridgeNumChannels: 2
Comments:By: Matt Jordan (mjordan) 2013-12-19 14:03:09.234-0600

Note that the immediate bug here was fixed in r403993. However, there are some longer term/deeper performance issues with format attribute/capabilities in the core that we should address.

As such, this issue is going to remain open, but the massive spike in CPU/horrible transcoding path should no longer occur on Local channels created via ARI.