4 Replies Latest reply on Jul 20, 2008 7:31 AM by wildrook

    RichFaces vs. Icefaces in production environment

    mhalmann

      Last 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!

        • 1. Re: RichFaces vs. Icefaces in production environment
          tedgoddard

          Could you point out some of the Ajax features in this application?

          • 2. Re: RichFaces vs. Icefaces in production environment
            brianaticesoft

            Mhalmann,

            I am sorry to hear about your troubling experience with ICEfaces. Most users of our Seam integrations have been very successful and the vast majority of our users have not reported any troubles whatsoever with scaling. We have had several customers contact us indicating vastly different results from what you are reporting in you post.

            If I recall correctly we did have one or two tech calls with you regarding scalability challenges you were facing with your application. In the quick review we did, I am pretty sure we had identified several sources for potential improvement in terms of application structure and best practices etc. and we were reasonably confident that we could help you resolve your issues with a couple of days of consulting services. At the time you had expressed no interest in engaging with us and were confident in your ability to resolve the issue on your own. Its unfortunate that you had to spend the several weeks of additional engineering time that you mentioned to no avail. We would have liked to have helped.

            In any event it sounds like you finally found a solution that works for you and your particular application, which is great. Best of luck.

            Brian McKinney
            President
            ICEsoft Technologies Inc.

            • 3. Re: RichFaces vs. Icefaces in production environment
              pradeep123

              Great post mhalmann. I wish we can have more such comparative analysis.

              It's possible for individual circumstances to be vastly different but it definitely helps to be aware of situations under which the comparison was done.

              Kudos to you pal for the posting.

              • 4. Re: RichFaces vs. Icefaces in production environment

                Memory is the general problem of JSF technology, try to reduce number of views per session (com.sun.faces.numberOfViewsInSession for Sun RI), this should help a lot. Another way is to develop your own server state manager and make cache of views for all sessions and views that is not in use save to the disk, this solves your problem at all.