<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 21, 2016 at 11:12 AM, 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div class="h5"><div>>On Fri, Jun 17, 2016 at 1:37 PM, Richard Mudgett <<a href="mailto:rmudgett@digium.com" target="_blank">rmudgett@digium.com</a>> wrote:<br>
>><br>
>><br>
>> On Fri, Jun 17, 2016 at 12:36 PM, Michael Petruzzello<br>
>> <<a href="mailto:michael.petruzzello@civi.com" target="_blank">michael.petruzzello@civi.com</a>> wrote:<br>
>>><br>
>>> Hello,<br>
>>><br>
>>> I am currently working on determining bottlenecks in Asterisk and a Stasis<br>
>>> App. I'm currently trying to handle 83.3 calls/second. For the most part,<br>
>>> Asterisk and the Stasis APP handle that well, but there is a 60+ second<br>
>>> delay in response time.<br>
>>><br>
>>> On the Asterisk side, I am seeing the following warnings. [Jun 17<br>
>>> 12:00:16] WARNING[23561]: taskprocessor.c:803 taskprocessor_push: The<br>
>>> 'subm:cdr_engine-00000003' task processor queue reached 500 scheduled tasks.<br>
>>> [Jun 17 12:00:18] WARNING[25477][C-00000068]: taskprocessor.c:803<br>
>>> taskprocessor_push: The 'subm:devService-test-00000038' task processor queue<br>
>>> reached 500 scheduled tasks.<br>
>>> [Jun 17 12:00:21] WARNING[26298][C-000000a3]: taskprocessor.c:803<br>
>>> taskprocessor_push: The 'subp:PJSIP/sippeer-00000022' task processor queue<br>
>>> reached 500 scheduled tasks.<br>
>>> [Jun 17 12:00:23] WARNING[27339][C-0000010d]: taskprocessor.c:803<br>
>>> taskprocessor_push: The 'subm:ast_channel_topic_all-cached-00000032' task<br>
>>> processor queue reached 500 scheduled tasks.<br>
>>> [Jun 17 12:01:32] WARNING[31697][C-000003b2]: taskprocessor.c:803<br>
>>> taskprocessor_push: The 'subm:ast_channel_topic_all-00000036' task processor<br>
>>> queue reached 500 scheduled tasks.<br>
>>> [Jun 17 12:05:55] WARNING[23280]: taskprocessor.c:803 taskprocessor_push:<br>
>>> The 'SIP' task processor queue reached 500 scheduled tasks.<br>
>>><br>
>>> I have not seen a configuration setting on Asterisk to prevent these<br>
>>> warnings from occurring (I'm trying to avoid modifying Asterisk source code<br>
>>> if possible). Looking at the task processors, I see the queue to the stasis<br>
>>> app bottlenecks:<br>
>>> subm:devService-test-00000038                    4560990          0<br>
>>> 1041689. It does clear up relatively quickly. The CDR engine also bottle<br>
>>> necks (extremely badly), but I don't use that. Nothing else comes close to<br>
>>> having a large queue.<br>
>>><br>
>>> The stasis app itself is extremely streamlined and is very capable of<br>
>>> handling a large number of messages at a time. The app runs with the JVM so<br>
>>> I am also researching into that as well as the netty library I am using for<br>
>>> the websocket connections.<br>
>>><br>
>>> Any insight into Asterisk's side of the equation and how it scales on 40<br>
>>> vCPUs would be greatly appreciated.<br>
>><br>
>><br>
>> There are no options to disable those taskprocessor queue size warnings.<br>
>> They are a<br>
>> symptom of the system being severely stressed.  If the stress continues it<br>
>> is possible<br>
>> that the system could consume all memory in those taskprocessor queues.<br>
>><br>
>> Recent changes to the Asterisk v13 branch were made to help throttle back<br>
>> incoming<br>
>> SIP requests on PJSIP when the taskprocessors become backlogged like you are<br>
>> seeing.<br>
>> These changes will be in the forthcoming v13.10.0 release.  If you want, you<br>
>> can test with<br>
>> the current v13 branch to see how these changes affect your stress testing.<br>
>><br>
>> If you don't need CDR's then you really need to disable them as they consume<br>
>> a lot of<br>
>> processing time and the CDR taskprocessor queue backlog can take minutes to<br>
>> clear.<br>
>><br>><br>>To echo what Richard said, because Asterisk is now sharing state<br>
>across the Stasis message bus, turning off subscribers to that bus<br>
>will help performance. Some easy ones to disable, if you aren't using<br>
>them, are CDRs, CEL, and AMI. Those all do a reasonable amount of<br>
>processing, and you can get some noticeable improvement by disabling<br>
>them.<br>
><br>
>Once you get past that, you can start fiddling with some of the lower<br>
>level options. To start, you can throttle things back further by<br>
>disabling certain internal messages in stasis.conf. As stasis.conf<br>
>notes, functionality within Asterisk can break (or just not happen) if<br>
>some messages are removed. For example, disabling<br>
>'ast_channel_snapshot_type' would break ... most things. You may<br>
>however be able to streamline your application by looking at what ARI<br>
>messages it cares about, what messages it doesn't, inspecting the<br>
>code, and disabling those that you don't care about. Lots of testing<br>
>should occur before doing this, of course.<br>
><br>
>You may also be able to get some different performance characteristics<br>
>by changing the threadpool options for the message bus in stasis.conf.<br>
>This may make a difference, depending on the underlying machine.<br>
<br></div></div></div>Thank you for the suggestions.<br><br></div>I'm running Asterisk on 40 vCPUs with 120 GB of RAM. Changing the thread pool options to many more threads is not increasing performance, and at a certain point it decreases performance.<br><div><div><br></div><div>With further testing and having implemented your suggestions, I am realizing the subm:devService-test-00000038 task processor is a major bottleneck. I have always read that Asterisk can handle as many calls as the hardware allows, but I'm not seeing that.<br><br></div><div>I can go with a different architecture of multiple Asterisk servers working together, but I would prefer one server to reduce complexity.<br><br></div><div>What I am doing is not really a stress test because I really need Asterisk to handle 1000s of callers calling in within a few minutes.<br></div></div></div></blockquote><div><br></div><div>The subm:devService-test-00000038 taskprocessor is servicing the stasis message bus<br>communication with your devService-test ARI application.  Since each taskprocessor is<br>executed by one thread, that is going to be a bottleneck.  One thing you can try is to<br>register multiple copies of your ARI application and randomly spread the calls to the<br>different copies of the application.  (devService-test1, devService-test2,...)<br></div><div><br></div><div>Richard<br></div></div><br></div></div>