Performance Report of Server Side RIA Frameworks
Server-side RIA frameworks have become popular recently. Both ZK and ICEfaces have reached the goal of 1 million downloads. However, regarding server side RIA frameworks, people used to worry about their performance and memory consumption since it determines how many concurrent users can their application serve, and its average response time. It is a pity that few reports can be found nowadays.
Editor's Note (7.7.09): Subsequent to its original publication, ICEsoft engineers found the methodologies and results as presented by ZK to be erroneous and misrepresentative. For additional and accurate information on the performance realized by the ICEfaces framework, mentioned in this article, please refer to ICEfaces Performance Report -- Corrected.
Editor's Note (6.12.09): The author of the folowing performance benchmark, Robbie Cheng, is an engineer at ZK. DZone has not participated in this experiment nor has it validated the results of Robbie's findings. The results are being presented here as means to facilitate further dialogue amongst the end users of these three products as well as the product vendors. The findings and recommendations provided at the end of this article are those of the author's, and are not in any way endorsed by DZone.
To determine the performance of these two frameworks, I arranged a series of tests to record their average response time, and memory consumption. For reference, I also include another famous server side framework, RichFaces into this test. Among these three frameworks, both ICEfaces, RichFaces are JSF based, and ZK is pure Java based. This could be a battle between comfort, and standards. It is interesting to see which one will win out.
Test Methodology
This experiment includes 3 test scenarios, from simple to complex, including a simple form, a grid with 15 records, and a grid with 150 records. Moreover, to determine the scalability of each one, each test case includes 10 scenarios, from 100 to 1000 concurrent users. Each test case will be run for 50 times, and its average response time will be recorded.
- Target
Static page (ZK), ZK, Icefaces, RichFaces - Test Cases
Simple Form, Grid with 15 records, Grid with 150 records
To record required data, I use two popular tools, including JMeter, a load testing tool built specifically for websites, and VisualVM, a tool released by Sun Microsystems for viewing detailed information about Java applications.
Test Environment
The following paragraphs include the hardware specification of this test, required software, and corresponding parameters. I downloaded the latest version of these three frameworks, and used Apache Tomcat as the test platform. The maximum memory of Tomcat is 1GB due to limitation of the computer.
- Hardware
- CPU: Intel Core 2 Duo P8600 2.4 GHz 2GB
- Memory:4GB
- Network Adapter: Intel 82567LM Gigabit Ethernet Connection
- Software
- ZK 3.5.2
- ICEfaces 1.7.2
- Richfaces 3.3
- JDK 1.6.0_10
- Apache Tomcat Server 6.0.18
- Jmeter 2.3.2
- VisualVM 1.1.1
- Configurations
Tomcat- Session time-out: 30 mins
- -Xms 256MB
- -Xmx 1024MB
- maxThreads: 1000
- acceptCount: 200
- Loop per test case:50.
- Source Code
Source Files can be downloaded from the following url:
https://zkforge.svn.sourceforge.net/svnroot/zkforge/trunk/zkTest
Test Case1 - Simple Form
- Test Case
This simple form includes 3 fields, name, password, and comment. - Response Time
ZK:
- Less than 0.5 second response time when 500 concurrent threads.
- Less than 1.5 second response time when 1000 concurrent threads.
- More than 1.5 seconds response time when 500 concurrent threads.
- Out of memory when 1000 concurrent threads.
- More than 1 seconds response time when 500 concurrent threads.
- More than 3 seconds response time when 1000 concurrent threads.
- Memory Consumption
ZK:
- 200 MB memory consumption when 500 concurrent threads.
- 300 MB memory consumption when 1000 concurrent threads.
- 900 MB memory consumption when 500 concurrent threads.
- Out of memory when 1000 concurrent threads.
- 200 MB memory consumption when 500 concurrent threads.
- 300 MB memory consumption when 1000 concurrent threads.
- Analysis
- ZK runs 2 times faster than RichFaces, and 3 times faster than ICEface. The result indicates that JSF based frameworks requires more time while generating page.
- Memory consumption of ZK and RichFaces is as good as each other, but ICEfaces consumes more than 4 times than the other two. It is a surprise that the memory consumption of JSF based RichFaces is as good as ZK, but ICEfaces is on the contrary.

Test Case2 - Grid with 15 Records
- Test Case
This test case includes a grid, and a model with 15 records of employees’ information.

