1 2 Previous Next 17 Replies Latest reply: Mar 26, 2012 12:48 PM by Tushar Apshankar RSS

Richfaces Performance 3.3.2

Muthu Kumaran Newbie

We are having our Application using JSF+Richfaces framework and it is running on JBoss Application Server. The web page runs on IE 7 browser.

 

We have a NFR requirement that All the pages should be loaded within 4 seconds.

 

The pages are getting responded in 1-3 seconds in the production environment. But still rendering the page in IE 7 takes lot of time( > 15 seconds). We are using some of richfaces components. When we did the response time and rendering time analysis, we found lot of time is spent on the javascript execution.

 

 

Script Loaded/executed during page Load

Type

Time in msec

Richfaces   Menu x 50 instance

Richfaces

6000

Richfaces   Calendar x 8 instance

Richfaces

1037

Richfaces   Model x 10 instance

Richfaces

1012

Richfaces   File Upload x 1 instance

Richfaces

500

Richfaces   Framework script - loading Framework + UI component js Load

Richfaces

400

Richfaces   Data scroller x 7 instance

Richfaces

246

Richfaces   Suggestion Box x 3 instance

Richfaces

180

Richfaces   Toggle Panel x 5 instance

Richfaces

166

Richfaces   Tab Panel component x 1 instance

Richfaces

92

Richfaces   Progress Bar x 1 instance

Richfaces

50

 

