Sealyu

In the first of this two-part article, Dan Allen discusses some common performance problems you may encounter when using JSF components, Seam components, and the EL. You'll learn about the set of best practices for eliminating them that led to an improvement of two orders of magnitude in the performance of his application.

JavaServer Faces (JSF) has a reputation for having poor performance. Some claim that this "runtime tax" is simply the cost of using a component-based abstraction layer. After focused research, I have determined that by following a handful of best practices, you can get your JSF data tables to perform almost as well as hand-crafted HTML while still being able to retain the benefits of developing with an event-driven programming model. I begin by identifying some performance problems that occur when using JSF UI components, Seam components, and the EL carelessly, and then present, through a series of four lessons, ways to eliminate these problems one-by-one until you have observed a remarkable, two orders of magnitude improvement.

All the test results reported in this article were gathered on a Lenovo R60 with 2.5GB RAM, Dual Core T2300 @ 1.66Ghz processor running Ubuntu Linux 7.10. The application was built using Seam 2.0.3.CR1, Sun JSF 1.2_04-b16-p02, and RichFaces 3.2.2.GA. It was deployed to JBoss 4.2.2.GA running on Sun JVM 1.6.0_03. The timing results are shown in six progressive phases. Each result shows the total request time and the time to render a data table with 50 records. All metrics were captured using the FireBug extension for Firefox.

Introduction

Developing a data management application is just a matter of getting data up on the screen in tabular format, correct? Oh, right, and being able to filter the data. Ah, and also allowing the data to be changed. Unfortunately, once those challenges are behind us, we tend to wash our hands of the application and move on. But the principle goal of most web applications is to enable users to perform their work more efficiently than they did before we introduced our "solution." In fact, none of those fancy features you add have any value at all if you can't improve the user's productivity. That's why, before you step away, you have to make sure that you have addressed the issue of performance.

My colleagues and I recently completed the first stage of an open source data management application based on JSF, Seam, and RichFaces in which we addressed this very concern. The application, named EDAS2, was developed for a group of scientists for managing water quality data (stored in the WQX database schema). Now, you have to understand that these scientists, they like their data. Hordes of data. And they like to view it all at once. So much, in fact, that it tends to cause the browser to crash. Naturally, we needed to condition the scientists to some degree that browsers have limits. But regardless, we were going to be dealing with large data sets. Our goal was to make sure that working with those data sets was not painful.

This article documents the bottlenecks that we discovered and a set of best practices for eliminating them. But we went beyond merely removing obstacles in performance. We tuned the application to the point where paginating, sorting, and filtering the data is actually faster than any desktop application our scientists had ever used. Find that hard to believe? Read on.

About the EDAS2 application

The intent of the EDAS2 application is to house and analyze water-quality measurement results. The results are taken from a location, known as a monitoring location, during a given visit, known as an activity. There are various types of results, depending on what is being measured. In this article, we will be focusing on the benthic measurement result, which in layman's terms is a sampling of mud with bugs in it. That data is recorded on site and later entered into the database and analyzed using the EDAS2 interface.

There isn't anything revolutionary about the interface of the EDAS2 application. Rather, the emphasis is on efficiency. We want to provide the experience of the MS Access database-which our scientists are currently using to manage this data-in a web application.

The application has two types of views. The first is a list view, which displays a paginated table of records for the currently selected parent entity, such as monitoring location, activity, or result. You will learn shortly that what makes this interface efficient is that it offers in-place editing of each row (it also has a floating popup dialog for detailed editing of the row).

The editable data table

The key feature of this application is that the data rendered in each table can be modified in place. To implement this functionality, we decided against using an off-the-shelf grid editor from a JSF component library. Instead, we took the RichFaces step-wise approach by building a composite, Ajax-enabled component using the partial page rendering technology that the Ajax4jsf core provides.

Ajax4jsf provides a set of tag libraries that can tie a JSF generated event to the rerendering of one or more regions of the user-interface. Those regions are identified by their JSF client IDs. When the JSF event is sent to the server, instead of the JSF servlet returning an entire page response, it returns only fragments of the HTML. Ajax4jsf then cuts out the old branches from the live view and stitches in the replacements returned from the server. The result is that the user observes the page updating without any noticeable refresh, in real-time, so to speak. And Ajax4jsf's declarative approach let's us fine-tune this behavior.

Figure 1 provides a view of the editable data table with one of the rows in edit mode.

 
Figure 1. The data table demonstrating its single-line editing capabilities.

