Performance

The following table shows where each cost lands in the request processing lifecycle. A postback walks all six phases; an Ajax request walks them too, but only for the components named in execute (and renders only the ones named in render, see Scope Ajax Requests with Execute and Render); an initial GET builds the view and renders it.

The MyFaces documentation gives a rule of thumb from tests it ran long ago: rendering the response took about 70% of the time Faces itself used, and building the view 15% to 20%, while walking the tree took far less than either. On an Ajax request the build step weighs more the larger the tree is. That is the argument behind view pooling (MyFaces: EL Caching, View Pooling and Other Switches). Treat those percentages as a hint about where to look first, not as a measurement of your application.

Source: Apache MyFaces Core Concepts: View Pooling

The cheapest speed-up is a context parameter (the stages are described on the configuration page). In the Development project stage Faces re-checks every view file on every request so that you can edit a page and reload, shows detailed error pages. None of that belongs on a server that real users use.

Source: Jakarta Faces 4.1 specification, 11.1.3 Application Configuration Parameters and Mojarra 4.1 context parameters

A last measurement for the case you are weighing up. The same three Bookshelf pages (300 components, a 300-row ui:repeat and 300 rows of plain markup, all described in Component Tree Size) were requested 500 times in a loop in each stage. On the loopback interface and with server state, the Development stage was between about 1.2 and 4 times slower than Production on both implementations, and the gap was the largest on MyFaces. The ratio depends on page size and on the file system; the lesson is only that the stage matters.

Source: Mojarra 4.1 context parameters, Apache MyFaces Core 4.1 configuration

Every Faces tag that has a component behind it (h:outputText, h:inputText, h:panelGroup, f:facet children and so on) becomes a UIComponent in the tree for as long as the view lives. The tree is built when the page is first requested and rebuilt, in part, on each postback; every component takes part in every lifecycle phase it is not skipped for, costs memory in the saved state (see State Saving: Partial, Full, Server, Client) and produces markup. Two pages that look the same in the browser can differ by an order of magnitude in tree size.

