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. |