When the page is first rendered, all rows have an edit and delete button. Clicking on an edit button puts the corresponding row in edit mode, at which point the outputs in the selected row become inputs. From edit mode, the user can make changes to the visible data and either save or cancel the update, which returns the table to read-only mode.

The strategy we use to deliver this row-level editing functionality is to have two UI components in each column of a standard JSF data table: one output component (e.g., <h:outputText>) and one input component (e.g., <h:inputText>). We then use the JSF rendered attribute on each component to control which one is displayed.

A backend supported by Seam

To support our editable data table, we put together a small hierarchy of classes that are instantiated as Seam components to manage the query (filtering, pagination) and the editing process (select row for editing, update, delete, cancel). We chose to put the components in Seam's conversation scope. The conversation scope is a slice of the HTTP session that is managed by Seam and associated with a sequence of pages through the use of a special request token (known as the conversation id). The conversation provides the developer the convenience of using the HTTP session without the memory leakage concerns, since the conversation has a much shorter lifetime and is kept isolated from other parallel conversations in the same session.

We chose to leverage the conversation for three reasons:

• to reduce the number of times the database needs to be queried
• to ensure the record remains managed by the persistence context while being edited
• to maintain the search criteria and pagination offset

Using the conversation has the added bonus of making previously viewed result pages load faster since the records are already sitting in the persistence context (i.e., the first-level cache).

Given all the benefits the conversations provide, you may be wondering where the performance problem is. Let's take at look at where things began to go wrong and what we did about it.

The performance roadblock

Development was going smoothly until my colleague noticed something peculiar about the performance. Five or ten records on the page took a reasonable amount of time to render, but when that number went up to 50 or 100 records, the performance of the page plummeted. It turns out that the degradation was linear, but the slope was very steep. The page with 100 records was taking over 15 seconds to render. Obviously, that just wasn't going to fly. And so our optimization work began. Could we find the bottleneck and how low could we go?

As we optimized, we first looked at the most basic page and established a performance baseline. Then we added additional components to the page and tried to identify which ones were contributing to the major slowdown. As it turns out, in a Seam application, the first area to place your focus is on page actions, which are methods that execute before the page begins to render.

Page actions and component initialization

When a page is taking 15 seconds to render, there is likely a single culprit that is chewing up a bulk of that time. To establish a baseline, and to make sure I was focusing on the right problem, I first stripped everything from the page and requested it. The response took a couple of seconds to come back. This had me puzzled for a moment. I soon realized that that a Seam page action was registered with the page (i.e., view ID). A page action is a method-binding expression that is assigned to a JSF view ID (or a group of view IDs if a wildcard is used) in a Seam page descriptor and is evaluated by Seam just before the view ID is rendered by the JSF view handler. Here's the expression that was registered with the view ID of the results page.

The page action is there to eagerly fetch the results that are to be displayed on the page. However, the query in that method was executing in about a tenth of a second. So that wasn't the problem. After studying the code a bit longer, I recognized that the problem was not in the page action method, but rather the @Create method of the component being invoked. The @Create method is a synonym to the standard @PostConstruct method in Java EE and marks a method to be evaluated immediately after a component is instantiated.

Inside the @Create method was a handful of queries that retrieved more than 10,000 records of reference data. This data is used by select menus in various forms on the page, but those forms are all being conditionally rendered. So basically, we were charging the user a toll to enter the page with a chance that that reference data would never be referenced. That brings us to lesson #1.

Lesson #1: Don't make the user pay an upfront fee to view a page. Defer logic where possible.

Since the forms are rendered conditionally, and some via Ajax, the reference data can be retrieved at the same time the forms are activated. If you must display a form unconditionally, think about the most efficient way to prepare the data (perhaps using a cache). It's also preferable to use Ajax-based autocomplete rather than select menus with a large list of options, since making this switch can drastically reduce the speed of the initial rendering of the form. The user will likely be more patient when working on the field with autocomplete, and you can even keep the number of options delivered to a minimum as the user types.

With the toll skimmed off the top, we could get back to the performance of the elements on the page. Bringing back the page piece-by-piece, I determined that the next big time hog was in fact the data table. Again, I stripped out elements in the data table until I pinned down what was causing the problem. As it turns out, it was the expressions in the rendered attributes that I was using to hide or show various components in the table.

The cost of conditional rendering

