Tuning Web Applications on JBoss AS Part 1

nThe last topic of this topic teaches the reader how to write fast and efficient web applications on the JBoss web server. From a bird’s eye view, all web applications can be roughly divided into two broad areas:

• Business-to-Consumer (B2C) applications, where the user interacts with legacy systems by means of an interface, usually a browser. The archetype of a B2C application is engineered using dynamic web pages (JSP/Servlets) and/or frameworks based on a component-driven UI design model (JSF).

• Business-to-Business (B2B) applications: They typically require exchange of information between businesses and their legacy systems. Common examples of B2B application are web services, which are a common paradigm to integrate heterogeneous systems.

Following this simple distinction, we have split this topic into two main sections. In the first one, we will discuss tuning B2C web applications, focusing on the performance of different frameworks available. In the second part of this topic, we will talk about web service performance tuning, which can ultimately determine how fast your B2B apparatus will respond.

Choosing a framework for your web applications

The new era of web applications has introduced a number of frameworks designed to aid in rapid development. But, no matter what your preferred language is, finding a suitable framework is not usually an easy task.

When it comes to adopting a new technology, many of the decision points are organizational and not developer driven. When an organization intends to adopt an application-development framework, it is typically looking to accomplish three things:

• Address the complexities of some lower-level application architecture

• Reduce the amount of code developers have to write (also known as "productivity")

• Allow developers to focus on "business logic"

In the landscape of Java technologies, Model View Controller (MVC) frameworks have been the most popular choice in the web development arena for years, exhibiting strong features of the concept of a separation of concerns. This can be accomplished by structuring the Model to deal with the business domain objects, the Controller to handle request processing and the View, which renders the model into a form suitable for interaction, typically a user-interface element.

The following image depicts the basic interaction between the main MVC components:

The biggest advantage of using MVC frameworks is that, because of the logic separation of concerns, future enhancements, and other maintenance, the code base should be very easy and should be reusable as well.

Unfortunately, as for all technologies which match their hype, some defects started to become evident to developers. In particular, the biggest complain is that MVC frameworks, like Struts for example, will tightly couple your application to the framework interfaces. As a matter of fact, Struts uses ActionForm and Action interfaces to mediate between the Model and the View. This makes it awkward to test your application, which needs a server runtime environment accessible. The second main disadvantage is related to the difficulty of managing the details of HTTP requests and responses, which is error prone and needs to follow a complex path (Controller-Model-View) even for simple actions.

The Java Server Faces framework was designed during a period of big changes in the community of Java developers where a growing number of people agreed that Java Enterprise technology was getting over complicated. JSF eases the development of Graphical User Interfaces (GUI) for web applications allowing developers to work with extensible user interfaces like buttons, textboxes, checkboxes, and so on. These components are no more bound to HTTP request but to simple events in the form of Java methods, thus greatly simplifying web application programming.

