test

Sun Java System Application Server 9.1 Performance Tuning Guide

Chapter 1 Overview of Application Server Performance Tuning

You can significantly improve performance of the Sun Java System Application Server and of applications deployed to it by adjusting a few deployment and server configuration settings. However, it is important to understand the environment and performance goals. An optimal configuration for a production environment might not be optimal for a development environment.

This chapter discusses the following topics:

Process Overview

The following table outlines the overall administration process, and shows where performance tuning fits in the sequence.

Table 1–1 Performance Tuning Roadmap

Step 

Description of Task 

Location of Instructions 

1 

Design: Decide on the high-availability topology and set up the Application Server and, if you are using HADB for session persistence, high-availability database (HADB) systems. 

Deployment Planning Guide

2 

Capacity Planning: Make sure the systems have sufficient resources to perform well. 

Deployment Planning Guide

3 

Installation: If you are using HADB for session persistence, ensure that the HADB software is installed. 

Installation Guide

4 

Deployment: Install and run your applications. Familiarize yourself with how to configure and administer the Application Server. 

Application Deployment Guide

Administration Guide

5 

Tuning: Tune the following items: 

  • Applications

  • Application Server

  • Java Runtime System

  • Operating system and platform

  • High availability features

The following chapters:

ProcedurePerformance Tuning Sequence

Application developers should tune applications prior to production use. Tuning applications often produces dramatic performance improvements. System administrators perform the remaining steps in the following list after tuning the application, or when application tuning has to wait and you want to improve performance as much as possible in the meantime.

Ideally, follow this sequence of steps when you are tuning performance:

  1. Tune your application, described in Chapter 2, Tuning Your Application

  2. Tune the server, described in Chapter 3, Tuning the Application ServerChapter 3, Tuning the Application Server

  3. Tune the high availability database, described in Chapter 6, Tuning for High-Availability

  4. Tune the Java runtime system, described in Chapter 4, Tuning the Java Runtime System

  5. Tune the operating system, described in Chapter 5, Tuning the Operating System and Platform

Understanding Operational Requirements

Before you begin to deploy and tune your application on the Application Server, it is important to clearly define the operational environment. The operational environment is determined by high-level constraints and requirements such as:

Application Architecture

The J2EE Application model, as shown in the following figure, is very flexible; allowing the application architect to split application logic functionally into many tiers. The presentation layer is typically implemented using servlets and JSP technology and executes in the web container.

Figure 1–1 J2EE Application Model

J2EE Application Mode

Moderately complex enterprise applications can be developed entirely using servlets and JSP technology. More complex business applications often use Enterprise JavaBeans (EJB) components. The Application Server integrates the web and EJB containers in a single process. Local access to EJB components from servlets is very efficient. However, some application deployments may require EJB components to execute in a separate process; and be accessible from standalone client applications as well as servlets. Based on the application architecture, the server administrator can employ the Application Server in multiple tiers, or simply host both the presentation and business logic on a single tier.

It is important to understand the application architecture before designing a new Application Server deployment, and when deploying a new business application to an existing application server deployment.

Security Requirements

Most business applications require security. This section discusses security considerations and decisions.

User Authentication and Authorization

Application users must be authenticated. The Application Server provides three different choices for user authentication: file-based, LDAP, and Solaris.

The default file based security realm is suitable for developer environments, where new applications are developed and tested. At deployment time, the server administrator can choose between the Lighweight Directory Access Protocol (LDAP) or Solaris security realms. Many large enterprises use LDAP-based directory servers to maintain employee and customer profiles. Small to medium enterprises that do not already use a directory server may find it advantageous to leverage investment in Solaris security infrastructure.

For more information on security realms, see Chapter 9, Configuring Security, in Sun Java System Application Server 9.1 Administration Guide.

The type of authentication mechanism chosen may require additional hardware for the deployment. Typically a directory server executes on a separate server, and may also require a backup for replication and high availability. Refer to Sun Java System Directory Server documentation for more information on deployment, sizing, and availability guidelines.

An authenticated user’s access to application functions may also need authorization checks. If the application uses the role-based J2EE authorization checks, the application server performs some additional checking, which incurs additional overheads. When you perform capacity planning, you must take this additional overhead into account.

Encryption

For security reasons, sensitive user inputs and application output must be encrypted. Most business-oriented web applications encrypt all or some of the communication flow between the browser and Application Server. Online shopping applications encrypt traffic when the user is completing a purchase or supplying private data. Portal applications such as news and media typically do not employ encryption. Secure Sockets Layer (SSL) is the most common security framework, and is supported by many browsers and application servers.

The Application Server supports SSL 2.0 and 3.0 and contains software support for various cipher suites. It also supports integration of hardware encryption cards for even higher performance. Security considerations, particularly when using the integrated software encryption, will impact hardware sizing and capacity planning.

Consider the following when assessing the encryption needs for a deployment:

For information on how to encrypt the communication between web servers and Application Server, please refer to Chapter 9, Configuring Security, in Sun Java System Application Server 9.1 Administration Guide.