In each row there are 6 "editable" columns, each containing an output and an input component and 4 icons for controlling editing (edit, delete, approve, cancel). In total, there are 16 uses of the rendered attribute appearing in each row. (Initially I had a couple columns with multiple input components, which I realized I needed to group within a panel group [i.e., <h:panelGroup>] so that the rendered attribute was only applied once).

As you know, logic that occurs in a single row is multiplied by the number of rows in the table. In a table with 100 rows, there are 1600 uses of the rendered attribute! But wait, there's even more! The rendered attribute is a nasty beast in JSF because it's often evaluated multiple times as the UI component tree is assembled. In fact, during the render response phase, it's resolved 3 or 4 times per component in a data table. What that means is that for our data table, the conditional rendering logic we are using is executed 5200 times for 100 rows! Whatever that logic is better be darn efficient or else it will have a huge impact on performance.

As it turns out, we were not being very efficient. Let's take a look at one of the columns of the data table in the /BenthicMeasurementList.xhtml view template:

As you can see here, I am calling the editing() method on a Seam component named benthicMsmntEditor to test whether the current row is in edit mode. We can pass the iteration variable, _item, to the method because Seam integrates with the JBoss EL, which introduces parameterized method calls to the Unified EL. The editing() method performs an identity check between the row data and the selected row.

Here we are only allowing one row to be in edit mode at a time, but this logic could easily be enhanced to support editing multiple rows simultaneously.

So where's the bottleneck? Initially, you may be inclined to point the finger at the EL or Java reflection. I did some testing and determined that the EL is surprisingly fast and Java reflection is equally optimized. And if you are inclined to believe that the slowness is caused by the parameterized method call, I'll inform you that comparing the current item using an EL operator to the item in edit mode retrieved using the JavaBean style accessor yields the same timing results:

rendered="#{_item == benthicMsmntEditor.itemInEditMode}"

The culprit is that the editing() method resides on a Seam component and each method call to a Seam component passes through a stack of interceptors, unless otherwise skipped by the presence of the @BypassInterceptors annotation at the component or method level.

When you call an intercepted method once, you would never notice the impact of the interceptors. However, when you call the method 5200 times, the time spent in the interceptors adds up. How much of a difference does it make and what other options do we have?

To determine the impact, I timed both the rendering of the entire page and the rendering of the data table region, as described in the introduction. The data table region consists of the data table and the pagination controls and summary information for the table. A test of 4 requests on 50 rows (2600 calls) produced these timing results:

Not many people are going to stick around for a page that takes 6 seconds to render (in the best case scenario), and that doubles for 100 rows. The trick is to outject the selected row so that the comparison can be done without having to invoke a Seam component. Outjection is a mechanism in Seam that takes the value of a JavaBean property on a component and assigns it directly to the name of a variable in the specified scope (such as the conversion scope). You outject a property by annotating it with the @Out annotation, as shown here:

@Out(required = false) private T itemInEditMode;

(For readers with Seam experience, there is a reason why you cannot simply add @BypassInterceptors to the editing() method, which I will provide in a moment.)

Now we can check if the row is in edit mode by comparing the iteration variable in the data table to the outjected property using the following EL expression in the view:

In the first part of this article, I began briefing you on optimizations I made to maximize the responsiveness of a JSF application that I developed out in the field. I cited performance problems caused by casually accessing components from a JSF view, then presented a set of best practices to eliminate this unnecessary overhead. Despite the progress made by the end of the first part, you had not yet witnessed the two orders of magnitude in performance improvement that was promised.

In this part, the additional gains will be achieved by leveraging partial page rendering-provided by the RichFaces JSF component library and by slimming the response. Partial page rendering cuts out the overhead of rerendering the entire page after each user interaction, which turns out to be the real bottleneck in most traditional web applications, and instead redraws only the areas of the page that have changed. Naturally, you want the replacement HTML source to be as condensed as possible. These optimizations allow the responsiveness of a web application to measure up to its desktop counterpart.

Tapping into Ajax

When the user performs an operation on the screen, such as selecting a row for editing or paginating a result set, we only want to rerender the area of the page that is affected. Using the data-driven application presented in the first part, that means redrawing the data table and its pagination controls. (Note that it's possible with Ajax4jsf to rerender a single row, when applicable, but I have found it to be more trouble than it's worth).

