CPU charge question

[GoogleCodeExporter]

- siprtmp takes without calls about 2% of CPU and with one call about 10% with 
a nocona 2 x Xeon
This is a little weird since there is no audio/video encoding. 
is this the effect of RTMP to RTP loop ?

Original issue reported on code.google.com by Boophone...@gmail.com on 8 Feb 2011 at 11:08

[GoogleCodeExporter]

Hey, I tried rtmp.py.patch, but don't see any significant improvement beyond 
r60/r68. I also tried changing the reading to use array of buffers instead of 
manipulating strings, but not much improvement.

Original comment by kundan10 on 5 Apr 2011 at 3:12

[GoogleCodeExporter]

an idea, maybe use ffmpeg libraries to call from python to manage rtmp <-> rtp 
, what guys do you think ?

Original comment by in...@boophone.com on 5 Apr 2011 at 3:22

[GoogleCodeExporter]

Ok, I see all of you confirms stability of Reactor in r68, also my approach 
gives less and causes bugs. Excellent job kundan10, thanks.

Original comment by Lukasz.P...@gmail.com on 6 Apr 2011 at 2:34

[GoogleCodeExporter]

lukasz, if you have others ideeas don't be frustrated go ahead ;)

Original comment by in...@boophone.com on 6 Apr 2011 at 3:33

[GoogleCodeExporter]

I am also planning to do a non-multitask based simple rtmp server (just for 
streaming, no recording/playback) in Python to compare the effect of multitask.

Original comment by kundan10 on 6 Apr 2011 at 4:41

[GoogleCodeExporter]

good idea Kundan. on my side I'm going to make some research of audio signal...

Original comment by in...@boophone.com on 6 Apr 2011 at 10:12

[GoogleCodeExporter]

> Hey, I tried rtmp.py.patch, but don't see any significant improvement beyond
> r60/r68. I also tried changing the reading to use array of buffers instead of
> manipulating strings, but not much improvement.

Idea:

In general Reactor returns socket output to task (actually to yield interrupt 
in task) when any data are on the socket. So there are lots of rtmp reads and 
task invocations that yield little amount of data, therefore buffering after 
read has little effect. Reactor could be modified to support delayed read witch 
delay parameter. This would cause necessary data buildup on socket buffer to 
make. select.select should be invoked only on sockets with expired delay. When 
there are no sockets with expired delay, and no tasks, then sleep should be 
invoked until the nearest delay. Writes could be treated similar by Reactor, 
with buildin reactor buffers.

Original comment by Lukasz.P...@gmail.com on 7 Apr 2011 at 2:58

[GoogleCodeExporter]

I added a gevent-based SIP-RTMP gateway and RTMP server module.
http://code.google.com/p/rtmplite/source/detail?r=73

My performance measurement result is documented at
http://p2p-sip.blogspot.com/2011/04/performance-of-siprtmp-multitask-vs.html

In summary, using gevent requires only 1/2 the CPU cycles for RTMP streaming, 
and 2/3 the cycles for SIP-RTMP gateway compared to using multitask.

Original comment by kundan10 on 16 Apr 2011 at 12:02

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Thanks Kundan. I am going to try gevent revisions.

Original comment by Lukasz.P...@gmail.com on 16 Apr 2011 at 4:52

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I received an email from Denis Bilenko, the main maintainer of gevent :
.....

> is it transparent to update libevent-1.4..14b to 2.0.10 to make gevent work
> better ?
not necessarily, In some regards libevent-1.14 is more stable to
2.0.10. You should test on your own application.

Note, that the next version will be using libev, so this question
won't be relevant.

....

Original comment by pratn...@gmail.com on 18 Apr 2011 at 4:16

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

You can ignore the debug message on "ignoring protocol message type 4". In 
previous rtmp.py this was not printed. In siprtmp_gevent.py, this is explicitly 
printed out. YOu can compare protocolMessages function of both rtmp.py and 
siprtmp_gevent.py to see that old one was also ignoring it but not printing. 
Alternatively, you can comment out those else lines in the new file.

Can you create a new issue for tracking for the audio problem you are having 
with siprtmp_gevent.py? So that we can keep this ticket for discussion on CPU 
performance.

Original comment by kundan10 on 21 Apr 2011 at 12:51

[GoogleCodeExporter]

- I had to change user.proxy to an IP instead of hostname because 1/3 times it 
disconnected saying (dns target not found)

gevent uses another async gethostbyname. I guess because of that? Can you try 
experimenting with gevent's monkey patching of gethostbyname?

- i got in rtmp stream debug ignoring protocol message type 4 repeatly when 
sound is coming to siprtmp_gevent.py

You can comment out that line in siprtmp_gevent.py that prints "ignoring 
protocol message..."

- I had to hack siprtmp_gevent for publish(false) needed for netconnection 
serverSide when it needs to stop the stream and close it.

Can you send me the code on this. If it is general purpose, I will add it to 
the SVN.

Thanks

Original comment by kundan10 on 21 Apr 2011 at 12:57

[GoogleCodeExporter]

> gevent uses another async gethostbyname. I guess because of that? Can you try 
experimenting with gevent's monkey patching of gethostbyname
weirdly after serveral time the problem didn't occure anymore... so I kept 
hostname and seems to fully working.

thanks

Original comment by pratn...@gmail.com on 21 Apr 2011 at 2:21

[GoogleCodeExporter]

How many ppl are experimenting this with asterisk?

The biggest issue i saw was the transcoding. the solution for audio.py helps a 
lot but then the CPU in transcoding is tooo high. it gets way better with 
gevents thought

ty

Original comment by ncrip...@gmail.com on 31 Jul 2011 at 4:26

[GoogleCodeExporter]

By audio.py you mean py-audio project on Google Code? Yes, that takes 
significant CPU due to speex<-->pcmu transcoding...

Another alternative to avoid transcoding would be to use Flash Player beta 11 
(which natively supports G711 -- PCMU/PCMA). The changes needed for this in 
rtmplite are mentioned in a comment on issue #49. The changes needed in front 
end if you use Flash VideoIO are documented in 
http://code.google.com/p/flash-videoio/downloads/detail?name=VideoIO-2.4.zip 
(just set the "codec" property to "pcmu") and if you use VideoPhone then you 
can manually set the codec property to "pcmu" in the actionscript code. Make 
sure to compile with new Flex SDK 4.5+ and mxmlc compiler/command line options 
of swf-version=13 and target-player=11 ... unfortunately Flash Player 11 is in 
beta stage, and not already available on many browsers (e.g., not on Mac OS X 
10.5).

Asterisk can be configured to support speex, so that you can move the 
transcoding to asterisk... But depending on whether you want to scale 
siprtmp.py or asterisk nodes, that may not be desirable...

Original comment by kun...@twilio.com on 3 Aug 2011 at 5:56

[GoogleCodeExporter]

Just installed 9.1 version, having about 30 users streaming I got about 21% CPU 
usage while I had 4% with more users on Flash media server, thought to let you 
know.

Original comment by m...@majidkhosravi.com on 9 Feb 2013 at 9:52

Attachments:

• [CPU Usage.png](https://storage.googleapis.com/google-code-attachments/rtmplite/issue-31/comment-76/CPU Usage.png)

[GoogleCodeExporter]

excellent, it's now very stable. thanks for your test.

Original comment by pratn...@gmail.com on 26 Feb 2013 at 4:25