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

[Gunnar Hellström]

Hi Bala,

I don't know enough about the message processing in Asterisk to give 
hints on that level.

I only wanted to indicate that it could be network transmission time 
that sets the limit to the throughput for MESSAGE. There will be at 
least 4 transmissions on SIP level, to share the 70 milliseconds 
interval you have. Thus 17 milliseconds transmission time per SIP 
network transmission. Maybe that is the speed limit of your network.

Gunnar


Den 2017-06-12 kl. 21:08, skrev bala murugan:
> Hi Gunnar ,
>
>         Each message is addressed to unique and single URI and as 
> expected by protocol after receiving 202 for each message .
>
>         Then it is expected rate because the protocol requires end - 
> to - end confirmation by 200 OK or 202 before sending next MESSAGE.
>         [Bala] any idea what this means expected rate ? whether 14 is 
> accepted or only 5 is accpeted .
<GH>First sum the network transmission times involved in the MESSAGE 
transaction and calculate how many such transactions you can 
theoretically get through.
>
>         Right now @ 14/sec we see the msg_queue is backedup and the 
> message processing thread which is single threaded @ the moment now / 
> taskprocessing thread is not keeping up
>
>         Please advice .
> thanks,
> Bala
>
> On Mon, Jun 12, 2017 at 2:41 PM, Gunnar Hellström 
> <gunnar.hellstrom at omnitor.se <mailto:gunnar.hellstrom at omnitor.se>> wrote:
>
>     Hi Bala,
>
>     You did not answer my question:
>
>     Do you send these MESSAGE between the same two SIP URI:s?
>
>     Then it is expected rate because the protocol requires end - to -
>     end confirmation by 200 OK or 202 before sending next MESSAGE.
>
>     If you send to many URI:s, then expected throughput might be higher.
>
>     Regards
>
>     Gunnar
>
>
>     Den 2017-06-12 kl. 18:23, skrev 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
>>     <mailto: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
>>         <http://lists.digium.com/mailman/listinfo/asterisk-dev>
>>
>>
>>
>>
>
>

-- 
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom at omnitor.se
+46 708 204 288

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20170612/2dee78a1/attachment-0001.html>