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-0600	Date Closed:	2014-01-07 12:52:13.000-0600
Priority:	Major	Regression?
Status:	Closed/Complete	Components:	Core/Bridging Resources/res_ari
Versions:	12.0.0-beta2	Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	Using an AMI Originate with an optimizing Local channel: {noformat} action: Originate Application: Dial Data: Local/201@queue Channel: SIP/200 {noformat} Asterisk consumes about 6% cpu. With a non-optimizing Local channel, the consumption goes up quite a bit: {noformat} action: Originate Application: Dial Data: Local/201@queue/n Channel: SIP/200 {noformat} 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=". {noformat} Action: BridgeList reports: Event: BridgeListItem BridgeUniqueid: 6d05c058-7ec4-47d7-a029-08dca733ddfe BridgeType: basic BridgeTechnology: simple_bridge BridgeNumChannels: 2 {noformat}
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.