Hardware Resources

The type and quantity of hardware resources available greatly influence performance tuning and site planning.

The Application Server provides excellent vertical scalability. It can scale to efficiently utilize multiple high-performance CPUs, using just one application server process. A smaller number of application server instances makes maintenance easier and administration less expensive. Also, deploying several related applications on fewer application servers can improve performance, due to better data locality, and reuse of cached data between co-located applications. Such servers must also contain large amounts of memory, disk space, and network capacity to cope with increased load.

The Application Server can also be deployed on large “farms” of relatively modest hardware units. Business applications can be partitioned across various server instances. Using one or more external load balancers can efficiently spread user access across all the application server instances. A horizontal scaling approach may improve availability, lower hardware costs and is suitable for some types of applications. However, this approach requires administration of more application server instances and hardware nodes.

Administration

A single Application Server installation on a server can encompass multiple instances. A group of one or more instances that are administered by a single Administration Server is called a domain. Grouping server instances into domains permits different people to independently administer the groups.

You can use a single-instance domain to create a “sandbox” for a particular developer and environment. In this scenario, each developer administers his or her own application server, without interfering with other application server domains. A small development group may choose to create multiple instances in a shared administrative domain for collaborative development.

In a deployment environment, an administrator can create domains based on application and business function. For example, internal Human Resources applications may be hosted on one or more servers in one Administrative domain, while external customer applications are hosted on several administrative domains in a server farm.

The Application Server supports virtual server capability for web applications. For example, a web application hosting service provider can host different URL domains on a single Application Server process for efficient administration.

For detailed information on administration, see Sun Java System Application Server 9.1 Administration Guide.

General Tuning Concepts

Some key concepts that affect performance tuning are:

The following table describes these concepts, and how they are measured in practice. The left most column describes the general concept, the second column gives the practical ramifications of the concept, the third column describes the measurements, and the right most column describes the value sources.

Table 1–2 Factors That Affect Performance

Concept 

In practice 

Measurement 

Value sources 

User Load

Concurrent sessions at peak load 

Transactions Per Minute (TPM) 

Web Interactions Per Second (WIPS) 

(Max. number of concurrent users) * (expected response time) / (time between clicks) 

Example: 

(100 users * 2 sec) / 10 sec = 20 

Application Scalability

Transaction rate measured on one CPU 

TPM or WIPS 

Measured from workload benchmark. Perform at each tier. 

Vertical scalability 

Increase in performance from additional CPUs 

Percentage gain per additional CPU 

Based on curve fitting from benchmark. Perform tests while gradually increasing the number of CPUs. Identify the “knee” of the curve, where additional CPUs are providing uneconomical gains in performance. Requires tuning as described in this guide. Perform at each tier and iterate if necessary. Stop here if this meets performance requirements. 

Horizontal scalability 

Increase in performance from additional servers 

Percentage gain per additional server process and/or hardware node. 

Use a well-tuned single application server instance, as in previous step. Measure how much each additional server instance and hardware node improves performance. 

Safety Margins

High availability requirements 

If the system must cope with failures, size the system to meet performance requirements assuming that one or more application server instances are non functional 

Different equations used if high availability is required. 
 

Excess capacity for unexpected peaks 

It is desirable to operate a server at less than its benchmarked peak, for some safety margin 

80% system capacity utilization at peak loads may work for most installations. Measure your deployment under real and simulated peak loads. 

Capacity Planning

The previous discussion guides you towards defining a deployment architecture. However, you determine the actual size of the deployment by a process called capacity planning. Capacity planning enables you to predict:

You can estimate these values through careful performance benchmarking, using an application with realistic data sets and workloads.

ProcedureTo Determine Capacity

  1. Determine performance on a single CPU.

    First determine the largest load that a single processor can sustain. You can obtain this figure by measuring the performance of the application on a single-processor machine. Either leverage the performance numbers of an existing application with similar processing characteristics or, ideally, use the actual application and workload in a testing environment. Make sure that the application and data resources are tiered exactly as they would be in the final deployment.

  2. Determine vertical scalability.

    Determine how much additional performance you gain when you add processors. That is, you are indirectly measuring the amount of shared resource contention that occurs on the server for a specific workload. Either obtain this information based on additional load testing of the application on a multiprocessor system, or leverage existing information from a similar application that has already been load tested.

    Running a series of performance tests on one to eight CPUs, in incremental steps, generally provides a sense of the vertical scalability characteristics of the system. Be sure to properly tune the application, Application Server, backend database resources, and operating system so that they do not skew the results.

  3. Determine horizontal scalability.

    If sufficiently powerful hardware resources are available, a single hardware node may meet the performance requirements. However for better availability, you can cluster two or more systems. Employing external load balancers and workload simulation, determine the performance benefits of replicating one well-tuned application server node, as determined in step (2).

User Expectations

Application end-users generally have some performance expectations. Often you can numerically quantify them. To ensure that customer needs are met, you must understand these expectations clearly, and use them in capacity planning.

Consider the following questions regarding performance expectations:

Further Information