Is there a difference in performance between BlazeDS or LCDS? The answer for this is – Depends on what features you are using. 
PS: Thanks to Seth Hodgson from Adobe for posting these details in the pre-release forums
Scenarios in which BlazeDS and LCDS provide same performance
If you’re just using RPC services (RemoteObject, HTTPService, WebService) over an AMFChannel from the client to the server, there’s no difference in performance between BlazeDS and LCDS. That’s just traditional HTTP requests/responses between the clients and servers. So you’re limited by OS/hardware specs to some max request per second processing capacity for your box (this limit would also depend on what your RemoteObjects are doing, etc.)
If you application is using messaging (or auto-sync data management), that requires a channel that can get messages from the server down to the client. There’s simple polling, and that behaves the same in BlazeDS and LCDS.
Scenarios in which LCDS performance is better than BlazeDS performance
If your application is using data push, this is where the performance differs. BlazeDS supports long-polling and streaming over HTTP to push data to the client but it manages this through the Servlet API, which has the restriction right now of mandating blocking IO.
Why LCDS performs better
LCDS provides support for the RTMPChannel (direct duplex socket connection between the client and server) as well as non-blocking long-polling and streaming support over HTTP that bypasses the Servlet API and its blocking IO limitation. All of these options in LCDS are built on top of the Java NIO APIs.
Non-blocking IO doesn’t require a thread per connection sitting blocked in a read() call on the underlying socket. So you can have many connections without the expense of a having a thread per connection.
In terms of the total number of connections a BlazeDS or LCDS server will support, back of the envelope estimates are in the hundreds for BlazeDS (because of Servlet blocking IO and the fact that Servlet containers generally don’t have more than hundreds of threads in their request handler thread pool) and in the thousands for LCDS thanks to Java NIO. Whether you’re talking about 5K or 10K depends on your OS, hardware and application. At some point, depending on the number of messages you’re sending and the amount of processing and IO you’re doing you’ll saturate your box.
Conclusion
For traditional request/response style interaction between the client and server, blocking IO is reasonable, but for server data push and messaging, it’s not so good. That is BlazeDS and LCDS performance differs when it comes to server data push and messaging, where you are using Blocking IO, LCDS performs better in these scenarios, because of Java NIO.
Posted by Sujit Reddy G 
