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

[bala murugan]

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/4b55ca5e/attachment.html>