[Serusers] new MediaProxy release 1.1.0

Andrei Pelinescu-Onciul pelinescu-onciul at fokus.fraunhofer.de
Thu Jul 1 17:25:29 CEST 2004


On Jul 01, 2004 at 15:53, Adrian Georgescu <ag at ag-projects.com> wrote:
> On Thursday 01 July 2004 14:11, you wrote:
> >>On Jun 30, 2004 at 08:53, Ezequiel Colombo <ecolombo at 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.
> 
> Ezequiel's test result seems to be in the expected range (given our own 
> test
> results).
> 
> In our tests, on a 1GHz Athlon CPU running linux 2.4.26 we got the 
> following
> results:
> 
> mediaproxy reaches 95% CPU load at around 60 simultaneous calls
> mediaproxy gets to 100% CPU load at 80-90 calls
> 
> rtpproxy reaches 95% CPU load at 120 calls
> rtpproxy gets to 100% CPU load at about 150 calls


> 
> Given that we discovered that rtpproxy is only at most twice as fast as
> mediaproxy, we never bothered to re-implement mediaproxy in C. It's much
> easier to stack another box (or even more), than to spend lots of time 
> in
> optimizing a program and in the end to only get it to run twice as fast.

> 
> Given that Andrei's results are very different from what our tests 
> showed, we
> suspect that there were some errors in the testing procedure.


> Also there is an error in his patch (see comments below for details).
> I attached a version of rtpgenerator that was modified to work with 
> rtpproxy,
> but with this error fixed.
> 
> >>I tested it on a dual athlon mp2000.
> >>I've also modified rtpgenerator to work with nathelper (patch for nh
> >>version attached).
> 
> Patch has a problem. It sends packets to the same IP as the generator 
> itself
> (the default is 127.0.0.1) and not to the rtpproxy returned IP. This 
> means
> that in it's default configuration it sends from 127.0.0.1 to 127.0.0.1 
> where
> rtpproxy doesn't listen. We tried it and it gets flooded back with "udp 
> port
> unreachable". This explains the high load on the generator you've seen 
> and
> the much lower load on rtpproxy.

No, rtpproxy was listening on 127.0.0.1 (I've  started it with -l
127.0.0.1). If it would have not listened on 127.0.0.1 then there would
have been no load on it (cpu 0%).

BTW: there is an error in your changes:
command should be:
 "%(mode)s %(session)s %(ip)s %(port)d dummyfrom dummyto\n" % self.__dict_

and not
"%(mode)s %(session)s  %(port)d  %(ip)s dummyfrom dummyto\n" ...

> 
> >>
> >>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).
> 
> You can call poll3 instead of poll, but it is not designed to generate 
> that
> many calls. That's why we limited it to 30 max. If it generates more it 
> loads
> the cpu too much and the results are not conclusive. Instead run 
> multiple
> instances with 30 calls and they should do better. Or run it on a 
> different
> host that the one that runs rtpproxy.

If you run it on a different host you end up with the same problem (it
will still eat the cpu faster then rtpproxy, unless you have a much
faster test host).
In my tests I've used a dual machine. Both rtpproxy and rtpgenerator are
single processes, so each of them got in fact a cpu for them (they were
not competing for the same cpu).
Moreover running rtpgenerator on a different host than rtpproxy will
require more changes, since rtpproxy uses udp in this case.

> 
> Another problem if you try to generate too many calls with it is that 
> it won't
> be able to send the packets at exactly 20ms time intervals. In this 
> case you
> will see a high load on the generator and a much smaller load on 
> rtpproxy
> itself. (as we noticed the thing that generates the high load on both
> mediaproxy and rtpproxy is the combination of many calls with the small 
> time
> interval that the packets arrive at the proxy (10-20 ms). if this time
> interval is increased because the generator cannot push that many data 
> at
> every 20ms the load on rtpproxy will decrease very quickly while the 
> load on
> the generator will sharply increase).
> 
> As a conclusion, I suggest the following to get results that are closer 
> to
> reality:
> 
> 1. Preferably run the generator on another machine.

As I said this won't solve much and requires deeper changes to
rtpgenerator (udp support). OTOH  I think a dual machine is pretty good
for this kind of tests.

> 2. Never use a count higher than 50 (at least for a 1GHz machine) for a
>    running instance of the generator. The rule is to not see the 
> generator
>    eat more than 1% of CPU. If you need more calls run multiple 
> instances of
>    the generator to sum up the number of calls.

In my case generator always use more than 1% of the CPU (even for
count=30).
A good test will run different instances on different machines. However
you would need a lot of them.


>    (The attached generator accepts up to 50 calls - increased from 30)
> 3. Specify the commands you used to run both the generator and the 
> proxy so
>    it is easy to spot problems like data being sent to 127.0.0.1 or the
>    fact that data is only sent in one direction but never answered 
> (we've
>    seen this sometimes if --ip is not specified)

Ok, I forgot to include them.
I've re-run the tests with similar results:
ulimit -n 10240
./rtpproxy -f -l 127.0.0.1 -s /tmp/rtp.sock
chmod 666 /tmp/rtp.sock

./rtp2generator.py --ip=127.0.0.1 --proxy=/tmp/rtp.sock  --g711
--count=500




> 4. Make sure the data is passing through the proxy. With mediaproxy you 
> can
>    use the sessions.py script of the media_sessions.phtml web page.
>    With rtpproxy use iptraf or tcpdump.

Or just watch the load and the udp socket queues.
> 

[...]

You might have a point though about the large number of calls bad
behaviour of rtpgenerator. Since it seems like it's using select it might
scale very badly with the number of calls (select/poll performance drops
much faster then linearly with the increasing number of files descriptors).

The same problem affects rtpproxy. I think its performance would improve 
 dramatically if it would switch from poll to sigio (linux 2.4), epoll
 (2.6), kqueue (*bsd) or /dev/poll (solaris).


Andrei




More information about the sr-users mailing list