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 . 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> 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> 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 >> > > > > >
-- _____________________________________________________________________ -- 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