BlazeDS and LCDS Performace difference

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.🙂

9 Responses to BlazeDS and LCDS Performace difference

  1. Adam says:

    Five minutes I came across this in the BlazeDS documentation: “each streaming connection open between a FlexClient and the streaming endpoints uses a thread on the server” and I almost screamed. Your post is one of the first that came up in the frenzied Google search that followed. There go my hopes of creating a low-cost performant data streaming solution! It is not totally rocket science to write an NIO server. Do you know if BlazeDS is going to go in that direction? Do you think they will go in that direction before my site gets to a thousand simultaneous users? If so, I’m gonna stick with a 1-CPU installation of LCDS until it happens.

  2. Sujit Reddy G says:

    Hi Adam,
    BlazeDS will start using non-blocking IO API, once they are available. This might take some time.🙂

  3. Mohan says:

    The PUSH thread has been Locked so that all threads were blocked
    Stack trace:
    java.net.SocketOutputStream.socketWrite0(Native Method)
    java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)
    java.net.SocketOutputStream.write(SocketOutputStream.java:136)
    org.apache.coyote.http11.InternalOutputBuffer.realWriteBytes(InternalOutputBuffer.java:737)
    org.apache.tomcat.util.buf.ByteChunk.flushBuffer(ByteChunk.java:434)
    org.apache.coyote.http11.InternalOutputBuffer.flush(InternalOutputBuffer.java:299)
    org.apache.coyote.http11.Http11Processor.action(Http11Processor.java:963)
    org.apache.coyote.Response.action(Response.java:183)
    org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java:314)
    org.apache.catalina.connector.OutputBuffer.flush(OutputBuffer.java:288)
    org.apache.catalina.connector.Response.flushBuffer(Response.java:548)
    org.apache.catalina.connector.ResponseFacade.flushBuffer(ResponseFacade.java:279)
    flex.messaging.endpoints.BaseStreamingHTTPEndpoint.streamChunk(BaseStreamingHTTPEndpoint.java:1159)
    flex.messaging.endpoints.StreamingAMFEndpoint.streamMessages(StreamingAMFEndpoint.java:248)
    flex.messaging.endpoints.BaseStreamingHTTPEndpoint.handleFlexClientStreamingOpenRequest(BaseStreamingHTTPEndpoint.java:912)
    – locked java.lang.Object@2c4eed84
    flex.messaging.endpoints.BaseStreamingHTTPEndpoint.serviceStreamingRequest(BaseStreamingHTTPEndpoint.java:1131)
    flex.messaging.endpoints.BaseStreamingHTTPEndpoint.service(BaseStreamingHTTPEndpoint.java:468)
    flex.messaging.MessageBrokerServlet.service(MessageBrokerServlet.java:377)
    javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
    org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
    org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
    org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
    org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
    org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
    org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
    org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)
    org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
    org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
    org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
    java.lang.Thread.run(Thread.java:619)

  4. Mahesh says:

    Hi Sujit,
    Im new to BlazeDS. And Im in the process of evaluating BlazeDS’s AMF Channeled Remoting technique and traditional HTTPService calls for our Flex app. The deserialization by BlazeDS seems a better advantage over converting Java objects in to XML. But Isnt this deserialization a over head as compared with java–>XML conversion?? This evaluation is on the basis of number of (multiple) users hitting the app. Please share your thought on this.

  5. Kapil Viren Ahuja says:

    NIO is available in LCDS. However, BlazeDS is not going to use it. As of what I heard last, Adobe will stop supporting BlazeDS very soon.

    By the way – great explanation.

  6. Ronny says:

    Mohan: did you find a solution? I got the exact same problem.

  7. abdulrahim says:

    Hi Sujit,

    i would like to know much about data bushing and messaging, can you give any sample program for this,still know i am using only RPC services,i want another one detail ,in which case we go for data bushing and messaging

  8. Hey Sujit,

    First of all,I am a great fan of your work.You seem to be very passionate about Adobe flex.Wanted some help on how to link flex and Blazeds…
    I installed tomcat and then downloaded blazeds…How do I link blazeds to flex….Pls help….The video tutorial doesnt seem to work😦 …Please get it up soon

  9. krish says:

    Dear Sujith,

    I am trying to build a chat application with FLEX,PHP.
    Is BlazeDS is required for that?

    If so, Do we need tomcat to run BlazeDS.

    Could you please clarify me?

    Thanks in advance,
    -Krish

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: