On Jun 30, 2004 at 08:53, Ezequiel Colombo <ecolombo(a)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