I'm not sure where all of that time is going... between these two log statements:
[LCDS] 16:25:10.578 [DEBUG] Thread[my-rtmp-SocketServer-WorkerThread- 1,5,main] Connection '19658898' starting a read. ... [LCDS] 16:25:10.937 [DEBUG] Deserializing AMF/RTMP request The code is reading data off of the socket until it gets a complete AMF message. ~350ms is a long time to spend reading data off the socket. I wonder if maybe the client is writing either a lot of data into a large message or if it is introducing some latency with its ability to write? It might make sense to turn on more debugging options such as "Protocol.*" or maybe even "*" so we see all targets. That will give us more fine-grained timings of where the time is being spent. Of course that much debug logging will slow things down overall but it can be helpful to see what exactly the system is doing. Jeff From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Rogier Oorburg Sent: Tuesday, August 19, 2008 2:04 AM To: flexcoders@yahoogroups.com Subject: [flexcoders] LCDS and real-time performance Hi, Recently we have started an experiment on our benchmark-LAN where we have several Windows XP PCs running test programs. One of the PCs is the data-injector (Flex) which pushes changes every second, one is the LCDS2.6 server running on Tomcat and one PC is running the client application (Flex) in which the changes are visible every second. This experiment should determine if Flex using LCDS is a viable option for our real-time systems. There is very little network-traffic and CPU-usage on all PCs is very low, yet the system is able to handle only 400 changes every second. Using our own logger we see that about 400ms pass between the injector committing the changes and the server synchronizing the database. Another 400ms are needed to get all the changes to the other client so it can merge the changes and display them. By examining the built-in server-side logging of LCDS, it becomes clear that a lot of time is spent in the sending and receiving of messages over RTMP: [LCDS] 16:25:10.578 [DEBUG] Thread[my-rtmp-SocketServer-WorkerThread- 1,5,main] Connection '19658898' starting a read. ... [LCDS] 16:25:10.937 [DEBUG] Deserializing AMF/RTMP request ... [LCDS] 16:25:10.968 [DEBUG] Before invoke service: data-service ... [LCDS] 16:25:11.156 [DEBUG] After invoke service: data-service; execution time = 172ms ... [LCDS] 16:25:11.171 [DEBUG] Serializing AMF/RTMP push x 400 ... [LCDS] 16:25:11.390 [DEBUG] Committed transaction ... [LCDS] 16:25:11.421 [DEBUG] After invoke service: data-service reply: Flex Message (flex.messaging.messages.AcknowledgeMessage) ... etc. etc. As you can probably see the communication starting at the first entry up to the start of deserialization already takes approx. 400ms.. the processing of all the changes 172. The pushing of all the changes again takes about 400ms. If we can eliminate these two bottlenecks LCDS would be the perfect candidate to use in our new systems. We have tried everything we can think of, but nothing seems to help. Is it the RTMP protocol or a server or socket setting, or the way the server handles multithreading? Is there some JVM setting we don't know about? Any pointers and help would be appreciated! Greetings, Rogier Oorburg
<<inline: image001.jpg>>
<<inline: image002.jpg>>
