>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/ _______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
