-
1. Re: Richfaces Performance 3.3.2
ilya_shaikovsky Feb 1, 2010 4:24 AM (in response to smuthu.14)1 of 1 people found this helpfulDo 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
smuthu.14 Feb 1, 2010 4:59 AM (in response to ilya_shaikovsky)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
nbelaevski Feb 1, 2010 5:57 AM (in response to smuthu.14)Hi,
Can you please provide some more information on performance measurement technique used and more detailed results?
-
4. Re: Richfaces Performance 3.3.2
smuthu.14 Feb 1, 2010 6:58 AM (in response to nbelaevski)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-
richfaces-page-time-split.xls 42.5 KB
-
-
5. Re: Richfaces Performance 3.3.2
ronanker Feb 1, 2010 7:02 AM (in response to nbelaevski)1 of 1 people found this helpfulHi,
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
smuthu.14 Feb 1, 2010 7:14 AM (in response to ronanker)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
vfarina Apr 23, 2010 8:15 AM (in response to smuthu.14)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
nbelaevski Apr 23, 2010 4:59 PM (in response to vfarina)Veronica,
Try configure GZip compression for script files.
-
9. Re: Richfaces Performance 3.3.2
henk53 Apr 24, 2010 6:00 AM (in response to smuthu.14)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
vfarina Apr 26, 2010 4:53 AM (in response to henk53)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 Apr 26, 2010 5:59 AM (in response to vfarina)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
vfarina Apr 26, 2010 11:35 AM (in response to ilya_shaikovsky)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 Apr 27, 2010 5:30 AM (in response to vfarina)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
maxwell998 Apr 30, 2010 3:55 AM (in response to vfarina)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?