RichFaces vs. Icefaces in production environment
mhalmann Jul 11, 2008 7:42 AMLast year we decided to develop a new portal for echanging real-estate advertisments.
Portal itself is currently located here: http://kinnisvara.soov.ee/
We decided to use JBoss Seam 2.0 and Icefaces 1.7 (latest build from svn) and the Aplication server itself is Weblogic 10 + Oracle 10gR1
Site was launched at the end of January and so far we have been not happy with the stability and the performance of the site.
Usually we do get somewhere around 2500 unique visitors a day, a bit more by now (3500) but the site is slow.
Hardware underneath is 32bit 4g ram 3ghz Xeon for the application server and same goes for the database server.
As You can see the site loads slow and dom updates are slow. It is quite common to get the OutOfMemoryError and we had to make a lot of fixes in order to make things work out at all:
here are the referencing posts by efbiaiinzinz:
are there any tips or tricks to make icefaces perform faster ?
http://www.icefaces.org/JForum/posts/list/7376.page
three human weeks to make the corrections and the memory is still overused.
web.xml property "javax.faces.STATE_SAVING_METHOD" does not have any effect when Icefaces is used:
<ice:inputFile /> fails to work at all with seam when seam ejb-transaction management is on
http://www.icefaces.org/JForum/posts/list/6840.page
<ice:inputFile /> problem
http://www.icefaces.org/JForum/posts/list/6613.page
Two human weeks to correct the issue, had to fix the source code and compile the archives again
Icefaces outputs incorrect html and messes up site looks
http://www.icefaces.org/JForum/posts/list/6630.page
2 days to correct the issue and archive recompile.
is there any workaround to stop dom updates in certain region ?
http://www.icefaces.org/JForum/posts/list/7371.page
2 days to correct and recompile the archive.
So aftes five months of fixing and still not achieveng the result we wished for, we decided to move the whole project to use RichFaces.
We used the latest Richfaces release and whole process took us five weeks and we are now ready to go into production env.
Test version is currently deployed here:
http://soov.matis.homeip.net/soovkv
Yes we had a bit of problems with it, but nothing major. We had to recompile the archive in order to change "" into ""
so the web design would not be messed up.
Main thing, what we wanted to achieved, we made it. The whole site is a lot faster, memory usage is down, a lot.
Now the web.xml property "javax.faces.STATE_SAVING_METHOD" has effect and if client mode is selected, there is absolutely no memory leak.
left search box, where you can select the counties is a lot faster and what is more important, site performs very fast under Internet Explorer 6.
With Icefaces it was a real disaster when Internet Explorer 6 was in use. I perfectly understand that IE6 is old browser but more than 50% of our visitors use the that browser.
Compare those two:
http://kinnisvara.soov.ee/ - live
http://soov.matis.homeip.net/soovkv - test but the internet connection has only 2mb upload, so it might not be that fast in countries outside Estonia.
About the memory (1.8ghz intel core 2 duo, 4g ram, application server and database on same machine, 1gb heap for the JVM):
Loading page search.seam for 300 times, javax.faces.STATE_SAVING_METHOD=client
Icefaces: used memory = 320M, average response time 250ms
Richfaces: used memory = 150M, average response time 62ms
Loading page search.seam for 600 times, javax.faces.STATE_SAVING_METHOD=client
Icefaces: used memory = 450M, average response time 302ms
Richfaces: used memory = 150M, average response time 60ms
Loading page search.seam for 300 times, javax.faces.STATE_SAVING_METHOD=server
Icefaces: used memory = 320M, average response time 255ms
Richfaces: used memory = 165M, average response time 55ms
Loading page search.seam for 600 times, javax.faces.STATE_SAVING_METHOD=server
Icefaces: used memory = 450M, average response time 300ms
Richfaces: used memory = 169M, average response time 55ms
Loading page "Korterid -> Tallinn -> Kõik" copy-paste url, and loading it 300 times, javax.faces.STATE_SAVING_METHOD=client
Icefaces: used memory = 420M, average response time 8775ms
Richfaces: used memory = 150M, average response time 875ms
Loading page "Korterid -> Tallinn -> Kõik" copy-paste url, and loading it 600 times, javax.faces.STATE_SAVING_METHOD=client
Icefaces: OutOfMemory error, did not finish the test.
Richfaces: used memory = 150M, average response time 805ms
Loading page "Korterid -> Tallinn -> Kõik" copy-paste url, and loading it 300 times, javax.faces.STATE_SAVING_METHOD=server
Icefaces: used memory = 420M, average response time 8901ms
Richfaces: used memory = 150M, average response time 650ms
Loading page "Korterid -> Tallinn -> Kõik" copy-paste url, and loading it 600 times, javax.faces.STATE_SAVING_METHOD=server
Icefaces: OutOfMemory error, did not finish the test.
Richfaces: used memory = 150M, average response time 630ms
So the numbers speak for themselves, additionally the whole application is now more stable and gone are the errors such as "javax.faces.FacesException: Expression Error: Named Object: domainValueConverter not found."
In a few days (16. of July to be exact) we are upgrading the live environment and from there on, the site will be using RichFaces.
I am making this post in order to inform the users what they are getting and in my opinion Richfaces seems to be quite nice and stable. Lets just hope, everything works out in the production env and finally we can enjoy much faster and more stable portal. Keep up the good work!