Chapter 2   Understanding Tuning and Sizing


This chapter describes performance tuning tips and techniques. It is a concise guide to some of the tunable parameters of iPlanet™ Application Server.

This chapter contains the following topics:

• Why Tune iPlanet Application Server?

• What Is Application Sizing?

• Factors That Affect Sizing

• Understanding Operational Requirements

• Predicting Performance

• General Performance Guidelines

• Performance Tuning Sequence

Why Tune iPlanet Application Server?

---

There are so many variables that influence the performance of an application server that there is no single configuration that performs optimally at every site. Even if the system is sized properly, performance can be significantly enhanced by just a few modifications made to the default deployment.

These modifications can enhance the overall system performance. Certain modifications have a positive impact on the development environment, but adversely effect production environments. The reverse is also true.

Before you tune iPlanet Application Server, you need to assess the exact result you are expecting. This chapter takes you through various tuning and sizing options that you can adopt to get the best out of your iPlanet Application Server.

The process architecture of iPlanet Application Server is represented in the following diagram for easy reference:

Figure 2-1   

iPlanet Application Server Process Architecture

What Is Application Sizing?

---

The sizing of a system is meant to forecast the amount and type of hardware necessary to support a particular user load.

To properly size a system, it is important to understand the characteristics of the load, the characteristics of the application, and the characteristics of the platform (operating system and hardware).

This section of the document discusses the details for measuring the load, the application, the platform, and to estimate the system requirements for the application servers.

Before we can move on to the methods used to size an application, we need to understand the factors that affect sizing.

Factors That Affect Sizing

The following table lists the factors that affect the sizing of an application

Factor

Description

User load

The system load must be proportionate to the hardware required to handle the load.

Application Design & Implementation

An application that performs very little work will be able to handle a lot of users for a given amount of hardware. Often, this kind of application scales poorly because it spends a large percentage of its time waiting for shared resources. Conversely, applications that perform a great deal of computation tend to require much more hardware per user, but scale much better.

An application whose threads contend for shared resources is likely to scale poorly within a single server, spending time waiting for those shared resources. The optimal solution for this would be to employ a number of small servers.

An application that contends for shared resources between servers is likely to scale poorly within a cluster, spending time waiting for shared resources. The optimal solution for this would be to employ fewer, large servers.

Hardware Platform

Raw processor performance is critical to reducing the amount of hardware needed. Generally, applications do not include floating point intensive computation, so internal performance is usually the most important factor. Response time is highly dependent on the performance of the processor.

Safety Margins

Even with high-speed processors, a server can scale poorly if shared resources cause significant contention. Usually, cache design and memory bandwidth play a big role in determining how much extra performance is achieved as processors are added to a server. Factors that affect sizing"> Table 2-1   

Factor	Description
User load	The system load must be proportionate to the hardware required to handle the load.
Application Design & Implementation	An application that performs very little work will be able to handle a lot of users for a given amount of hardware. Often, this kind of application scales poorly because it spends a large percentage of its time waiting for shared resources. Conversely, applications that perform a great deal of computation tend to require much more hardware per user, but scale much better.
	An application whose threads contend for shared resources is likely to scale poorly within a single server, spending time waiting for those shared resources. The optimal solution for this would be to employ a number of small servers.
	An application that contends for shared resources between servers is likely to scale poorly within a cluster, spending time waiting for shared resources. The optimal solution for this would be to employ fewer, large servers.
Hardware Platform	Raw processor performance is critical to reducing the amount of hardware needed. Generally, applications do not include floating point intensive computation, so internal performance is usually the most important factor. Response time is highly dependent on the performance of the processor.
Safety Margins	Even with high-speed processors, a server can scale poorly if shared resources cause significant contention. Usually, cache design and memory bandwidth play a big role in determining how much extra performance is achieved as processors are added to a server.

Factors that affect sizing

Understanding Operational Requirements

---

As you begin to tune simple deployments, the implementation team can establish the general layout of the operational environment based on the requirements of iPlanet Application Server, and your application. This general layout will show the relative position of the system's external interfaces. Before the general layout can be transformed into a more concrete design, implementers need to factor in the following operational requirements of the new system:

• Security

• Availability

• Performance

Security

If you want to encrypt the communication between the browser and the web server, you need to consider the following factors:

• Do you need to encrypt the browser to Web server communications for all or part of the application?

• Will the Web server tier exist in a demilitarized zone (DMZ), separate from the application server tier and backend enterprise systems?

