[Live-devel] Performance

[Ross Finlayson]

>Studying the performance my own epoll()-based scheduler, I strongly
>suspect that the far bigger source of inefficiency is the DelayQueue
>implementation that BasicTaskScheduler0 uses. This queue is a linked
>list, causing O(n) cost to adding and deleting timers. Which happens a
>lot. If I understand the behavior correctly, a 45-second idle timer is
>rescheduled on each packet.

No, that's not correct.  The RTSP server implementation's 'liveness 
check' timer gets rescheduled only after the receipt of an incoming 
*RTCP packet* (or an incoming RTSP command) - not on every (or any) 
outgoing packet.

>With the stock code, I had results similar to Vlad Seyakov's: I petered
>out at about 140-150 sessions. With my rewritten scheduler, I've been
>able to get to 400-500 sessions. My scheduling queue is based on an STL
>set<> with an appropriate less-than operator. This provides O(log n)
>insert/delete.

I'd be happy to consider replacing the current DelayQueue 
implementation with something that performs better with large number 
of tasks (with relatively small number of tasks, the existing 
implementation shoud be OK).  However, I don't want to use the STL, 
because I don't want to make the "LIVE555 Streaming Media" dependent 
upon it (because I want this code to continue to be useful for (e.g.) 
embedded systems that are relatively memory constrained, or which 
might not have the STL available for other reasons).

>I made one other observation: readSocket() in GroupsockHelper.cpp calls
>blockUntilReadable(). blockUntilReadable() uses select() to wait for the
>socket to be ready. This has two problems: first, we really shouldn't
>ever be blocking, since this blocks all sessions: if the data isn't
>ready, we should go back to the event loop.

Yes.  Unfortunately there are still a few places in the code where we 
want to do a synchronous (blocking) read on a socket.  To handle that 
case, we include the "select()" call in "readSocket()", even though 
it's usually (i.e., for asynchronous reading) a no-op.

At some point, I should get rid of these (few) remaining blocking 
socket reads, and remove the "select()" call from "readSocket()". 
Actually, as you're just running a RTSP server, you can probably 
remove the "select()" call right now.  You could give that a try, to 
see if it improves performance on your system.
-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/