JSF 2 performance ?

Can JSF 2 / Facelets used in high volume sites because of it's high resource (memory) consuption ?
Or is the problem with third party libs ( RichFaces, ICEFaces, ...) ?
What are the best practices to avoid resource consumption ?
The seems to be various results about this matter for ex the following gives quite good resulsts to JSF Sun RI:
http://developers.sun.com/learning/javaoneonline/2008/pdf/TS-6517.pdf

This document describes performance tuning techniques using JSF and JBoss Seam - the information within however can be quite an eye opener even if you do not use JBoss Seam.
[http://www.jsfcentral.com/articles/speed_up_your_jsf_app_1.html|http://www.jsfcentral.com/articles/speed_up_your_jsf_app_1.html]
Part 2 focusses mostly on JSF and Richfaces.
[http://www.jsfcentral.com/articles/speed_up_your_jsf_app_2.html|http://www.jsfcentral.com/articles/speed_up_your_jsf_app_2.html]
Can JSF 2 / Facelets used in high volume sites because of it's high resource (memory) consuption ?I've never noticed high memory consumption in JSF really. In any case with high volume sites the resources become quite academic - you don't have enough? Put more in the server. Not physically possible to do that? Then it is time to load balance across multiple hosts.
The solution is not in the technology used because the differences there will not win you the war, it is completely in the hardware you run the technology on (and some optimization where needed).

Similar Messages

  • JSF Performance and very intensive UI systems

    I'm concerned about what is the performance of JSF comparated with the same implementation but with JSP and HTML UI?
    It's JSF a good choice if my system is a very intensive ui?
    Please, tell me about what does you think?

    Has anybody done a study comparing JSF performance to JSF and Struts performance?
    I'm afraid that JSF is imposing performance hit on our application of an order of magnitude or more than similar UI code written in Struts.
    I agree with the previous comments that JSF performance is much slower than JSP. The JSF implemention that I'm working on [MyFaces] is clearly loaded with performance problems. For example, there's object creation all over the place in the table component as it coerces the data from one form into another.
    I've also looked at doing my own implementation of the components that are giving me problems. The problem with that is that coercion is forced by the way the JSF specifiction was written. I never had to this much data conversion when writing Swing applications, why isn't JSF designed similarly to Swing?
    JFA

  • JSF 1.1 performance, especially UIData and Data Table

    Hi,
    Does anybody have any JSF 1.1 (Sun reference implementation) performance experiences to share? I am currently looking at the data table component and the use of UIData. Initial observations are an incredible amount of memory is churned during rendering the data table, with the following classes culprits:
    java.util.HashMap$KeyIterator
    javax.faces.component.UIComponentBase$ChildrenListIterator
    java.util.AbstractList$Itr
    char[]
    java.util.ArrayList
    javax.faces.component.UIComponentBase$FacetsMapKeySetIterator
    javax.faces.component.UIComponentBase$FacetsMapKeySet
    javax.faces.component.UIComponentBase$FacetsMapValues
    javax.faces.component.UIComponentBase$FacetsAndChildrenIterator
    To render 50 rows with 10 columns (each column only having a simple outputText component) I'm seeing 1.3Mb memory churned and 0.8 seconds processing time.
    To rener 100 rows with same columns and components I'm seeing nearly 2Mb churned and 2 seconds processing time.
    UIData.setRowIndex is a large culprit.
    I'm really after finding out your experiences on JSF performance and its scalability.
    Any help here is appreciated.
    Thanks - JJ

    Hi,
    Does anybody have any JSF 1.1 (Sun reference implementation) performance experiences to share? I am currently looking at the data table component and the use of UIData. Initial observations are an incredible amount of memory is churned during rendering the data table, with the following classes culprits:
    java.util.HashMap$KeyIterator
    javax.faces.component.UIComponentBase$ChildrenListIterator
    java.util.AbstractList$Itr
    char[]
    java.util.ArrayList
    javax.faces.component.UIComponentBase$FacetsMapKeySetIterator
    javax.faces.component.UIComponentBase$FacetsMapKeySet
    javax.faces.component.UIComponentBase$FacetsMapValues
    javax.faces.component.UIComponentBase$FacetsAndChildrenIterator
    To render 50 rows with 10 columns (each column only having a simple outputText component) I'm seeing 1.3Mb memory churned and 0.8 seconds processing time.
    To rener 100 rows with same columns and components I'm seeing nearly 2Mb churned and 2 seconds processing time.
    UIData.setRowIndex is a large culprit.
    I'm really after finding out your experiences on JSF performance and its scalability.
    Any help here is appreciated.
    Thanks - JJ

  • Faces Performance vrs Struts

    In evaluating JSF's, I put together a simple customer maintenance application of about 10 screens, first using Struts and then again using JSF's, matching the UI exactly. To measure relative performance between these two technologies, I isolated 3 relative static pages from each and ran individual JMeter benchmarks against them (just cycling between these 3 pages over and over). The struts implementation is approximately 5 times faster (measured in pages/sec) over faces. My question is this the same observation most have seen so far (faces vrs struts)? I understand faces is new and will continue to improve. I am using the lastest snap of faces 1_1_01. I welcome any comments.

    This is a slow moving thread, but the issue stills seems to be hanging around. I got similar results current technology.
    I grabbed the attachments from the original performance bug https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=3 and ran some JMeter tests against the "JSP only" and the JSF versions.
    The pages are really simple, the JSP version outputs a page which is visually identical to the JSF page. The table in question had 10 columns and 50 - 200 rows. Not a huge amount of data. I used MyFaces 1.1.3 as the JSF implementation and ran the test in JBoss 4.0.4 GA running on JDK 1.4.2.
    Here's the results:
                   Table Rows   Average [ms]  Median [ms]   Hits / Min   Samples
    JSF Testcase    50           36            30            1300         5007
    JSP Testcase    50           14            10            4030         5001
    JSF Testcase    100          56            60            1050         5001
    JSP Testcase    100          21            20            2700         5001
    JSF Testcase    200          100           100           590          5001
    JSP Testcase    200          26            30            2170         5001 This data confirms the discussion original JSF bug. The JSF version started out nearly three times slower than the JSP page. The relative performance of the JSF version degraded to nearly four times slower as table rows were added.
    So if you are thinking about adopting JSF you should be aware of the performance hit and make sure that you can architect around the problem or get the performance benchmarks adjusted. Perceived performance is important in real life projects so it's more than a theoretical problem.
    I'd also like to know if anybody has ideas or code samples that make JSF perform better?

  • Jsf a good framework for production?

    Trying to decide on jsf as a framework. Could someone help me with some answers to the followign questions:
    1.How is JSF performance in production?
    2. Is there a way to avoid Repost Dialog on refresh/back button?
    3. Any issues with SSL (back button on SSL)
    4. Does 2+ Windows with same session interfering with each other�s state ?
    5. Any real World Examples? Ang big production sites using jsf(any with high volume hits?
    6. Is there any Annotation support to help with the xml config generation,etc?

    Trying to decide on jsf as a framework. Could someone help me with some answers to the followign questions:
    1.How is JSF performance in production?
    2. Is there a way to avoid Repost Dialog on refresh/back button?
    3. Any issues with SSL (back button on SSL)
    4. Does 2+ Windows with same session interfering with each other�s state ?
    5. Any real World Examples? Ang big production sites using jsf(any with high volume hits?
    6. Is there any Annotation support to help with the xml config generation,etc?

  • Faces-config

    I have a page with a submit button that I want to open a pdf file. In my backing bean, I have:
    public String submit() {
              return "download_coupons";     
         }In my faces-config.xml file I have:
    <navigation-rule>
              <from-view-id>/coupons.jsp</from-view-id>
    <navigation-case>
              <from-outcome>download_coupons</from-outcome>
              <to-view-id>/images/online_cpns.pdf</to-view-id>
         </navigation-case>
    </navigation-rule>
    When i submit my page, I get a 404 error. Can I go to a pdf file this way?
    Thanks

    Have you tried <redirect /> inside of your navigation rules?
    JSF performs an HTTP redirect and calls
    responseComplete() on the FacesContext
    instance for the current request. So <redirect/> produces
    a non-faces response.

  • Using redirect /

    Hi,
    I tried using the <redirect />-Tag in the faces-config.xml. The result is,
    that a page, which was the result of an post request, is "changed"
    to a page, which was the result of an get request.
    I also understand the post/redirect/get-Pattern, which was used
    behind that. But what exactly happens in jsf, when I use the <redirect />-Tag?
    Thanks,
    Andy

    Hi Andy
    as i understand, JSF performs an HTTP redirect and calls
    responseComplete() on the FacesContext instance for the current request.
    Cheers,
    Matthias

  • SelectOneMenu valueChangeListener with onchange=

    Can anyone provide some insight into what I'm getting when using both valueChangeListener with onchange="submit()"? Both are needed in my app to cause a form change when a selectOneMenu item is selected.
    After the page is initially loaded and making a menu selection, the selected menu item does not show and no action occurs. Watching the backing bean code, the listen method is not even called. Everything works as expected the second time a menu selection is made.
    When the onchange="submit() statement is removed, the first menu selection will show in the menu, but, of course, the action upon value change does not occur.
    Now I understand that JSF performs lazy instantiation and wonder if this is involved. But the menu choices are available for selection after the page loads, it's the listen method that doesn't get called the first time.
    This is my selectOneMenu code:
    <h:selectOneMenu id="locationSelection"
      valueChangeListener="#{SelectBean.onLocationChange}"
      onchange="submit()" >
      <f:selectItems id="locationSelects" value="#{SelectBean.locationSelects}" >
    </h:selectOneMenu>

    Likely you misunderstood the valueChangeListener and you was expecting some client-side magic. Wrong. JSF is fully server-side and the valueChangeListener definies a server-side method which should be invoked if the form is being submitted. If you want to submit the form automatically on change of the selection, then you indeed need to add onchange="submit();" attribute, which just adds a piece of Javascript (client-side scripting language) defining a Javascript method to submit the form when the selection has changed.

  • Navigation Pane Action Issue

    Im using JDeveloper 12c Studio Edition Version 12.1.2.0.0
    When i click on a link of the navigation pane the url does not get updated until i click it for the second time.

    It is expected behavior because JSF performs postback, i.e. the page submits to itself (to apply the ADF/JSF page lifecycle) and then the ADF/JSF controller forwards internally to another page in a case of navigation. The browser displays the URL it has submitted to (i.e. the URL of the current page, because of the postback approach). If you want the browser to show the correct URL, you should configure the target page's taskflow View activity with Redirect=true.
    Dimitar

  • JSF 2.0 Performance - Build View on postback

    Hi,
    we are currently looking at JSF 2.0 and it seems as if on every postback a buildView is executed instead of a restoreView, as it was the case with JSF 1.2. This unfortunately seems to have quite an impact on performance in regards to memory consumption and runtime. Is there a way to get back to the "old" JSF 1.2 behavior by setting a flag or something similar? Until now, we could not find such an option.
    Thanks and regards,
    Michael

    Set the javax.faces.PARTIAL_STATE_SAVING context init parameter to false.

  • ADF-JSF: Application Performance Issue

    Hello!
    My question or set of questions will be a bit vague...I am simply not sure where to look for problem(s). So here is what I have. Application implemented with ADF-JSF (JDEV ver:10.1.3.2.0). It basically has 5 pages. Each page containes user input form, commandButton and result table. Functionally, each page is a 'search page' that returns results based on what user specified in the form. Components on each page are bound to VO that is based on EO (DB table). Tables have at least 2.5M records up to 16M. Certain indexes exist (for most common searches) to improve the performance. However, there have been performance issues found and largely they would be grouped into the following:
    1. User is on page A, performs the search, goes to page B (via link) and performs other search, then goes back to A and similar search takes much longer to return results. Seems to me that this moght be related to memory. Maybe results of the previous search are cashed and it takes new search to retreive results longer as the VO cashe needs to be cleared first. Does that make sense?
    2. User is on page A and then goes to B. Leaves browser for 10-20 minutes and tries to go back to A. It takes up to a minute before page reloads with the previously displayed results. I am thinking this has to be related to page lifecycle where AM tries to re-execute bindings ( I do not think it is passivation issue though). What is the best practice to control the lifecycle?
    Any pointer on where to look for the solution is very welcome.
    Rade

    Carl,
    To use Tom Kyte's analogy, you are firing a gun into a room full of people hoping to hit the bad guy. You haven't seemed to have gotten any information about where the performance issues lie. It could be in the DB, network, ADF Business Components, JSF layer, other stuff monopolizing resources, etc, etc. I have ADF BC apps developed in 10.1.3.3 that run quite well.
    So, I would recommend you spend some time investigating where the performance problems lie. Try turning on logging output, check machine utilization - use your investigative techniques to find the bad guy so you can then work on fixing him.
    John

  • JSF 1.2 performance is not adequate

    Sun JSF developers...
    JSF 1.2 performance is not adequate.
    Here is a simple use case to prove:
    Render a table with ~100 columns and ~1000 rows (with facelets)
    (you could increase the numbers to stress test)
    using h:dataTable tag.
    You have to repeat h:column hundred times in XHTML (to create bigger
    UI component tree).
    Have a backing bean with 100 properties and JSF action which returns
    list of 1000 those beans.
    In this case there is no DB interaction, no back-end involved.
    Have your application set up with Ajax4Jsf (so it goes via its filter). You could
    also compare the results with and without it.
    Measure RENDER RESPONSE phase, and overall response time.
    Compare with JSP which renders same table from same bean.
    This is very simple test case to write and you will see that JSF in current state is really slow.
    This test could also be used to measure performance of new versions to see where they stand.
    It would be also interesting to see how render time grows with increase of
    number of columns (number of components in UI tree) (Is it linear or not?)
    How fast does it grow with the number of rows (Is it linear growth with increase of data size?)
    I believe this type of tests should be standardized before each release.
    Does JSF development team perform regular profiling of JSF RI java code?
    Running profiling for this use case could also reveal interesting things which
    could be improved.
    Regards,
    --MG                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                   

    But you have done nothing here to determine if itscales linearly or not.
    See below.
    You increase number of columns (rows) and measure
    time.
    When you draw on a chart how time grows with increase
    in number of columns (rows) you will see if it linear
    or not.
    I understand how to determine the growth rate; I was merely pointing out that you have only claimed to run one test and one cannot determine the growth rate from that.
    It would be also interesting to see how render timegrows with increase of
    number of columns (number of components in UI tree)(Is it linear or not?)
    How fast does it grow with the number of rows (Isit linear growth with increase of data size?)
    Unless you are talking about spreadsheets I doubtthese apps are useful.
    They are very useful.I bet they would be more useful as native desktop apps.
    >
    But this is besides the point; my point is that thescenario of having a large number of components on a
    page does not occur often in real applications.
    Really? You are not serious?Yes I am serious. I can see we have different perspectives here.
    >
    A much more common performance scenario is highload.
    This is separate story. I'm talking about latency of
    loading one page.
    Please do not confuse latency and bandwidth.I am not talking about bandwidth but throughput.
    >
    BTW most of the web sites have small number of
    concurrent users,
    so the most common scenario is actually exactly
    opposite.
    Low load but complex pages with lots of components on
    them.Again, I can see we have different perspectives here. My experiences are the opposite.
    >
    So your results will be much more useful if youinclude a load test on a moderately sized page. I'm
    not dismissing your original test as invalid or
    useless.
    My results are more useful than what you are
    proposing, as they help to pinpoint the cause of
    latency. You could run my test with profiler and
    investigate the root cause of it.You do not need to increase the number of components on the page to numbers beyond practice in order to determine this. It is sufficient to run profilers on average pages many times and determine where the most time is spent. In fact, your approach may result in an implementation optimized for pages with a large number of components but not for pages with a lower number of components.
    >
    My point is that the user experience is not degradedby the performance but by the poor presentation of
    information. Many web browsers to not take kindly to
    such large tables as well.
    With JSF user experience is degraded by performance.I'd like to see your numbers and the code you used.
    JSF makes it easier
    to do nicer user presentation, but performance
    suffers to degree that it is not usable in number of
    cases.
    JSF inability to generate page fast on server side
    has nothing to do with browsers.Correct; but I was talking about pages with large tables in general and why they are a bad idea for web applications. A native application is more appropriate. But this is orthogonal to the purpose of this thread.
    >
    Again, you are missing the point. Perhaps JSFperformance differs between the application servers.
    A fair and useful test will determine that. I'm not
    talking about the relative performance vs JSP here.
    If JSF does things inefficiently in its code it will
    show consistently bad results
    across all app servers. Again my test is to detect
    and pinpoint JSF inefficiencies and not app servers
    ones.
    Don't you think JSF developers would want to look for
    it first rather than investigating why it perform
    badly on some particular app server because of
    its internal reasons.I'm approaching this from the perspective of a developer evaluating whether to use JSF and which application server to use. This is very useful from this point of view.
    As far as the JSF developers go, as I noted above one does not need to scale out the number of components on the page to determine performance bottlenecks in the implementation. An average case is more appropriate.
    Also, if you are going to compare JSF to other technologies you need to try a variety of platforms for both. Some application servers might do JSP better than others. If you limit yourself to one platform you run the risk that it is skewing the comparison one way or another.

  • Is it possible to use a JSF Validator to perform a Dependency validation?

    I'm new to JSF, but getting more and more experience everyday. I've create some custom validators for a few input fields on my form and they are working beautifully. What I can't figure out is how to write a validator that will check a field for a value based on another fields value. For instance, I would like to require a person to enter an address if they select a Yes / No select box indicating they would like to supply an address.
    Does anyone know how I can do this? I've come up with a clunky work around by performing my dependency validations in my action page rather than a validator.
    Thanks!!!!

    Hi RaymondDeCampo.
    I have never been a big fan of how JSF (and even Struts)handle forms both in the front (the view) and the back.
    Forcing the developer to contend with writing a java class for each thinkable form does not look like a workable pattern to me. And tying the view (JSP or JSF page) tightly to the form classes and validators is also cumbersome.
    In many decent applications, the number of forms grows to more than a tiny handful and so would the number of classes that simply act as dummy data carriers.
    I do not see why I should have to maintain all the accompanying classes and validators and JSP code that each form comes with. Making changes to the structure of a form (say adding new fields or removing others, or even adding whole form pages into the sequence), modifying the model of a form (like renaming fields, adding new validation rules), or changing form view (e.g. switching from a list of checkboxes to a select dropdown, changing how and where error messages are presented, supporting a new language) are just some of those things that become tedious to maintain sentrally.
    No other model of building forms out there makes the named tasks any simpler, aprt from adding a new level of complexity to the simple data collection purpose of web forms. Well, except Formular. I have had Formular working in JSF and Struts although I ended up ditching the JSF way of handling forms altogether.
    I prefer good and solid separation of form components as outlined by Formular. Formular is the only API out that would allow me to migrate my forms from any Java web server to another without having to rewrite a line of code. Try upgrading your Struts form to JSF or vise versa and you'll get the idea of why I dropped the more hardwired way of coding web forms.
    With Formular, I have created a repository of validators (for doing my form checks). datasources (for populating lists, radios, checkboxes, and combos), and styles (for laying out my form elements). Making modifications to my repositories, I can do site-wide changes without touching my JSPs or Java classes. I can move form messages from the top of ALL my forms and place them just above the offending fields in one single style file, I can swap the markers on optional fields and use them only on required fields if the business manager wants to in a single go, I can even change validation rules that are attached to several fields in different web forms at one instance (how many hours did we save when one client wanted all buttons in the site changed to GIFs and all phone and address fields in their application and survey forms validated a little different?)
    Ack! Now It looks like I'm preaching, again so I'll hold myself.

  • Major performance bottleneck in JSF RI 1.0

    We've been doing some load testing this week, and have come up with what I believe is a major performance bottleneck in the reference implementation.
    Our test suite was conducted two different application servers (JBoss and Oracle) and we found that in both cases response time degraded dramatically when hitting about 25-30 concurrent users.
    On analyzing a thread dump when the application server was in this state we noticed that close to twenty threads were waiting on the same locked resource.
    The resource is the 'descriptors' static field in the javax.faces.component.UIComponentBase class. It is a WeakHashMap. The contention occurs in the getPropertyDescriptors method, which has a large synchronized block.

    Well not the answer I was hoping for. But at least that's clear.
    Jayashri, I'm using JSF RI for an application that will be delivered to testing in august. Can you give advice wether I can expect an update for this bottleneck problem within that timeframe?
    Sincerely,
    Joost de Vries
    ps hi netbug. Saw you at theserverside! :-)

  • Performance of JSF and HashMap

    Using Java profiler I've noticed that with large number of components on the page time of HashMap.put calls plays significant role.
    Is there a way to control initial capacity of hash maps in Sun RI?
    Does Sun RI tries to set initial capacity and load factor in the code?
    Per Java 5 API docs:
    An instance of HashMap has two parameters that affect its performance: initial capacity and load factor. The capacity is the number of buckets in the hash table, and the initial capacity is simply the capacity at the time the hash table is created. The load factor is a measure of how full the hash table is allowed to get before its capacity is automatically increased. When the number of entries in the hash table exceeds the product of the load factor and the current capacity, the capacity is roughly doubled by calling the rehash method.
    It would be nice if JSF RI could guess more appropriate capacity and load factor to minimize performance impact on extensive HashMap.put() calls.
    Thanks

    This is an example of what I was talking about in the other thread. I was saying that if you use an unusual page as the basis for your performance tests, you will end up optimizing for the extreme case at the expense of the normal case. If changes are made in this area care must be taken not to cater to the extreme at the expense of the usual.
    If the implementation starts with a higher capacity in the map initially, that means more memory is being used. If the capacity is optimized for pages with large numbers of components, the memory is wasted.

Maybe you are looking for