• Is encryption required between the web servers and application servers?

For information on how to encrypt the communication between Web servers and iPlanet Application Server, please refer to Chapter 6, "Enabling High Availability of Server Resources", in iPlanet Application Server Administrator's Guide.

Availability

You should consider the following factors to ensure the availability of an application:

• What are the availability requirements of the application? Is the loss of service acceptable when a machine becomes unavailable?

• Can the loss of a user's session information be tolerated?

• What are the possible weak links with respect to the manner in which the application interacts with other aspects of the environment?

• Can these weak links be reasonably enhanced or are they constants?

• Many companies view a CPU busy rate of 80% as a high-water mark. What is your company's standard?

Performance

You should consider the following factors with regard to performance:

• What are the required response times experienced by the end users for various interactions with the application?

• What are the perceived steady state and peak user loads?

• What is the average and peak amount of data transferred per Web request?

• What is the expected growth in user load over the next 12 months?

For peak user loads, you need to focus on the number of concurrent sessions being managed by the application server. We often find that organizations view peak user load as the total number of possible users rather than the average number of concurrent users. Given this more realistic view of user loads, you'll find that the number of peak users drops dramatically on paper from hundreds of thousands or even millions to tens of thousands of concurrent users.

Defining these operational requirements will help move you to the next stage in understanding the deployment environment. Let us assume that the operational security and availability requirements are such that multiple Web and application server instances, separated by a set of firewalls, will form the basis of the environment. Here, you'll need separate tiers of machines to support the division between the DMZ and the secure, back-end business systems. You'll also need to plan on multiple instances of machines in each tier to enhance the availability of the application.

Proceeding from these assumptions, the layout of the operational environment is further refined, though it does not yet address the exact number or size of machines required by the system. The next step is to develop a basic understanding of how to predict performance and how to size a system.

Predicting Performance

---

Given the factors affecting the sizing process and the general layout of the operational environment, how does one predict either the capacity of a given combination of hardware, or the minimal hardware required to sustain a specified capacity? The best way to answer these questions is to take the data gathered from the discussions in the previous section and plug it into the sizing calculator that is bundled with iPlanet Application Server.

iPlanet provides you with two calculators to help size applications deployed to iPlanet Application Server. The first calculator computes the size of a system (i.e., the number of CPUs and the number of machines in each tier) based on the factors described in the above section. The second calculator computes the maximum capacity of a given hardware configuration.

iPlanet has built these calculators based on a combination of tests, including those for popular application workflows, and has drawn upon publicly available benchmark results for RDBMS and processors. Both calculators assume a fully tuned system.

Apart from using sizing calculators, it is recommended that you develop your own understanding of application sizing based on the following steps:

1. Determine performance on a single CPU

   You need to first determine the largest load that can be sustained with a known amount of processing power. You can obtain this figure by measuring the performance of the application on a uniprocessor machine. You can either leverage the performance numbers of an existing application with similar processing characteristics or, ideally, use the results of basic performance testing done during development.

   While determining performance on a single CPU, you must begin to tune the basic environment. As with any performance test, you must ensure that none of the outlying systems (driver machines, Web servers, database machines, etc.) throttle the test. Otherwise, your performance numbers may be artificially low and will adversely impact the sizing results.

2. Determine vertical scalability

   You need to know exactly how much additional performance is gained when you add processors. That is, you are indirectly measuring the amount of shared resource contention that occurs on the server for this workflow. You can 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 four CPUs generally provides a decent sense of the vertical scalability characteristics of the system.

   Based on your sizing estimates, it's important to exercise the application under load on systems of the target configuration. While determining the vertical scalability, ensure that availability requirements are factored into the configuration. For example, to guarantee that the failure of a single JVM does not result in a loss of all sessions, perform the vertical scalability tests with at least two JVMs and configure session replication between the JVMs.

3. Determine horizontal scalability

   You need to know how much additional performance is gained when you add servers. Again, benchmarking of a cluster of application server systems is required if information on a similar application is not already available. Ensure that you take into consideration high-availability requirements and the attendant session replication configuration as you lay out your horizontal scalability test environment.

   In this case, session replication occurs across application server instances deployed to multiple machines, in addition to session replication across JVMs within each application server instance. Running this suite of tests will provide you with a solid understanding of the performance of the application server. Using this information, you can develop your own custom sizing equations.

   You need to first determine how much load can be sustained with a known amount of processing power. You can obtain that figure by measuring the performance for a given application on a uniprocessor for extrapolating on multiprocessors.

