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.hellst...@omnitor.se <mailto:gunnar.hellst...@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>
--
_____________________________________________________________________
-- 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