Putting numbers aside, using Ajax is going to make the application feel far more responsive because the browser does not have to bootstrap a whole new page and all the assets that come along with it. Research has shown that creating HTTP connections is more costly than rendering large pages. Partial page rendering accounts for these findings by treating the static areas of the page and its associated assets as completed work, and focusing solely on retrieving updates. This section will support my recommendation that you should always consider using Ajax in your application, as it truly does eliminate a lot of overhead.

Accessible Ajax with Ajax4jsf

Turning regular JSF postbacks into Ajax requests is pretty simple with Ajax4jsf. However, if used inappropriately, you won't get all the performance gains you are looking for. We'll get to that in a second. First, begin by changing your <h:commandLink> and <h:commandButton> components to the ones from Ajax4jsf: <a:commandLink> and <a:commandButton>. Next, select what you want to rerender. You reference the areas of the page to update using a comma-separated list of the regions' component IDs in the reRender attribute of the command component. If you are paginating, you need to rerender the whole table and the pagination controls (dataTableContainer). If you are transitioning into edit mode, there's no need to requery or update the pagination, so you only have to rerender the table itself. Here's the code for the pagination controls:

The code for the edit control buttons in each row is similar. Here's how the edit button is defined: <a:commandLink id="edit" action="#{benthicMsmntEditor.editItem}" rendered="#{_item != conversationScope.get('itemInEditMode')}" reRender="dataTable" ajaxSingle="true"> <h:graphicImage value="/img/edit.png" alt="Edit" title="Edit"/> </a:commandLink>

What's important about using an Ajax request is to keep it simple. You don't want to perform a lot of processing on the server because then the users aren't going to get the "instant" feedback they are expecting. You can drastically reduce the portion of the component tree that is processed by JSF by using either the <;a:region> tag or the ajaxSingle attribute on an Ajax4jsf component. Let's focus on ajaxSingle.

Keeping the Ajax call brief

By default, JSF processes the whole component tree on a postback because it doesn't know where events may originate or which input fields within the submitted form contain new data. What the ajaxSingle attribute does is tell JSF to advance directly to the component that was activated, process events from that component, and re-encode it as if it were the only component on the page. The result is a drastic speed increase in the processing, independent of the size of the component tree. In fact, the only time you would forgo using ajaxSingle is when you need to capture input data from a form (a classic form submit).

When deciding whether or not to use this attribute, ask yourself if you are capturing form data or whether JSF is simply using the form submit to perform server-side work (a contrived form submit). In JSF, it's most often the latter.

Note: Interestingly enough, ajaxSingle is also a drop-in replacement for immediate, which is excellent since immediate is so poorly understood. When ajaxSingle is placed on a command component (such as a button), the form data is not processed, and hence no validation/conversion failures can occur, thus eliminating the need for immediate.

Having shifted all interactions to the Ajax bridge, it's now time to look at the performance gains. Of course, when using Ajax, the tax of rendering the portions of the page outside of the data table is gone. The performance on the server is also no longer a primary concern. Now what matters is the size of the response. Unfortunately, giving timing results here would be arbitrary because it's highly dependent on the speed of the network (and I'm testing against my own box). We have to focus on what we can control.

Trimming down the response

So what affects response size? The answer is, every character in the view. Every character that you type that is encoded into the response, as well as the markup that the JSF components generate, affects the size of the response. That includes:

• Component IDs
• View IDs
• The path of images, external JavaScript files, and CSS
• The application context path
• Embedded JavaScript
• Inline styles and names of style classes
• Erroneous markup that is encoded into the response

As you can see, there's lots of room for improvement in this category. I want to focus on component IDs first, since they are the biggest culprit.

Resources

• Code samples for this article (browse)
• Code samples from this article (SVN checkout)
• Best Practices for Speeding Up Your Web Site
• An introduction to RichFaces
• JBoss virtual host configuration
• EDAS2 Homepage
• Seam
• RichFaces
• Seam, Hibernate, RichFaces, and JBoss Tools blog

After graduating from Cornell University with a degree in Materials Science and Engineering in 2000, Dan became captivated by the world of free and open source software, which gave him his debut in software development. He soon discovered the combination of Linux and the Java EE platform to be the ideal blend on which to build his professional career, with his interests equally divided between the two platforms.

Dan is a member of the Seam project, a dedicated open source advocate, and a Java blogger. He lives with his extremely supportive wife in Laurel, MD. You can keep up with Dan's development experiences by subscribing to his blog at Mojavelinux