Please let know how to reduce the javascript execution during page load for menu, calendar and modal panel.

 

 

  • 1. Re: Richfaces Performance 3.3.2
    Ilya Shaikovsky Master

    Do you using extendedDataTable component? If so - yes it's menus not optimized even in latest versions and takes many time to be initiated. So you could try to turn them off and if the results will be satisfiable - it seems that it would be better to implement them by implementing dynamic single context menu.

  • 2. Re: Richfaces Performance 3.3.2
    Muthu Kumaran Newbie

    Hi,

    We are not using the extendedDataTable in our project.

    We are using Richfaces menu with the tool bar. For creating each menu item, it takes more than 100 ms. When we drill down the menu creation flow, we found lot of DOM update taking time on IE7.

     

    We are facing the same issue with Calendar and modal panel also. Do you have any pointers for improving this.

     

    We will also try implementing ajax loading of the menus.

     

    Thanks and Regards

    Muthu kumaran.S

  • 3. Re: Richfaces Performance 3.3.2
    Nick Belaevski Master

    Hi,

     

    Can you please provide some more information on performance measurement technique used and more detailed results?

  • 4. Re: Richfaces Performance 3.3.2
    Muthu Kumaran Newbie

    Hi,

    We are using Fiddler and DynaTrace tool for analysis the page download time and javascript profiling.

    Please refer to the attachment excel for time taken by each script.

     

    Regards

    Muthu kumaran.S
  • 5. Re: Richfaces Performance 3.3.2
    Kerdudou Ronan Apprentice

    Hi,

     

    We add a lot of performance problems with IE and rich:calendar initialisation while embeddd in several datatable rows.

     

    The use of http://www.jroller.com/a4j/entry/richfaces_calendar_component_shared_calendar heped us a lot.

     

    Hope this will help.

  • 6. Re: Richfaces Performance 3.3.2
    Muthu Kumaran Newbie

    Hi,

    Thanks.

     

    Yeah we tried this, it helped in reducing the page load time upto 2 secs. The results which i shared previously does not include this change.

     

    Regards

    Muthu kumaran.S

  • 7. Re: Richfaces Performance 3.3.2
    veronica farina Newbie

    Hello,

     

    I have just read your post and I will say that we have exactly the same problem than you. Our website has to be fast and, using RichFaces we really have performance issues (above all on IE7).

     

    We already improved a lot our site building Richa JS customized (using the maven plugin), decreasing the number of RichFaces components, symplifying our pages, etc. But is still not enough.

    Mainly, we are using: suggestionBox, calendars, dataTables and dataScroller from RichFaces. The JS for those components is very heavy (400KB) and, the difference between loading the JS and not is around 500 ms (that for our web site is a lot).

     

    Have you got better performance since your last post? Do you have some ideas?

     

    Thanks a lot for your help!

     

    Vero.

  • 8. Re: Richfaces Performance 3.3.2
    Nick Belaevski Master

    Veronica,

     

    Try configure GZip compression for script files.

  • 9. Re: Richfaces Performance 3.3.2
    henk de boer Master

    Muthu Kumaran wrote:

     

    We are facing the same issue with Calendar and modal panel also. Do you have any pointers for improving this.

     

    We're having the same problems. Personally I love the modal panel, but its performance is really sub par. If you hide the panel when rendered and then show it via javascript, it's not that bad, but when you display it when rendered you can see the thing being build.

     

    In our app, our UI is modeled such that the content the modal panel displays depends on which selection a user makes. We therefor can't really render it initially hidden. Via AJAX it's indeed possible to hide the latencies a little for the user, but that still doesn't take away the fact that the dialog is just really slow.

     

    The latest modern browsers (Firefox, Safari, Opera) have massively improved their Javascript performance, but for some reason the dialog's performance hasn't gotten a lot better. I don't even dare to look at IE7 really...

  • 10. Re: Richfaces Performance 3.3.2
    veronica farina Newbie

    Hello,

     

    Well, our performance issue is en general with the RichFaces JavaScript. The difference between loading the RichFaces JS and not is around 500ms.

     

    We already use Gzip + JSMin to reduce as much as possible the JS. In fact, the JS size transferred with Gzip is around 90KB but, the problem seems to be on what is executed when the file is loaded.

    The Calendar workaround that you mentioned on this  post could help us a little bit, but I really don't like the idea of changing the JS offered by RichFaces, is not maintenable.

     

    Some questions:

     

    1. It is the JS file evaluated in each request? We noticed that the "evaluated" function takes time in some requests (above all on IE7).

    2. Could we save some time putting in place the NEKO parser? As far we understand the neko parser we'll have an impact on the AJAX requests but not in the time spent to load the JS.

     

    Thanks a lot for your help!

     

    Regards,

     

    Vero.

  • 11. Re: Richfaces Performance 3.3.2
    Ilya Shaikovsky Master
    2. Could we save some time putting in place the NEKO parser? As far we understand the neko parser we'll have an impact on the AJAX requests but not in the time spent to load the JS.

    for sure. It will save lot of time which spent for responce parsing. Also please pay attention to forceparcer parameter. But using NEKO or NONE you should care more about having your markup w3c complaint.

  • 12. Re: Richfaces Performance 3.3.2
    veronica farina Newbie

    Hello Ilya,

    Thanks for your help.

     

    I put in place NEKO but I haven't noticed any important impact on the performance. And, sincerely, I am not sure that is parsing all requests.

     

    The versions are:

    RichFaces 3.3.0

    nekohtml 1.9.14

     

    Our web.xml config is:

     

    ...

    <filter>
    <display-name>RichFaces Filter</display-name>
    <filter-name>richfaces</filter-name>
    <filter-class>org.ajax4jsf.Filter</filter-class>
    <init-param>
    <param-name>forceparser</param-name>
    <param-value>false</param-value>
    </init-param>
    <init-param>
    <param-name>enable-cache</param-name>
    <param-value>true</param-value>
    </init-param>
    </filter>

     

    <context-param>

       <param-name>org.ajax4jsf.xmlparser.ORDER</param-name>

        <param-value>NEKO</param-value>

    </context-param>

     

    <context-param>

            <param-name>org.ajax4jsf.xmlparser.NEKO</param-name>

            <param-value>.*\..*</param-value>

        </context-param>

     

    ...

     

     

    Should the <a4j:log> display information about what is parsed by NEKO?? I would like to be sure if it's applied on all  AJAX requests.

     

    Thank you!

     

    Vero.

  • 13. Re: Richfaces Performance 3.3.2
    Ilya Shaikovsky Master
    RichFaces 3.3.0

    I highly recommend to try 3.3.3.Final. We made much optimization works after 3.3.0 release.

  • 14. Re: Richfaces Performance 3.3.2
    Max well Newbie

    Hi, Veronica  farina,

    I have the same performance problem caused by Richfaces.  I have ever tried to use the NEKO parser in Richfaces application, but the performance bottle-neck is still exists.  Besides Menu, datatable, Calendar etc. Richfaces components,  The Ajax4JSF POLL component's performance which is refreshed with interval 1000 is very slow.  Do you have any opinion?

1 2 Previous Next