Hello, thanks for all those details, very useful ...
To be clear -- the issue of using high cpu on idle (no active calls) was with rtpproxy v1.2 on a centos (iirc, v6), not with rtpproxy 2.0. On debian, same version of rtpproxy was not exposing this. I was just curios to see if anyone else saw it ... might have been just that system... Cheers, Daniel On 19/10/16 20:00, Maxim Sobolev wrote: > Just a little comment on the numbers that I've thrown out earlier > today. Those are probably somewhat pessimistic, with some creative > tuneup you can probably go much higher. But we also constrained by > some other considerations (i.e. running fully redundant network > connection with FEC, full firewall etc, custom OS), so those are what > we get. > > Also, I wanted to point to the list, speaking about number of sessions > is pretty much pointless, as the main thing that keeps us busy is > packet per second rate. Since same 10,000 sessions might translate to > as much as half of PPS rate if use 10ms ptype versus 20ms ptype. Our > limit at this point of time is some 450k PPS in and 450k PPS out, 16 > cores, FreeBSD 10.3, which could be either 4.5k sessions with 10ms > packets or 9k sessions with 20ms or somewhere in between if you have > mixed traffic (as most of our customers do). Latest Linux kernels > might get better contention control on higher CPU count systems, or at > least it is what I've seen on some of the benchmarks not so long time > ago, We've planned to run some evaluations but have not got time to do > so yet. > > On top of that, even if you can push say 1 million PPS through single > tuned up box (10k sessions at 10ms), some other constrains may arise. > Most of the general-purpose DC providers we've encountered in our > somewhat limited practice, design their networks with much lower PPS > per port in mind. It's often an issue with a new DC here that we bump > into all sorts of automated DDoS prevention systems once we reach > 100-200k PPS per box/port. So at the end of the day it might be more > practical and economical to run bunch of the smaller nodes and spread > the load across them using something like rtp_cluster rather than try > to cram all that traffic into a single box/port. > > -Max -- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio Advanced Training, Berlin, Oct 24-26, 2016 - http://www.asipto.com
_______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