- Response Time
ZK:
- 1 seconds response time when 500 concurrent threads.
- 3 seconds response time when 1000 concurrent threads.
- 2 seconds response time when 500 concurrent threads.
- Out of memory when 1000 concurrent threads.
- 2 seconds response time when 500 concurrent threads.
- 5.5 seconds response time when 1000 concurrent threads.
- Memory Consumption
ZK:
- 200 MB memory consumption when 500 concurrent threads.
- 400 MB memory consumption when 1000 concurrent threads.
- 1000 MB memory consumption when 500 concurrent threads.
- Out of memory when 1000 concurrent threads.
- 300 MB memory consumption when 500 concurrent threads.
- 600 MB memory consumption when 1000 concurrent threads.
- Analysis
- Again, ZK outscore the other two JSF based ones for the other two. ZK runs 2 times faster than RichFaces, and 3times faster than ICEface.
- Regarding memory consumption, ZK uses less memory than RichFaces. ICEfaces consumes more than 4 times than the other two. Not sure if ICEfaces uses much cache at the server since its memory consumption reaches 1 GB when there are only 300 concurrent threads.
Test Case3 - Grid with 150 Records
- Test Case
This test case includes a grid, and a model with 150 records of employees’ information.

- Response Time
ZK:
- 2.7 seconds response time when 500 concurrent threads.
- 6.4 seconds response time when 1000 concurrent threads.
- Out of memory when 500 concurrent threads.
- 10 seconds response time when 500 concurrent threads.
- 28 seconds response time when 1000 concurrent threads.
- Memory Consumption
ZK:
- 350 MB memory consumption when 500 concurrent threads.
- 600 MB memory consumption when 1000 concurrent threads.
- Out of memory when 500 concurrent threads.
- 350 MB memory consumption when 500 concurrent threads.
- 600 MB memory consumption when 1000 concurrent threads.
- Analysis
- The result indicates that ZK handles scalability issue quite well since it runs 4 times faster than RichFaces. But, ICEfaces runs out of memory when 300 concurrent threads.
- ZK and RichFaces both use memory most efficiently. The memory management of RichFaces is as good as ZK again. And, ICEfaces runs out of memory when there is only 300 concurrent threads.
Summary
In all of above tests, the pure Java framework outscores JSF based frameworks regarding average server response time, and memory consumption. ZK runs 2 to 4 times faster than RichFaces, and at least 3 times faster than ICEfaces. The complex six phases of JSF might be the cause of slow response time since it takes longer time to be initialized. Regarding memory consumption, ZK and RichFaces perform as good as each other; on the contrary, ICEfaces used to get in trouble of out-of-memory issue. It seems that ICEfaces use a lot of caches since it runs out of memory when there are only 300 concurrent threads.
I hope this article provides help for those who attempts to adopt which RIA framework to choose. If you plan to introduce RIA into a green-field project, I suggest pure Java framework, ZK instead of JSF based ones. However, if your project is build based on JSF technology, I recommend RichFaces than ICEfaces since it outscores ICEfaces, especially memory management.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)





