In order to provide a recognizable point of reference, this study uses SPECjAppServer2002* as a standard benchmark for our exploration. SPECjAppServer2002 provides a complete Web application that uses a large and representative sample of J2EE APIs to benchmark performance of individual systems against one another. Many of the findings in this paper are applicable to future releases of the SPECjAppServer family of benchmarks as well.

There are other criteria to select a workload for performance tuning and analysis. An earlier paper, “Enterprise Java Performance: Best Practices,” mentions that the workload needs to support some metrics that allow one to measure performance differences. SPECjAppServer2002 meets this criterion by establishing well-defined run rules and a performance metric – Total Operations per Second (TOPS).

Using such a well-defined metric allows us to measure the performance of different configurations and compare them directly. In this workload, however, the total number of transactions by the application is limited by the injection rate, known as TxRate. Thus, when performance improvement is expected, one must adjust the TxRate parameter to measure the performance gain.

Establishing a workload and performance metrics are just two of the necessary steps to prepare for performance analysis. One must also determine, among many software and hardware configurations, how to improve performance. Intel recommends using a consistent top-down, data-driven approach to identify performance issues and improve the system in a systematic manner.

This series of articles presents both the methodology and the key findings of our optimization effort. While some of our findings are specific to J2EE application performance, others are generic enough to help performance improvement for other types of applications.

These articles focus on the application-tuning process, as opposed to programming techniques to be used during the actual coding process to increase performance. Further information about such programming techniques is available elsewhere on the Intel® Software Network Web site.

While this article discusses the performance issues on the application server, one should be aware that the performance issues of a typical J2EE application (such as the SPECjAppServer2002 workload that this article studies) go outside the scope of the application server. The application server is connected to a database back-end system and one or more drivers.

Furthermore, in a clustered configuration, there can be more application servers, as well as more database back-end systems. The database system can have a huge impact on the performance of the application server on two fronts: the database configuration itself, which involves another layer of software and hardware stack of components, and the interaction with the JDBC* component on the application server.

The drivers can also be critical to the measured performance for similar reasons. Figure 1 illustrates an example of a SPECjAppServer2002 setup using multiple drivers and application servers. Both the drivers and the database systems can introduce additional response-time delays to the overall system performance and thus affect the performance metric (TOPS).

Figure 1. An example of SPECjAppServer2002 setup using multiple drivers and application servers.