Open sourcing of the highly compressed communication protocol AMF and server‐side Flex components play an important role in adoption of Flex by the enterprises. Live Cycle Data Services (LCDS) is an excellent solution for building scalable RIA, but it’s not cheap. For those who don’t have a budget for LCDS, Adobe has released BlazeDS, the open source implementation of AMF communication protocol.

The Theory
BlazeDS was offered as a free version of LCDS Flex remoting that also promised scaled down support of a modest number of concurrent users for data push.
But the enterprise clients wanted the best of both worlds: an inexpensive and scalable solution. The great part about LCDS and BlazeDS is that their code base is extendable and you can try to make the code do new things. The problem is that the base code is targeting only conventional Java Servlet container where BlazeDS is deployed, and performance/scalability of BlazeDS also depends on the number of concurrent connections supported by your server such as Tomcat, JBoss, WebSphere et al.

Farata Systems architects started experiments in this area when the prerelease of Jetty 7 became available. Jetty is a mature open source server that supports Java Servlet 3.0 specification (JSR 315).

BlazeDS runs in a servlet container, which maintains a thread pool. Each thread is given to a client request and is returned back to the reusable pool after the client is served. When the client uses so called long running connection that thread becomes locked by that client as it never finishes the request. So the number of the concurrent subscribers in BlazeDS depends on the number of threads a particular servlet container can hold.

While BlazeDS is preconfigured with just 10 simultaneous connections, it can be increased to several hundreds, and the actual number depends on the server's threading configuration, CPU and the size of its JVM heap memory. This number can also be affected by the number of messages processed by server in the unit of time and size of the messages.

Non-blocking I/O combined with Servlet 3.0 architectureallowsyou to write the code that is not tied to available server threads. The servlet container sends a request for execution and puts it in a suspended mode releasing the thread for other requests. When the result comes back, it resumes the processing of the request efficiently recycling a smaller number of threads. Because of that, the number of streaming connections can be increased to thousands.

The Test
The first goal was to create a module for BlazeDS to support the Servlet 3.0 with the messaging based on the AMF streaming. Thus test was set with Jetty - the first servlet container that implements Servlet 3.0 API. In less than six months this specification will be supported by most of the J2EE application servers. Additional endpoints ( components responsible for binding actual application services with servlet container ) were created based on BlazeDS open source implementation.

Tree small changes are required to add nio endpoints to a standard BlazeDS (or LCDS for that matter) application in the standard Jetty installation:

a) Add Farata’s nioblazeds.jar to Jetty’s lib folder

b) Modify the services-config.xml file of BlazeDS to change the standard thread-based end point for AMF streaming with Farata’s NioAmfEndpoint that supports Servlet 3.0 API.

c) Increase the parameter of the Jetty’s number of open file handlers based on the number of concurrent users requests you are planning to process.

The Trader Desktop, a sample application that comes with BlazeDS was successfully deployed under BlazeDS/Jetty and tested without any changes with enhanced endpoints.

The next step was to stress test this application using one of the commercial testing software suites that support AMF protocol. Farata engineers teamed up with Neotys, creator of a robust stress testing product called NeoLoad, that allows to emulate workload of tens of thousands of users hitting a server via both HTTP and AMF protocols.

Now you can watch a short screencast of the test that emulates 5000 users working with the Trader Desktop over the 5 minute period. The test starts with 200 users ramping up at the rate of 500 users per 10 seconds.

In this demo, the server side feed sends the messages about the latest stock prices to the Flex subscribers. After that, you’ll be monitoring this process using ds-console, yet another sample application that comes with
BlazeDS. First, the monitor will show just one client with a small number of messages, and the number of maximum streaming client is set to 65535.

Then you’ll see how easy it is with Neoload to load a large number of the users. The test uses 5 machines to emulate the load. The push count is the number of messages sent by the server. The test runs on a 8-cpu machine. Watch the number of allocated threads and the number of users – the number of threads is several times lower than the number of users at any given time. Please note that even when the number of users grows, the number of threads doesn’t. These processes are not expensive neither from the memory not from the CPU utilization perspective.

In this test the system was purposely restricted by introducing throttling in the Feed.java.

During this 5 minute test the server sent about 2.1 million messages. Since the first three minutes (180 seconds) of the test Neoload was ramping up the number of users until it reached 5000, count this time as a half or 90 seconds. Adding another two minutes brings the adjusted test time to 210 seconds or 10000 messages per second. This means that that each of 5000 users received 2 messages per second, which matches the throttling parameter that was set( in Feed.java we specified 400ms of sleep time between messages broadcast). Based on the server CPU and memory utilization we should have no problem supporting over 12000 users on this configuration as long as bandwidth and external load generators are added.

One of the machines used in this test was an 8-core MacPro for the server and four of the cores were shared with the VM emulating one of the client’s machine. There were also two 3Ghz desktops, one MacBook Pro and one 2Ghz Dell laptop - that’s the one that will work really hard trying to parse 300 messages per second. Actually, NeoLoad goes a little too hard on the client trying to even parse AMF messages on the machine running thousands of simulated clients.

The screencast of the stress test is located at http://myflex.org//demos/JettyBlazeDS/JettyBlazeDSloadTest.html .

Comparing with conventional and other technologies
Farata ran the same test with Apache Tomcat server using traditional thread-based I/O and standard BlazeDS long polling. Tomcat comes preconfigured with 250 threads. After increasing gradually this number, the same test can run for about 800 users, but pretty soon the system becomes unstable running out of threads and giving out of memory errors.

Tomcat also has experimental NIO implementation of servlet container named Comet. Farata has also created an endpoint adapter to utilize this feature of Jetty with BlazeDS. But while holding high promises of more efficient full duplex protocol the current Tomcat Comet implementation had some reliability issues.

Conclusion
The screencast should be treated as feasibility study and technical comment and not the benchmark of any sort as it still has a lot of room for improvement. More tests are required against the final release of Servlet 3 implementation for proper scalability benchmark for different servers/configurations.

Based on these results, you may consider using open source BlazeDS in the most demanding enterprise Flex applications. To be fair, we need to mention that LCDS is more than a data push, but if you are looking for a no-cost extensible solution that works in a standard Web environment with corporate firewalls and require session management, properly tuned BlazeDS becomes a good scalable solution for you next RIA.