BlazeDS vs LiveCycleDS
Here is a nice post for those of you who are trying to compare BlazeDS to LiveCycleDS.
Note that I had a question in comments:
Can you give your opinions on concurrent users? The article I read at http://flexblog.faratasystems.com/?p=277 said there was a major difference in the number of concurrent users that BlazeDS would support vs LiveCycleDS.
If anyone has any info on this, please respond to this post.
February 7th, 2008 at 5:29 pm
Wouldn’t BlazeDS’s concurrency limitation be a factor of the application server’s limit, not BlazeDS itself?
Beau
February 7th, 2008 at 8:59 pm
This was sent to me by Seth Hodgson so I thought I would share it:
It depends on what features your application is using. 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 client and sever - 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. But the better “push” channels is where things differ significantly. BlazeDS supports long-polling and streaming over HTTP to “push” data to the client but it has to manage this through the servlet API which has the unfortunate restriction right now of mandating blocking IO. We’re participating in the Servlet 3 JSR which will add non-blocking IO APIs but that won’t be available for some time in a standard fashion across all the containers we support.
For traditional request/response style interaction between the client and server blocking IO was reasonable, but for server data push and messaging, it’s not so good.
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 hundreds, thousands, etc. connections without the expense of a thread per each. You can mitigate that expense in BlazeDS by tuning down the stack size for your Java threads, but that’s still much more than 0 overhead.
In terms of the total number of “push” connections a BlazeDS or LCSD 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 your’re doing you’ll saturate your box.
There’s more detail regarding the various channel options in BlazeDS and LCDS and when to use what posted here: http://www.dcooper.org/blog/client/index.cfm?mode=entry&entry=8E1439AD-4E22-1671-58710DD528E9C2E7
RTMP is availble in the current LCDS release but the NIO-based long polling and streaming endpoints for LCDS are not - get on the LCSD beta program if you want to give them a try.