Expand my Community achievements bar.

July 31st AEM Gems Webinar: Elevate your AEM development to master the integration of private GitHub repositories within AEM Cloud Manager.

LCDS and real-time performance


Former Community Member

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!


Rogier Oorburg
2 Replies


Former Community Member
Some research on RTMP and AMF learns us that there should be some way to adjust the packet-size or the AMF-message-size.<br />In the LCDS 2.6 developers guide the <packet-size>-tag is mentioned for the RTMPChannel. But when we start the server the tag is not recognized... any thought on this? Am I using a wrong library for the RTMPChannel? Is there a place where all the possible tags are mentioned and explained?<br /><br />Thank you<br />Rogier


Former Community Member
Hi Rogier,<br /><br />We have a mistake in our documentation, there is no such tag like <packet-size> or <page-size> in LCDS...we will update the developer guide.Sorry for the inconvenience.<br /><br />Cornel.