Comments
michelle211 cannon replied on Fri, 2009/06/12 - 11:00am
We have a lot more than 300 concurrent threads. We do a massive amount of processing.
Or maybe your testing is flawed.
At the company I work for we have a major spring/icefaces application , it has over 100 screens, we've used automated testing and tested with over 5000 users and on the transaction side over 150,000 transactions via jms Performance was more than acceptable. Usually less than a second on screen response time, if we saw any hangups at all it was with the jpa spring hybernate templates, The app hits multiple databases and we definitely saw performance hits especially against microsoft sql server. We have better luck with the oracle side.
One reasons your test data may be skewed is that long polling ajax apps are hard to profile, we use the excellent testing tool DevPartner to find our bottlenecks and fix them.
It may be true that some javascript pure implemetations are faster, less abstraction but maintainance and code portability amoung large development teams is far easier to handle with the serverside platforms.
In additon to work , I am involved in serveral open source endevours that use java/icefaces as backend servers to mobile applications.
www.mooncatventures.com/blogs,
again performance is excellent. Even when loading and keeping large amounts of multimedia data in shared memory scopes.
Icefaces performance is very affected by how you configure it , what application server you use and wether or not you use an additional server to take up some of the workload. icefaces provides a push server that handles all the ajax calls and this improves performance a lot, so does the push capabilities of glashfish, tomcats NIO (but it can be buggy) and jetty continuations.
michelle211 cannon replied on Fri, 2009/06/12 - 11:06am
michelle211 cannon replied on Fri, 2009/06/12 - 11:10am
Paul Toker replied on Fri, 2009/06/12 - 4:58pm
michelle211 cannon replied on Fri, 2009/06/12 - 6:44pm
James Jamesson replied on Sat, 2009/06/13 - 12:40am
Robbie Cheng replied on Sat, 2009/06/13 - 3:12am
in response to:
michelle211 cannon
Ted Goddard replied on Sat, 2009/06/13 - 9:06am
Joonas Lehtinen replied on Sun, 2009/06/14 - 2:12pm
michelle211 cannon replied on Mon, 2009/06/15 - 9:02am
michelle211 cannon replied on Mon, 2009/06/15 - 9:05am
in response to:
michelle211 cannon
michelle211 cannon replied on Mon, 2009/06/15 - 9:38am
Jose Maria Arranz replied on Mon, 2009/06/15 - 11:43am
Why are so different these files?
https://zkforge.svn.sourceforge.net/svnroot/zkforge/trunk/zkTest/test%20cases/form/icefaces-form-all.jmx
https://zkforge.svn.sourceforge.net/svnroot/zkforge/trunk/zkTest/test%20cases/form/zk-form-all.jmx
For instance:
vs
vs
And so on.
Aguiar replied on Mon, 2009/06/15 - 12:40pm
Some suggestions:
For me it's clear that this benchmark is biased and I stopped looking into the source code...
michelle211 cannon replied on Mon, 2009/06/15 - 1:08pm
Ted Goddard replied on Mon, 2009/06/15 - 5:44pm
The load tests described in the article do not recreate actual browser interaction. The author's intent is to simulate 50 events for each of 1000 users, but due to the simplicity of the JMeter test case (50 identical GET requests for each virtual user), something very unusual is being simulated and the different frameworks react in different ways.
For instance, in real-world browser interaction, the user would not normally open the same page simultaneously in 50 browser windows (corresponding to 50 identical GET requests); but they might interact with the application 50 times via form submission or they might refresh the window 50 times. ICEfaces distinguishes between single and multiple window push applications, so the different cases are important: in actual browser interaction, the page reload case is handled through a view-disposal message sent from window.onunload(). Of course, the JMeter test case does not take this into account (it does not realistically simulate a browser) and is not testing actual load conditions.
Implementing the test case correctly requires some expertise with JMeter (using regular expressions to correctly propagate the session identifiers and the window identifiers), so rather than go into detail here, the simplest thing is to configure ICEfaces for single-window operation (appropriate, given the fact that the JMeter test is not designed as an Ajax test) by setting "com.icesoft.faces.concurrentDOMViews" to "false" in a web.xml context parameter.
With this configuration, you will find that 1000 "users" run without difficulty in a 400MB heap and respond with a latency of less than 3000 milliseconds, which is the same, or better than the other profiled frameworks.
The conclusion we must draw is that the performance difference is negligible (when tested correctly), so now you should ask yourself why you would use anything but an Ajax framework based on the JavaServer Faces standard.
Robbie Cheng replied on Tue, 2009/06/16 - 1:07am
in response to:
michelle211 cannon
Robbie Cheng replied on Tue, 2009/06/16 - 1:19am
in response to:
Ted Goddard
zodix Moore replied on Tue, 2009/06/16 - 3:01am
Bechmarking is never fair, and usually misleading. After all, applications are so diverse that no single benchmarking can cover them all. However, it does help us to understand a framework more by leaning the test cases and results.
@michelle211 and Ted: Instead of bashing the credits of the benchmarking, why don't you publish your own data and test cases. It will benefit all of us.
Just my two cents.
zodix Moore replied on Tue, 2009/06/16 - 3:14am
in response to:
Ted Goddard
michelle211 cannon replied on Tue, 2009/06/16 - 8:21am
in response to:
zodix Moore
michelle211 cannon replied on Tue, 2009/06/16 - 8:30am
in response to:
zodix Moore
Ted Goddard replied on Tue, 2009/06/16 - 10:41am
in response to:
Robbie Cheng
Ted Goddard replied on Tue, 2009/06/16 - 11:00am
in response to:
zodix Moore
Stephen Maryka replied on Tue, 2009/07/07 - 11:58am
in response to:
Ted Goddard
As Ted suggested we would, I have provided a follow-up article with corrected results for ICEfaces here.
Steve
prabhat jha replied on Wed, 2009/07/22 - 12:33pm
I just did a quick test to verify the validity of following for Test Application 1:
RichFaces:
- More than 1 seconds response time when 500 concurrent threads.
- More than 3 seconds response time when 1000 concurrent threads.
I got an average response time of < 100ms for 1000 concurrent threads. I did no JVM or Tomcat 6 tuning other than what's mentioned in this article.There could be difference between hardware and network speed but even then it's hard to fathom how there could be a difference of 2.9 seconds on a reasonable server and network setup. I will post the details in another blog at http://sensiblerationalization.blogspot.com/