On the wave of the success of JSF technologies, many companies started to produce JSF-component libraries, which offer a large set of custom components to cover most of the application requirements in a reasonably easy way. The JBoss team, for example, developed the RichFaces library (http://jboss.org/richfaces), which offers a broad set of built-in widgets and components and a vast community of users.

This new level of interactivity, however, does carry a price and today it’s not rare to see in JSF forums some complaints about, guess what, the performance of the "new" compared with the performance of the "old". Maybe people have discovered that not all that glitters is gold?

Comparing framework performance

One day you might be asked at a job interview "Which framework would you use for best performance?" That’s a tough question, which requires some additional input to produce a comprehensive answer. However, should you have plain Servlet/JSP on one checkbox and JSF on another, be sure to go for the first option.

Why is JSF slower than plain Servlet/JSP stuff? If you think about it, when you request a simple JSP page, the client makes an HTTP request for the page, and the server responds with the page translated into HTML. As a result, a single path is executed to render the content to the output stream. The following image depicts this simple process:

On the other hand, a Java Server Faces page is represented by a tree of UI components, called a View. When a client makes a request for the page, a complex life cycle starts. During the life cycle, the JSF implementation must build the View while considering the state saved from a previous submission of the page. When the client submits a page, the JSF implementation must perform several tasks, such as validating the data input of components in the View and converting input data to types specified on the server side. The JSF implementation performs all these tasks as a series of steps in the life cycle. The following image will give you an idea of the complexity of the JSF life cycle.

Although the JSF lifecycle is hardly set in stone (you can change the order of execution by skipping phases or leaving the lifecycle altogether), customizing the lifecycle of JSF is s a non-trivial task and a deep understanding of the JSF architecture is required to get it right.

So where do we go after this preamble? Chiefly to one point: To evaluate web frameworks not just on the basis of productivity and cool widgets but also with performance in mind. In the following sections, we will compare the performance of two common web tasks, displaying tabular and hierarchical data, using different approaches.

The numbers we will collect do not represent, as usual, a definitive truth since they are dependant on the type of application tested, on the kind of hardware used, and finally on the release of the component library used. What we will try to establish is an order of magnitude among several approaches, which must be a part of your wealth of knowledge.

The performance of tabular data

The HTML table is one of the most common constructs in a web application. Besides its usefulness when laying out components on a page, a table can display rows of data from a collection.

Trying to gather the most popular alternatives, we will consider these three possible options to iterate over the data:

• Use a Servlet/JSP-based solution

• Use a JSF solution, running the Mojarra JSF 1.2 implementation.

• Use the RichFaces 3.3 component library with the Mojarra JSF 1.2 implementation

In our test, we will suppose that the user needs to browse a table containing 10 columns and 50 rows.

The first, barebone solution, will require just to iterate through the collection of elements created on the server side:

The corresponding benchmark, built upon a total of 250 concurrent users, follows here:

The second benchmark uses JSF’s dataTable built-in UI component:

And here’s the corresponding outcome, from JMeter:

Finally, we will test a rich:dataTable, powered by the JBoss Richfaces 3.3 suite:

This is the last benchmark produced:

The numbers we have collected tell us that a simple JSP solution is about 2.5 times faster than the Mojarra’s JSF 1.2 implementation and over 3 times faster than the RichFaces 3.3 library.

What this benchmark does not tell us is that JSF experienced developers will surely complete a reporting GUI in less time than using a JSP/Servlet approach because you don’t have to write lots of repetitive code to read the request and deliver the response. Besides this, JSF-centric libraries offer a wide array of built-in useful features. These features include, but are not limited to, column sorting, pagination for large record sets, and a logical grouping of data.

As you can see, the choice of the technology for delivering the frontend introduces a trade-off between productivity and faster execution. You should decide on a per-case basis what the best is for you. For example, reports requiring the highest possible throughput should be delivered with a low-level technology like JSP/ Servlets. Also, if you can afford to use JSF for designing your tables, always use the basic h:dataTable component, unless you need some specific properties of the rich:dataTable.

In the end, if you are happy with rich:dataTable performance, try to keep its structure as simple as possible; for example, avoid nesting rich components like rich:tooltip inside it. They can slow down page rendering significantly especially on Internet Explorer.

The performance of rich tree

Displaying hierarchical data is a common requirement for many web applications. Possible usage includes, for example, file system browsing, enterprise organization path, and, network domain browsing.

The JSF specification does not include any standard tree component, so you need to extend your JSF implementation with a component library. In our case, we will test JBoss’s RichFaces tree component.

The sample tree we will benchmark will be built using a depth of 5 x 5 x 20 elements, summing up a total of 500 elements in the tree. For this purpose, the tree will be at first loaded with some data and then fully expanded.

Here’s the RichFaces’ benchmark outcome:

The average amount of time needed for each test was about 15 seconds, with a load of 250 concurrent users. Since we have skimmed any legacy systems interaction from this test, the amount of time is just spent in loading the set of elements, displaying the tree and fully expanding it.

A quick analysis of Eclipse’s profile view reveals that the server-side methods account only for a few milliseconds for building the tree, as shown in the following image:

What this simple analysis suggests is that most of the time is spent through the JSF lifecycle and, in particular, in the rendering phase which displays visually the component on the screen.

As a comparison, we will test a simple JavaScript solution, which has got a minimal set of API to create, expand, and collapse the tree (http://destroydrop.com/javascripts/tree/).

This is the same test, built using the same kind of tree:

It’s evident from this benchmark that the pure JavaScript solution works on another order of magnitude, taking just milliseconds to complete.

Should you then avoid using a rich tree? Well, from the performance point of view, the answer seems obvious. You might use a rich tree for a small set of data, possibly static data, where the user does not expand/collapse large tree structures.

One thing you might try to improve the performance of your rich:tree is switching to an Ajax-based communication, thus an Ajax request is sent when you trigger an action on the tree (see the next section to learn more about Ajax framework).

The same benchmark, executed with <rich:tree switchType="ajax" . . . /> produces this result, which exhibits a rich 10 percent gain in the average execution time and throughput:

An additional performance saving can be gained by introducing a caching strategy like Hibernate second-level cache. (Please refer to next topic, Tuning the Persistence Layer, to learn how to structure Hibernate caches in your application).