The equation for sizing a basic (single instance installation) High Availablity (HA) site looks like this:

TotalProcessorCount =(P*(1.0-k) * (ks+P*k*K*(1.0-2.0 * K) +sqrt(4.0 *ks*K*(1.0-K)*(ks+P*k*(1.0-2.0*K)))) / ((ks-P*k*K) * (ks-P*K*K));

where:

• P = Performance (throughput) required at peak load. If a maximum level of CPU usage is specified, then divide P by that value. For example, if the servers should never be more than 80% busy for 10,000 users, then P = 10,000/0.80 = 12,500.

• k= (1-CPU scalabality) / (1+ CPU scalability). CPU scalability is measured by running the application on servers with different numbers of CPUs. In this case, CPU scalability is the additional performance gained by adding a second processor. CPU scalability is dependent on the workflow, the application server software, the operating system, and the server hardware.

• ks= raw CPU performance. This is required for each unit of throughput (P) for this application on this hardware. ks is measured on at least one platform and is extrapolated using the ratio of SPECint_base95 performance on the new platform, as against the measured platform.

• K = (1 - server scalability) . (1+server scalability) - server scalability is measured by running the application on clusters with different numbers of servers (or application server instances). In this case, server scalability is the additional performance gained by adding a second appserver of the same performance as the first.

This equation estimates the total (minimum) number of processors needed. This value assumes that the configuration will be optimized. Note that each of these values is different for different applications. Different equations are used to identify the optimal number of clusters, the number of application server instances and the number of processors per server. This value also assumes that the required peak load must be satisfied with one failed server.

Another method for sizing a single server is to establish a throughput rate required for the site and decide if the workflow fits one of three basic examples given below:

• An online store implemented with servlets. Commonly accessed pages are cached.

• An online store implemented with servlets, but there are no commonly accessed pages. So, caching is disabled.

• An online store implemented with a mix of JSPs, servlets, session and entity beans. Caching is disabled.

General Performance Guidelines

---

The following table describes the factors that affect sizing and their impact on an application's performance:

Concept

Applying the Concept

Measurement

Value Sources

User Load

Peak Concurrent Sessions

Transaction Rate (RPM, WIPS)

Number of Peak Concurrent Users / Period between clicks.

Number of Subscribers Session time / Period between sessions.

Application Design and Implementation

Transaction Rate per Measure of CPU performance

RPM per SPECint_base95

Measured from benchmarks

Scalability within a server (additional performance for additional CPU)

%

% based on curve fitting from benchmarks

Scalability within a cluster (additional performance for additional server)

%

% based on curve fitting from benchmarks

Hardware platform

Processor performance (usually integer performance)

Ratio of performance of SPARC®20@40Mhz

SPECint_base95

Scalability (probably cache design & memory bandwidth)

%

% based on curve fitting from benchmarks

Safety Margins

High Availability Requirements.

If yes, size the system assuming that 1 server system is down

Different equations used if High Availability is required.

% Busy High Water Mark

%

Usually 80%; you need to compute the level of acceptable risk. Factors that affect sizing - applying concepts"> Table 2-2   

Concept	Applying the Concept	Measurement	Value Sources
User Load	Peak Concurrent Sessions	Transaction Rate (RPM, WIPS)	Number of Peak Concurrent Users / Period between clicks.
			Number of Subscribers Session time / Period between sessions.
Application Design and Implementation	Transaction Rate per Measure of CPU performance	RPM per SPECint_base95	Measured from benchmarks
	Scalability within a server (additional performance for additional CPU)	%	% based on curve fitting from benchmarks
	Scalability within a cluster (additional performance for additional server)	%	% based on curve fitting from benchmarks
Hardware platform	Processor performance (usually integer performance)	Ratio of performance of SPARC®20@40Mhz	SPECint_base95
	Scalability (probably cache design & memory bandwidth)	%	% based on curve fitting from benchmarks
Safety Margins	High Availability Requirements.	If yes, size the system assuming that 1 server system is down	Different equations used if High Availability is required.
	% Busy High Water Mark	%	Usually 80%; you need to compute the level of acceptable risk.

Factors that affect sizing - applying concepts

Performance Tuning Sequence

---

We recommend that you tune iPlanet Application Server and its associated elements in the following sequence:

• Tuning Your Application

• Tuning iPlanet Application Server

• Tuning the Java Runtime System

• Tuning the Operating System

• Tuning Database Servers

  These topics are discuused in detail in the following chapters.