> One question: was the following ever implemented/addressed since the
> post in 2007?
> http://lists.live555.com/pipermail/live-devel/2007-June/006889.html
>> At some point, I should get rid of these (few) remaining blocking
>> socket reads, and remove the "select()" call from "readSocket()”.
This corresponds with our recent findings with respect to
performance/scalability: We also found that the CPU usage limits the
number of clients that can connect to the RTSP server.
Attached is a plot of CPU vs number of clients when
- streaming only H.264 video per RTSP session (red)
- streami
>
> Also, I notice - from the “gprof” output - that you are streaming
> Transport Stream files. Are those the only kinds of files that you are
> streaming? Is there anything noteworthy/special about them, or are they
> just regular Transport Stream files (e.g. containing H.264 video and AAC
> aud
Also, I notice - from the “gprof” output - that you are streaming Transport
Stream files. Are those the only kinds of files that you are streaming? Is
there anything noteworthy/special about them, or are they just regular
Transport Stream files (e.g. containing H.264 video and AAC audio)?
Ro
> On Jul 16, 2017, at 7:44 AM, Konstantin Shpinev wrote:
>
> 40 clients, ~40% CPU usage.
> gprof results:
Thanks for the feedback. I’ll do some additional tests, to try to narrow down
more what parts of the code are contributing most to CPU overhead, and see if I
can improve things.
In the
40 clients, ~40% CPU usage.
gprof results:
Flat profile:
Each sample counts as 0.01 seconds.
% cumulative self self total
time seconds secondscalls us/call us/call name
20.76 0.11 0.11 15 0.73 3.47
BasicTaskScheduler::SingleStep(unsigned
> I my experience, scalability issues with our server software are usually
> caused by running up against limits in either (1) the capacity of their
> network, or (2) the number of open files (sockets) that are supported by the
> underlying operating system (see
> http://live555.com/liveMedia/f
>
> > 2. Improve DelayQueue. Can anyone share the code?
> To my knowledge, nobody has ever suggested that the implementation of the
> “DelayQueue” class needs to be improved (and, to my knowledge, the current
> implementation has no problems at all). So that’s completely a ‘red
> herring’.
>
>
> When I testing the RTSP server live555MediaServer then I faced slow
> performance. On one core of the CPU with a clock speed of about 3.2 Gz it is
> possible to process only about 140 client connections. The search for
> information on the mailing lists indicated the following ways of optimiza
