JSF2 - Benchmark datatable

In this article I will bench the datatables of 3 JSF2 components frameworks :

• Icefaces 2
• Primefaces
• Richfaces

I will focus on efficiency : page size, ajax request/response size, server load, and not on features.

Test setup

The datatable will display a list of books with 3 columns : ISBN, author and title. The datable is binded to an ajax paginator which display books 15 by 15.

Dependencies version:

• Icefaces 2.0
• Primefaces 2.2.1
• Richfaces 4.0.0M6
• Mojarra 2.0.3
• Jetty 7.2.2

No specific configuration is set.

JSF Fragments

Icefaces

Primefaces

Richfaces

Page size benchmark

I'm measuring the page size and the ajax response size with HtmlUnit. Creating an unit test with HtmlUnit is quite simple and I did not met issue requesting Icefaces, Primefaces and Richfaces for the purpose of this article.

Page size

Icefaces page size is huge, very huge. Icefaces and Richfaces don't used minified JS. Richfaces can gain 80KB by using JQuery min and be below 200KB.

All Primefaces JS are minified.

Ajax Response size

Richfaces Ajax Response

Icefaces Ajax Response

Primefaces Ajax Response

Icefaces and Richfaces send the paginator and the table. The table contains ids and classes on all cells. The Icefaces paginator block is quite big, more than the datatable block.

Primefaces sends only the table. The paginator is updated on the client side. The table contains ids and classes only on rows.
But what if the data changes on the server side (delete or add) ? An user action on the paginator doesn't update it. It seems to be bugged.

Knowing that I put an id only on the components i needed to update that means JSF autogenerate the other Ids by itself. So the question is, why does it do that when we don't need them?

Server load

I have created a simple unit test which executes 10 concurrent threads with a cookies manager.

Test setup : Core 2 Duo 3Ghz 64bits, 2GB dedicated to the JVM.

Average response time

• Icefaces : 36.5ms
• Primefaces : 13.8ms
• Richfaces : 25.2ms

You can basically have three time more users with Primeface than Icefaces (considering it is growing lineary)

Because Icefaces OOM my JVM very quickly without a cookie manager I did a very simple calculation on session size. I took the JVM memory consumption and the number of requests done :

• Icefaces : 7800 requests ~1.8GB : ~230KB
• Primefaces : 9400 requests ~900MB : ~100KB
• Richfaces : 9400 requests ~900MB : ~100KB

Conclusion

The page used for the test is quite simple and does not reflect a real page nor the global performance of these frameworks. To be complete the generic components (tab, tree...) have to be tested too in order to make a robust conclusion.

Primefaces has the best datatable implementation although buggy (I hope Primefaces 2.2 will correct all the issues). Icefaces has clearly the worst performance on datatable on all test. Richfaces is between Primefaces and Icefaces closest to Primefaces.

if a winner should be decided it would be Richfaces since I have been quite disappointed by Primefaces [1].

Dear Icefaces, Primefaces and Richfaces users, if you see some improvements please post a comment.

The project is available on github.


Thanks Mathieu for correcting the spelling of the article! ;)


[1] Post on Primefaces forum that is quite revelent :
I also hope that 2.2/2.3 focuses more on fixing up bugs and making the component library more useable in general. Once you start to use the components in PrimeFaces for things other than trivial showcase examples you quickly run into a lot of problems and limitations (I'm grateful for PrimeFaces, but thought I would provide a little constructive feedback).