On Jun 30, 2004 at 08:53, Ezequiel Colombo ecolombo@arcotel.net wrote:
Hi all, i am tested the mediaproxy 1.0.1 version on a dual CPU (2.6GHz) and get at least 180 simultaneous calls ! This is a good and very scalable solution to solve NAT related problems.
I tested it on a dual athlon mp2000. I've also modified rtpgenerator to work with nathelper (patch for nh version attached).
rtpgenerator has a few drawbacks: it eats more cpu than rtproxy and cannot create more than 510 calls (the python code seems to use internally select witch doesn't work on more than 1024 file descriptors).
Also mediaproxy cpu usage varies a lot (it doesn't stay constant it has a lot of peaks).
mediaproxy 1.0 eats all the cpu (100% ) at arround 90-120 simultaneous calls (it starts reaching 100% at 90 calls). rtpproxy (unstable, latest cvs) uses only 60-66% cpu for 500 simultaneous calls (rtpgenerator cannot generate more). rtpgenerator uses 70-81% during this time.
I've measured all this after 3-4 minute from starting rtpgenerator (because I was not interested on the initial session creation;, for example in the first minute rtpgenerator uses almost 100%).
Another interesting peformance benchmark is how many sessions can be handled per second, without any rtp traffic (the equivalent of a sip call: invite -> request, 200 ok -> lookup, bye -> delete). This shows how much is ser slowed down by sending commands to the rtp proxy.
Unfortunately my benchmark program works only with rtpproxy (different commands). Here are some results (this time on a pentiumM 1.6Ghz single cpu) maximum 100 simultaneous session : 5011 sessions/s 4000 simultaneous seessions : 46 sessions/S (this happens because poll scales very badly with the number of FDs used; 4000 sessions => 16000 open fds => rtpproxy spends the most time in the poll syscall).
Andrei