reSIProcate

Mailing Lists

Source Code

Google Search:



< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index  

Re: [reSIProcate-users] Transaction Throughput with Repro


Thanks for this Scott.


I'm going to look over what I did and try a few new things and I'll let you know if I get any different results.


From: slgodin@xxxxxxxxx <slgodin@xxxxxxxxx> on behalf of Scott Godin <sgodin@xxxxxxxxxxxxxxx>
Sent: Friday, April 20, 2018 1:42:16 PM
To: Michael Trank
Cc: resiprocate-users@xxxxxxxxxxxxxxx
Subject: Re: [reSIProcate-users] Transaction Throughput with Repro
 
Hi Michael,

I would have expected better performance than DUM, since there is less state tracking.  Here is an old posting on raw stack performance with various stack options for threading turned on.


Are you running repro with the ThreadedStack = true  following option enabled?  It should help a bit.

One thing to consider is that repro built-in logging is blocking, so if you have the logging level turned up high, it can slow things down.

Scott


On Fri, Apr 20, 2018 at 12:51 PM, Michael Trank <Michael.Trank@xxxxxxxxxxxx> wrote:


Scott and other Resiprocate-Users:


Can anyone tell me what kind of throughput that I can expect from the "repro" proxy server code? I had done some testing on a repro-based proxy server project that has a lot of custom database lookups, and I got some mediocre results. So, I have begin to test on the bare-bones repro server with no DB lookups and I am still unable to get more than about 50 calls per second through repro when compiled and running in Windows Server 2012. ( A "call" being an INVITE transaction followed by a BYE transaction that the repro server proxies between a UAC "sipp" script and a UAS "sipp" script.)


Note, repro is running in a machine with an Intel Xeon E5-2630 processor, and 64 GigaBytes of memory.


I have also tried this with repro compiled in Linux and got some better throughput.... about 130 calls per second.


What I mean by these maximum numbers is the call rate which I can maintain from the UAC sipp script without there being any delays in responses that lead to retransmissions by the sipp UA scripts.


Repro is something that I have begun to work with relatively recently, but I have worked with the "DUM" code for many years. With a custom B2BUA that I have built with the DUM code, I am able to push through upwards of 500 calls per second easily in the same type of hardware.


Is this disparity in performance between DUM and REPRO something that others have seen, and that there is an explanation for? (Or am I doing something wrong?)


Thanks.




_______________________________________________
resiprocate-users mailing list
resiprocate-users@resiprocate.org
List Archive: http://list.resiprocate.org/archive/resiprocate-users/