The Bookshelf scratch app has three pages that print 300 labelled text boxes. They use one binding (#{bulkEditBean.title}) so only the structure differs:

Source: Jakarta Faces 4.1 VDL: ui:repeat and Jakarta EE Tutorial: User Interface Component Model

(bulkEditBean is the view-scoped bean listed in Scope Ajax Requests with Execute and Render.) Measured on the three pages, with the saved state of a fresh GET:

The HTML sizes are with server state (where the state field is 32 to 41 characters on both implementations, a lookup key). Three observations. The tree-html page is the smallest and was the quickest in every timing loop on both implementations, because it creates only the form, the button and the ui:repeat. The tree-forEach page was the slowest in all but one of the loops and is the one JSTL tags are blamed for: c:forEach runs while the view is built, so it creates all those components (see the JSTL page for the correctness side of that choice). And the client state sizes cross over between the implementations: the page with 300 real components has a small state on Mojarra and a large one on MyFaces, while the ui:repeat page is the reverse. I did not investigate why; the practical lesson is to measure the state of your own pages with the implementation you deploy.

What shrinks a tree:

Faces evaluates an expression every time it needs its value: a rendered attribute is read in several phases, the value of a table is read per phase and a getter used in three places on the page is called three times or more. The page that calls #{bean.books} therefore calls getBooks() several times per request. Putting a database query, a web-service call or any other expensive work into such a getter is the best-known Faces performance mistake. The request processing page lists the phases; the data tables page observed that a table’s value is read three times before the action runs and once more to render on a postback.

The following pair of beans and views shows it. The service counts every call to catalogue(...) as a query, and a second counter counts getter calls:

Source: Jakarta EE Tutorial: Expression Language and Jakarta Faces 4.1 specification, Chapter 2 (lifecycle)

Counted by the instrumentation, one GET and then one postback of the form (five books, Production stage):

The getter is called a different number of times by each implementation (the specification does not fix it), so never write code that depends on the count. Notice what the table says about the design too: even the good bean’s getter is called six to nine times on a postback. That is fine because it only returns a field.

The rules that follow:

A @ViewScoped bean (jakarta.faces.view.ViewScoped) lives as long as the view does and is kept in the session, in the view map of a saved view. Two things follow. Everything the bean references is held in the session for the lifetime of the view, for every open view, for every user. And the bean has to be Serializable because the container may passivate the session (the scopes page lists the passivation rules).

The commonest mistake is to keep a whole result set in the bean to avoid re-querying. The scratch bean below holds 5000 search results twice, once as entities and once as ids, and measures both with Java serialisation, which is a fair proxy for what a clustered session would have to replicate:

Source: Jakarta Faces 4.1 API: ViewScoped

On both implementations the same figures came back: the 5000 Book records serialise to 211,107 bytes, the 5000 ids to 70,122 bytes. Both ways are far from free (the entities are roughly 42 bytes per record, the ids roughly 14), and a view scope that holds them is paid for once for every view the user has open. The advice follows:

Faces must restore the tree on a postback. It does so from saved view state, kept either on the server (the default, and what the jakarta.faces.ViewState hidden field then holds is a short key) or in the page itself (client state: the whole state encoded in the field). The setting is jakarta.faces.STATE_SAVING_METHOD, with the values server and client; the mechanism, the keys of client state and the cluster consequences are on the state saving page.

Partial state saving (PSS, since Faces 2.0, jakarta.faces.PARTIAL_STATE_SAVING, default true) saves only what differs from the initial state, which Facelets can rebuild by running the page again. It is the reason a restored view needs a build step at all. Disabling it (full state saving, or FSS) saves the whole tree.

Measured on the Bookshelf pages with client state, so that the state is visible. The figure is the length of the jakarta.faces.ViewState value:

Partial state saving is smaller in every cell, by a factor of about 1.7 to 38. Server state is the cheaper on the wire (32 to 41 characters in these runs) and costs session memory instead. Client state is unbounded by the session limits and survives a session that expires, which is why it is chosen for stateless clusters, and it costs CPU and bandwidth on every request. Its integrity and confidentiality rely on the implementation’s encryption, so never turn that off in production (Mojarra has a switch that exists for debugging only; the security page returns to this).

Related parameters:

Source: Mojarra 4.1 context parameters and Apache MyFaces Core 4.1 configuration

Three more points. First, the PrimeFaces performance page recommends switching view state compression off for speed; read the table above before copying that: with Mojarra’s default of server state it has no effect, and with client state it makes the page larger. Second, com.sun.faces.refreshTransientBuildOnPSS (false) and com.sun.faces.restoreBuildTimeDecisions (false), both added to Mojarra’s 4.0 line (4.0.19 and 4.0.23), exist for views whose structure changes between restore and render because of build-time tags; the Mojarra reference says the first costs a second full build of the view on every postback and only papers over a problem you should fix. The JSTL page explains those structural problems.

Third, full state saving is deprecated in Faces 4.1. The specification’s change log lists "Deprecate full state saving" (issue 1829) and marks jakarta.faces.PARTIAL_STATE_SAVING and jakarta.faces.FULL_STATE_SAVING_VIEW_IDS as deprecated. Setting PARTIAL_STATE_SAVING to false made both Mojarra 4.1.17 and MyFaces 4.1.4 log a warning that the parameter is deprecated as of Faces 4.1 at startup; setting it to true did not. Leave the default.

Stateless views. A view that needs no state between requests (a search form, a landing page) can be marked transient with <f:view transient="true">. Faces then saves nothing; the view state field of such a page held the text stateless on both implementations. The price: no view-scoped beans (a new instance each request, see the scopes page), and a required view parameter fails on a postback. Pooled views and stateless views exclude each other in MyFaces. The MyFaces documentation adds that the stateless optimisation has no noticeable effect for MyFaces, "because its PSS algorithm […​] is very efficient"; the page on state saving and stateless views covers the topic in full.

Source: Jakarta Faces 4.1 VDL: f:view and Apache MyFaces Core Concepts: View Pooling

f:ajax has two lists. execute names the components that are decoded, validated and written to the model in the request; render names the components that are encoded into the response. Their defaults are @this and @none. The common performance mistakes are execute="@form" where one input matters and render="@form" (or a distant, large container) where one text has changed: the first runs conversion, validation and every setter in the form, the second re-encodes and re-sends every component in it.

The view and the bean (the view-scoped bean has two inputs and a list of 300 rows next to them):

Source: Jakarta Faces 4.1 VDL: f:ajax and Jakarta EE Tutorial: Using Ajax with Jakarta Faces Technology

The server-side counters and the Ajax response for each button, hand-posted on both implementations with the identifiers that faces.js sends:

The wide response is 10 times larger for a list of 300 short rows and grows with the list. Because it re-renders the form, the whole view also pays encode time again.

A real browser showed one more difference that a hand-posted request cannot. Intercepting the XMLHttpRequest that faces.js issues in headless Chrome for the narrow button, Mojarra’s script sent 284 bytes (the form id, view state, the source and the Ajax parameters) whereas MyFaces' script sent 308 bytes, including f:title and f:author as well: it posts every input of the form regardless of execute. With a form of a hundred inputs that is a lot of bytes for a one-field update. The client resolves the keywords: @this became the button id and @form became f:wide f on Mojarra and f f:wide on MyFaces. (A hand-written request is a different matter: sending the literal @form as the execute value ran nothing on Mojarra, while MyFaces accepted it. Send resolved identifiers, as the script does, when you replay Ajax traffic, see Load Testing with JMeter.)

PrimeFaces adds a switch for that payload. primefaces.SUBMIT (full by default, or partial) tells p:ajax and p:commandButton to serialise only the components that are processed; the partialSubmit attribute overrides it per component. The PrimeFaces documentation says the global setting reduces network traffic; primefaces.SUBMIT was confirmed to be read by PrimeFaces 16.0.0 (its configuration class reads it), but the traffic reduction itself was not measured here.

Rules for Ajax:

Stylesheets, scripts and images included with h:outputStylesheet, h:outputScript and h:graphicImage are served by the ResourceHandler under /jakarta.faces.resource/ (the resource handling page explains the lookup, libraries and versions). What a browser may cache is decided by the response headers the handler adds. The scratch runs requested one stylesheet and one view from each implementation:

Seven days is the default on both. The parameters:

Source: Mojarra 4.1 context parameters and Apache MyFaces Core 4.1 configuration

A long cache lifetime only works if a changed file gets a new URL. Faces helps by letting a library carry a version (a version directory below the library, covered on the resource handling page); the OmniFaces combined resource of the next section (see also the OmniFaces page) adds a v parameter; and a build step can put a content hash in the file name. Changing the default to a short time instead of versioning gives up most of the benefit.

Views must not be cached by the browser. A cached page with a jakarta.faces.ViewState field brings back a view the server may no longer remember when the user presses the back button. The OmniFaces CacheControlFilter exists for this: with no parameters it sends headers that forbid caching, and its documentation says it deliberately skips Faces resources, whose headers the ResourceHandler controls. Compressing the HTML helps the other direction. Both filters, mapped on the Faces servlet, were run on Mojarra:

Source: OmniFaces 5 API: CompressedResponseFilter and OmniFaces 5 API: CacheControlFilter

Results for the 21,383-byte tree-repeat.xhtml response: with Accept-Encoding: gzip it was delivered as Content-Encoding: gzip in 2,061 bytes; the filter chain also added Cache-Control: no-cache,no-store,must-revalidate, Expires: Thu, 01 Jan 1970 00:00:00 GMT, Pragma: no-cache and a short-lived BFCache-Buster cookie to the view response (the Javadoc lists all four headers, the cookie since OmniFaces 2.7.28, and says the filter’s caching headers are disabled in the Development stage). Servlet containers can usually compress responses themselves, which is preferable when you control the container; the filter’s Javadoc names it as the container-independent alternative. Note that the PrimeFaces performance page still points at a GzipResponseFilter from OmniFaces; in OmniFaces 5.5.5 the class is CompressedResponseFilter and a GzipResponseFilter does not exist in the jar.

Two PrimeFaces notes from the same page: compress and optimise your own JavaScript and CSS in the build (it names the PrimeFaces Extensions resources optimizer Maven plugin), and use a servlet filter to set expiry headers on static files that are not served through the Faces ResourceHandler.

Every h:outputStylesheet and h:outputScript is one more HTTP request. OmniFaces' org.omnifaces.resourcehandler.CombinedResourceHandler removes the separate stylesheet and script resources from the head and replaces them with one combined stylesheet and one combined script. It is not registered automatically (OmniFaces registers its other resource handlers, but not this one); you add it to faces-config.xml:

Source: OmniFaces 5 API: CombinedResourceHandler and OmniFaces showcase: CombinedResourceHandler

The page has three stylesheets (one of them media="print") and two scripts. Without the handler the head references five files; with it, the browser got:

Source: OmniFaces 5 API: CombinedResourceHandler (Usage)

Fetching those two URLs returned the files concatenated in page order (layout.css then page.css; a.js then b.js), with ETag, Last-Modified and an Expires header one week ahead, on Mojarra and on MyFaces. The odd-looking file name is the list of combined resources encoded by the handler; the v parameter changes when one of the sources changes. (The Javadoc says it is the last-modified time in minutes; the values observed looked like millisecond timestamps, so do not parse it.)

The rules, from the Javadoc and confirmed in the run:

The context parameters, all documented in the Javadoc (names confirmed in the 5.5.5 jar):

With PrimeFaces 16.0.0 on Mojarra (a p:dataTable page) the six scripts the page loaded became two: one combined script of 897,342 bytes and PrimeFaces' locale-en.js, which stayed separate. Of the three stylesheets, components.css was combined (112,070 bytes); theme.css and primeicons.css stayed separate. On MyFaces the PrimeFaces combination was not run.

When is it worth it? With HTTP/1.1 every file costs a connection round trip, so fewer, bigger files load faster. With HTTP/2 the saving shrinks, and one changed file invalidates the whole bundle (reasoning, not measured here). A build-time bundle that gives the combined file a content hash is an alternative the PrimeFaces performance page suggests (it points to the PrimeFaces Extensions resources optimizer for JavaScript and CSS). Whatever you choose, test it against a cold cache.

MyFaces has several optimisations of its own. All of them are MyFaces-only context parameters, so they do nothing (and change no behaviour) on Mojarra; keep that in mind when a team runs different servers in development and in production.

Caching EL expressions. Each time a view is built, the Facelets compiler creates the value and method expressions of the page again. org.apache.myfaces.CACHE_EL_EXPRESSIONS lets MyFaces reuse them. The valid values, from the MyFaces documentation:

The documentation lists the traps of the cheaper modes: two pages that include one template with different numbers of ui:param values can see the first page’s cached var2, and a c:set inside a conditional can leave later expressions uncached. The switch is a plain context parameter:

Source: Apache MyFaces Core Concepts: Cache EL expressions

The scratch app ran every example of this page, including the Ajax and postback counts above, with alwaysRecompile and produced identical counts and output. The speed-up itself was not measured (loopback timings of a 1 ms request were noise).

View pooling. Instead of rebuilding a view for every request, MyFaces keeps a pool of views for reuse: after rendering, the view is reset to its initial state (this relies on the partial-state-saving mechanism) and parked, and the next request for the same view id, locale, render kit and contracts takes it from the pool and, for a view that has dynamic parts, refreshes only those. The MyFaces documentation reports, from tests with its demo application, about 25% less transient memory, about 9% more throughput for non-Ajax requests and 9% to 30% or more for Ajax requests depending on the tree size. Those figures are the project’s, not mine, and the documentation itself recommends the pool only where performance is a critical concern and only for the busiest views.

You enable it in one of two ways. A faces-config.xml mapping, which also lets you override the global parameters per URL pattern:

or a marker on the top-level page:

Source: Apache MyFaces Core Concepts: View Pooling

The parameters (defaults from the MyFaces 4.1 configuration page):

What the run showed, on MyFaces 4.1.4. Both ways of enabling the pool were accepted and the pages behaved as before. Without the EL caching switch the pool refused to start: the startup log said that CACHE_EL_EXPRESSIONS was noCache and had to be alwaysRecompile to enable view pooling, and "View Pooling disabled". So the pool needs the previous switch. A transient (stateless) view and a pooled view exclude each other, as the documentation says, because the pool reuses the state saving algorithm. The documentation also lists the costs: every component in a pooled view must be able to reset itself (components that extend UIComponent directly, rather than UIComponentBase with its StateHelper, need extra code in saveState), the detection is not fully failsafe, and listeners subscribed from a tag handler with UIViewRoot.subscribeToViewEvent are not restored. Custom components such as those on the custom components page have to be checked against that list.

Other switches, all from the MyFaces configuration or the PrimeFaces performance page and not run, unless noted:

PrimeFaces gives one performance advice before any other: the bottlenecks are almost always in the back end and in database queries. Its toolbox follows from that.

Lazy loading of data. A p:dataTable with a plain List value holds every row in memory on every request. Binding a LazyDataModel makes the table ask for one page at a time (the PrimeFaces data components page has the full lazy model). The PrimeFaces data table documentation states the difference: regular Ajax pagination renders one page but still needs all the data in memory, a lazy table also loads only the page into memory. The model implements count and load; the table calls load on every paging, sorting or filtering. It also advises against keeping the model in a long-lived scope such as @ViewScoped (large sessions and serialisation) and shows a request-scoped bean. The example below adapts the data tables page’s BookService (its find and count methods) and was run on Mojarra with PrimeFaces 16.0.0:

Source: PrimeFaces 16 documentation: DataTable (Data binding and Lazy Loading)

The first request rendered exactly 10 rows from a 1000-row source. The page only asks service.find(first, pageSize, ...) for the rows it shows and service.count() for the pager; replace BookService with a repository that issues a LIMIT/OFFSET or keyset query (the persistence and pagination material is linked from the persistence page) and a COUNT query that honours the filters. Selection needs a row key: rowKey="#{book.id}" on the table and a getRowKey override as above. PrimeFaces also ships DefaultLazyDataModel (a builder over a lambda, which its documentation says performs up to 30% better than binding a simple list; its supplier returns the whole list, so by reasoning it saves rendering and filtering work, not the query) and JPALazyDataModel. DefaultLazyDataModel was checked to exist in the 16.0.0 jar with a valueSupplier and a rowKeyProvider builder method, but was not run. Row grouping does not work with lazy loading and live scroll, according to the documentation. Virtual scrolling (virtualScroll="true") combined with a lazy model fetches data on demand as the user scrolls.

Load content on demand. p:tabView and p:accordionPanel render all tabs by default. With dynamic="true" only the active tab’s content is rendered and the others are fetched with Ajax when first selected. p:tabView keeps a loaded tab in the browser (cache="true", the default) and cache="false" reloads it on every activation. The scratch page below, requested once, contained the first tab’s text and not the second’s:

Source: PrimeFaces 16 documentation: TabView (Dynamic Tabs) and PrimeFaces 16 documentation: AccordionPanel (Dynamic Content Loading)

Cache rendered fragments. p:cache stores the rendered output of its content in a cache region and serves it on later requests and postbacks instead of rendering the content again. Its attributes are region, key, disabled and processEvents, and the provider is configured with primefaces.CACHE_PROVIDER (the default provider is based on a ConcurrentHashMap; Ehcache 2 and 3 providers exist). The scratch page below showed a summary that the bean said it computed once across three requests, on both implementations:

Source: PrimeFaces 16 documentation: Cache

Cached output is the same for every user and every request until you clear the region, so use it only for fragments that do not depend on the user, the locale or the request, and never for anything security-relevant. The default provider has no expiry or size bound (reasoning from its description as a map; the Ehcache providers add them).

Settings and patterns from the PrimeFaces performance page. The page recommends, besides the Production stage, the refresh period of -1 and server state saving covered above:

Source: PrimeFaces 16 documentation: Performance and PrimeFaces 16 documentation: Configuration

primefaces.SUBMIT is explained in Scope Ajax Requests with Execute and Render. primefaces.MOVE_SCRIPTS_TO_BOTTOM (false by default; true, false or defer) moves inline scripts to the end of the body, which the documentation says gives a better visible rendering and smaller HTML. Both names are read by PrimeFaces 16.0.0 (checked in its configuration class); the effect was not measured. Two more PrimeFaces parameters touch the page weight. primefaces.CLIENT_SIDE_LOCALISATION is true by default in PrimeFaces 16 (the configuration table of the documentation still says false; the 14.0.0 migration guide says it became the default), which makes the pages add a script locales/locale-<language>.js for the locale of the view (observed for a Spanish request); set it to false only if the application loads or needs no client-side locale. primefaces.HIDE_RESOURCE_VERSION (false by default) drops v=16.0.0 from the URLs of PrimeFaces resources; it does not make them faster, and it removes the version that cache busting relies on (see versioning), so prefer the version in the URL unless you are hiding the library version (the parameter table, where both defaults were observed). The patterns, summarised: define process and update precisely; use plain HTML instead of Faces tags where you need no component; keep logic out of getters, EL and long-lived beans; cache data used several times in a view in a request-scoped bean; set required on inputs whose label should show the required marker instead of making p:outputLabel look the constraint up (the page says the default of indicateRequired is auto and then looks up Bean Validation constraints); and mark views you do not post back as stateless. Each of these is also on this page under the matching heading.

Nothing above replaces a load test. It is the only way to see how your application behaves with concurrent users, with the JIT warmed up, with real think time and with the garbage collector. Apache JMeter is the usual tool. This section covers what is specific to Faces; building plans, thread group sizing, properties and running from Maven is on the existing Performance Testing with Apache JMeter page (for Spring Boot, but the JMeter part is the same). A separate load testing page for the Java frameworks is planned in issue #260 (prose only here); the testing page has a short load-testing note, and the deployment page covers monitoring.

What makes a Faces plan different: every request carries state. A GET returns a page with a jakarta.faces.ViewState hidden field; the POST that follows must send it back or the server answers with a ViewExpiredException. So the plan has three kinds of element beyond the plain HTTP samplers:

The extractor settings that worked against both implementations (verified with an equivalent regular expression on the responses of Mojarra and MyFaces; the JMeter elements themselves were not run, because JMeter is not installed in the scratch environment):

Source: Apache JMeter User’s Manual: Component Reference

The POST sampler then sends the form: the form id marker (f=f for the form with id f on Mojarra; MyFaces additionally needed a hidden f_SUBMIT=1 marker in hand-made posts, which a real browser sends because it posts every hidden field), the input values, the button name and jakarta.faces.ViewState=${viewState}. Record a real session with a browser and copy the parameters rather than guessing them.

For Ajax, the request is the same form post with these additions, as observed above for f:ajax:

The extractor for the Ajax response, as a second child of the Ajax sampler:

Source: Apache JMeter User’s Manual: Component Reference

Assertions make a load test meaningful: a Response Assertion on the response code, and on the text of the response (the partial response element for Ajax, a fixed text of your page for GETs, and a check that the text of your ViewExpiredException error page is absent). A test that counts only HTTP 200 will happily count error pages. See the exception handling page for how such errors are shown.

What to look at when you run it (from the JMeter best-practices page and the behaviour described above):

Both implementations produced identical output and identical server-side counts for every page of this section, with and without alwaysRecompile and view pooling on MyFaces, and with CombinedResourceHandler on both.

Source: Jakarta Faces 4.1 specification, Appendix B changes between 2.1 and 2.2 and the 4.1 change log

The JSF 1.x books in the bibliography (the Mann and Jacobi and Fallows titles) describe a framework in which every view saved its complete component tree; partial state saving arrived only in 2.0, which is why their warnings about page size and session size are harsher than today’s. Their tuning advice about STATE_SAVING_METHOD is still the right lever, but it now applies to a much smaller state, and full state saving is deprecated. The component-library chapters of those books (ajax4jsf, Weblets, hand-written XMLHttpRequest code) are replaced by f:ajax and the ResourceHandler, which is also where caching and combining now live.

JSF 2.0 Cookbook (2010) has recipes for testing and load-testing JSF applications and for serving resources through custom resource handlers. The advice to load test and to serve images, CSS and JavaScript as Faces resources still holds; the tools and the javax.faces code do not, and the cache headers and parameters in Resource Caching and Compression are the current form. The PrimeFaces Cookbook, Second Edition (2015, PrimeFaces 5.x) shows lazy data tables, partial submit and the cache component. Those recipes still exist in PrimeFaces 16, but LazyDataModel changed (the 16 documentation shows count and load with Map<String, SortMeta> and Map<String, FilterMeta> arguments, and builders for lambdas and JPA), partial submit is now a global primefaces.SUBMIT setting, and the cache component has a default provider and Ehcache 2 and 3 providers. Check the PrimeFaces version before copying its code. None of the books covers CDI @ViewScoped, OmniFaces 5, MyFaces view pooling or Production-stage defaults.