[asterisk-dev] Load on SIP MESSAGE how many per sec asterisk can Handle

[bala murugan]

On Mon, Jun 12, 2017 at 12:23 PM, bala murugan <fightwithme at gmail.com>
wrote:

> Thanks Gunnar ,
>
> This is load test to understand how many message it can handle and where
> the bottleneck is .
>
> 14 MESSAGE / sec - takes longer time for the Message to be processed , not
> sure if there is some kind of delay in picking up the message from the
> queue
> and also it will  never be realtime with this rate .
>
> Checking if this is already improved or if there is a way to improve this
> to handle by adding more taskprocessors on the ast_msg_queue or reading
> more messages from the queue etc.
>
> btw  i have good system resources like CPU(16 core),memory(32GB) etc
>
> I dont know how this asterisk taskprocessor works or implemented .
>
>
> thanks,
> bala
>
>
>
>
> On Wed, May 24, 2017 at 3:18 AM, Gunnar Hellström <
> gunnar.hellstrom at omnitor.se> wrote:
>
>> Den 2017-05-23 kl. 23:58, skrev bala murugan:
>>
>> Hi ,
>>
>>  Is anyone aware of how many SIP MESSAGE per sec asterisk can handle , is
>> there a benchmark
>> has this been load tested and results available some where , if there is
>> can you some one share it please .
>>
>> The reason is we ran 16 per sec and we see the ast_msg_queue is backing
>> up with lot of messages
>>
>> <GH>This may depend on your test setup. Are you sending between a fixed
>> pair of URI:s, or multiple?
>> Have you considered this rule from RFC 3428? "
>>
>>    A UAC MUST NOT initiate a new out-of-dialog MESSAGE transaction to a
>>    given URI if there is a previous out-of-dialog transaction pending
>>    for the same URI."
>>
>> So, if you are sending between one pair of URI:s, the sender needs to wait for a final response before sending next MESSAGE. With usual network delays that can mean a maximum of about 5 MESSAGE per second or so.
>>
>> With multiple URIs on both sides, the figure should be higher.
>>
>> Regards
>> Gunnar
>>
>>
>> thanks,
>> Bala
>>
>>
>>
>>
>> --
>> _____________________________________________________________________
>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>
>> asterisk-dev mailing list
>> To UNSUBSCRIBE or update options visit:
>>    http://lists.digium.com/mailman/listinfo/asterisk-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20170612/a67d4c1d/attachment.html>