Tuning Web Applications on JBoss AS Part 4

Compressing attribute text

One of the most powerful features of JAX-RPC web services is the Handler chain mechanism. A Handler can be used to modify a SOAP request or response message at the client and the server side. A Handler class is tied to the service endpoint and can be configured to intercept the SOAP message and perform various operations on it. A comprehensive guide to install and deploy Handlers with the JBossWS platform can be found here: http://community.jboss.org/wiki/ JBossWS-UserGuide.

A Handler extends the GenericSOAPHandler interface and is commonly used for performing aspect-oriented activities on the SOAP message like logging or encrypting. However, it can also be used to compress the content of the web service attributes. Showing a complete code example of this is out of the scope of this topic, however, in a nutshell, compressing the web service body requires reading the SOAPBodyElements in the handleInbound(MessageContext msgContext) method and send them compressed through the handleOutbound(MessageContext msgContext). Depending on the efficiency of the compression algorithm, you can expect a performance benefit due to the reduced size of the SOAP payload.

Faster JBossWS provider

JBossWS project provides a JAX-WS web service stack compatible with the Java EE 5 standard. The JBossWS framework is quite flexible as you can use three different kinds of web services implementations:


• JBossWS Native: This is the JBossWS web service framework integrating the original JBossWS native stack that has been developed in the past few years.

• JBossWS CXF: This is the JBossWS web service framework integrating the Apache CXF web service stack. It is the default web service framework in release 6.x of the application server.

• JBossWS Metro: This is the JBossWS web service framework integrating the GlassFish Metro Web Service stack.

Releases 4.x and 5.x of the application deliver the JBossWS native stack as the default JAX-WS implementation. However, it is worth trying different providers to see which one can achieve the best performance for your web services. This is what we will do in the next sections.

At first, you need to download the additional providers from the JBossWS download page: http://www.jboss.org/jbossws/downloads.html.

tmp181-118

Installing a new web services stack is quite easy and follows the same procedure for all web services stacks. Just drop a file named ant.properties in the home directory of your web services stack. The file needs to contain information about your jboss_home directory, for example:

tmp181-119_thumb[2][2]

Then, launch the ant make file adding as an argument the release where the web services libraries will be installed:

tmp181-120_thumb[2][2]

We will now compare the web services providers with three different kinds of payloads: small (5 KB), medium (50 KB) and large (500 KB). The first implementation tested will be the default JBossWS native stack. Here’s the benchmark aftermath:

tmp181-121

As you can see, the throughput of the JBossWS native implementation stays in the range between 26-34/sec for small or medium payloads. When using large payloads the throughput decreases to just 4.7/sec with an average of 5 seconds per request.

We will now repeat the test with Apache CXF stack:

tmp181-122

The result of this benchmark shows a consistent boost in all main metrics, revealing a throughput from 2.8 to 4 times higher. Besides this, Apache CXF stacks also exhibit a minor decrease in performance as the payload increases. The transition from a 5 KB XML size to a 500 KB reduces the throughput to 1/5 while the JBossWS native implementation reduced the throughput to 1/7.

The following graph completes our analysis with the Glassfish Metro benchmark:

tmp181-123

This benchmark sets a new record for all three tests, with very interesting performance numbers when dealing with small/medium-sized SOAP messages. The average response time for small payloads (which is just 7 ms) indicates clearly that this web service stack adopts internally caching algorithms to store the structure of the web service definition (WSDL). The time spent for small payloads using this stack can be as low as the mere network latency.

The wisdom behind these benchmarks

At the end of this test, we can draw some conclusions. As far as performance is concerned, the Apache CXF and Glassfish metro stack seem definitely superior to the default JBossWS native stack. GlassFish Metro scored the highest overall throughput, while Apache CXF seemed to be the one which scales better as payload increases.

Nevertheless, this test cannot say a definitive word about which web service stack is actually the fastest. There are still too many factors to compare, for example the performance of the security API or encryption metrics. Also these numbers are likely to change as the web service releases are upgraded.

What we can certainly argue with these statistics is that, if you have performance goals in your web service project, then you should seriously evaluate Apache CXF and Glassfish Metro stack. Setting up an alternate JBoss AS server configuration with another web service implementation, as we showed, is quite trivial so just benchmark before rolling in production with the default implementation.

Summary

In this topic, we have covered in detail how to deliver fast web application modules. In the first part of the topic we have discussed the best tactics to deliver a fast web application, covering the following topics:

• Earlier MVC web applications are intrinsically coupled with a set of interfaces and require lots of tedious and repetitive code to deal with low-level request and response objects. On the other hand, because of their shorter lifecycle they deliver fast responses.

• On the other hand, developers with a sound knowledge of JSF technology, can build highly flexible web applications in a much shorter time, at the price of a more complex (and thus slower) runtime lifecycle.

° Producing a tabular set of data is a common requisite of every web application. By using a plain JSP/Servlet approach you can achieve the best performance hit. Using JSF’s Mojarra 1.2 implementation was about 2.5 times slower in our lab tests. The RichFaces component library added an additional 20 percent slow down. The dataTable and rich:dataTable, however, are highly customizable and can mitigate the additional overhead by rendering a small dataset and using pagination.

° If you are going to render a set of hierarchical data by means of a tree, be aware that a JSF solution might impact performance. You are advised to stay on a low-level technology like JavaScript, if you have lots of data in the tree. Depending on the type of hardware and the browser used, as little as 500 records in a tree can produce a significant slow down in your JSF tree.

• JSF performance can, however, be enhanced by setting the javax.faces. state_saving_method to server. If using client-state saving method you are advised to use org.apache.myfaces.JbossSerialFactory as a serialization factory.

° Ajax technology can greatly enhance the performance of your web applications by limiting the area of the page to be reloaded and reducing also the amount of data to be sent for processing.

° The reRender attribute can be used to define the UIComponent, which is affected by page reloading. The ajaxSingle attribute when set to true can limit the amount of parameters sent by the view.

° Ajax partial page refresh requires a Servlet Filter, which adapts the content of the HTML page. If your application’s markup code is strictly verified, the NEKO parser yields the best performance results.

In the second part of this topic, we have discussed B2B components, namely web services, and how to improve their performance.

• The performance of web services is strongly dependant on the size of the SOAP packet sent during the communications. You can reduce the packet size by overriding the default binding rules for Java-to-XML schema mapping using JAXB annotations; for example defining class fields as XML attributes instead of XML elements.

• Another element you should consider is caching, which could be applied both on the web service contract (WSDL) and, with some restrictions, on the web service port, in order to cache the abstract view of the web service.

• Finally, before rolling your web services in production, you should evaluate the available web services stacks. Basically, you can opt for three different web service stacks:

° JBossWS Native, which is the default JBoss 5.x web service stack

° JBossWS CXF, which integrates the Apache CXF web service stack

° JBossWS Metro, which integrates the GlassFish Metro web service stack.

• From a performance point of view, Apache CXF and GlasshFish showed a much better throughput than JBossWS Native. The former one (JBossWS CXF) is the default JBoss Web service stack in the 6.x releases.

Next post:

Previous post: