Previous Contents Index Next |
Sun Java System Application Server Standard and Enterprise Edition 7 2004Q2 Performance and Tuning Guide

> ## Chapter 1
> About Application Server Performance

> This chapter discusses the following topics:

> - Process Overview
> - The Importance of Tuning
> - General Tuning Concepts
> - Performance Tuning Sequence
> - Configuration Files
> - Logging and Performance

> ##

> Process Overview

> The following table outlines the overall administration process, and shows were Performance Tuning fits in the sequence. .

> Table 1-1 Performance Tuning Roadmap

> Step | Description of Task | Location of Instructions
> --- | --- | ---
> 1 | Design: Decide on your high-availability topology and set up your systems | System Deployment Guide
> 2 | Capacity Planning: Make sure the systems have sufficient resources to perform well. | System Deployment Guide, Appendix X
> 3 | Installation: Install the HADB software with or without the Application Server software | Installation Guide
> 4 | Deployment: Run your applications. Familiarize yourself with how to configure and administer the Application Server subsystems and components. | Administrator’s Guide
> 5. | Tuning: Tune your application, Java Runtime System, operating system, high-availability database (HADB), and the Application Server. | Performance Tuning Guide

> ##

> The Importance of Tuning

> Performance can be significantly enhanced by adjusting a few deployment descriptor settings or server configuration file modifications. However, it is important to understand the environment and performance goals. An optimal configuration for a production environment may not necessarily be optimal for a development environment. This guide helps you to understand the tuning and sizing options available, providing you the capabilities and practices to obtain the best performance out of your Application Server.

> ##

> General Tuning Concepts

> The following table describes factors that affect performance. The left most column describes the general concept, the second column gives the practical ramikfications 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 - Applying Concepts

> Concept | Applying the Concept | Measurement | Value Sources
> --- | --- | --- | ---
> User Load | Concurrent Sessions at Peak Load | Transactions Per Minute (TPM) Web Interactions Per Second (WIPS) | ( (Number of Concurrent Users at Peak Load) * Expected Response Time) / (Time between clicks) For example, (100 Concurrent Users * 2 seconds Response Time) / (10 seconds between clicks) = 20.
> Application Scalability | Transaction Rate measured on one CPU | TPM or WIPS | Measured from workload benchmark. Needs to be performed at each tier.
> vertical scalability (additional performance for additional CPU) | 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 later chapters of this guide. Needs to be performed at each tier and iterated if necessary. Stop here if this meets performance requirements.
> horizontal scalability (additional performance for additional server) | 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/or hardware node improves performance.
> Safety Margins | High Availability Requirements. | If system should 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.
> Slack 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.

> ##

> Performance Tuning Sequence

> Ideally, tuning is performed in the following sequence:

> - Tuning Your Application
> - Tuning the Application Server
> - Tuning HADB
> - Tuning the Java Runtime System
> - Tuning the Operating System

> Application tuning is listed first because it tends to produce unexpectedly large improvements in performance—larger than any other tuning operation. So, ideally, that is the first step in the tuning cycle.

> The remaining steps are performed by the system adminstrator. You take those steps when the application has already been tuned, or when application tuning has to wait and you want to improve performance as much as possible in the meantime.

> ##

> Configuration Files

> The files init.conf, <instance_name>-obj.conf, and server.xml are Application Server configuration files containing many attributes that can be modified to improve performance. They are frequently mentioned in this guide and can be found in the following directory:

> <APPSERVER_HOME>/domains/<DOMAIN_NAME>/<SERVER_NAME>/config/

> The following configuration files are located in the directory:

> - admch
> - admsh
> - backup
> - certmap.conf
> - dbswitch.conf
> - default-web.xml
> - generated.server1.acl
> - genwork.server1.acl
> - init.conf
> - keyfile
> - login.conf
> - mime.types
> - obj.conf
> - secure.seed
> - server.policy
> - server.xml
> - server1-obj.conf
> - sun-acc.xml

> APPSERVER_HOME is the installation directory for the Application Server. DOMAIN_NAME and SERVER_NAME refer to the domain and server names for the server instance to be configured.

> The config/backup directories contain a replica of the server configuration files. These files are created by the administration server instance. In general, users should not change these files. If the config files are edited, make a copy of the files and place them in the backup directory. Additionally, the server instance should be restarted.

> ##

> Logging and Performance

> The Application Server produces log messages and exception stack trace output that gets written to the log file. These log messages and exception stacks can be found in the logs directory of the instance. Naturally, the volume of log activity can impact server performance; particularly in benchmarking situations.

> By default, the log level is set to INFO. The log level can be set for all the server subsystems by changing the attribute level in the log_service element. You can override the logging level by adjusting it at a particular subsystem. For example, mdb_container can produce log messages at a different lever than server default by adjusting the log_level attribute under the mdb_container element. To get more debug messages, set the log level to FINE, FINER, or FINEST. Under benchmarking conditions, it may be appropriate to set the log level to SEVERE.

> Note | When using the load balancer, the load balancer plug-in uses the web server logging mechanism to write log messages. The load balancer plug-in uses the default logging level on Sun ONE Web Server (INFO), and Apache Web Server (WARN). The application server log levels - FINE, FINER, and FINEST map to the DEBUG level on the web server.

> Previous Contents Index Next

> Copyright 2004 Sun Microsystems, Inc. All rights reserved.