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.hellst...@omnitor.se <mailto:gunnar.hellst...@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.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>
--
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellst...@omnitor.se
+46 708 204 288
--
_____________________________________________________________________
-- 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
