Skip Headers

Oracle9i Application Server Oracle HTTP Server powered by Apache Performance Guide
Release 1 (v1.0.2.1) for AIX-Based Systems, Compaq Tru64 UNIX, HP 9000 Series HP-UX, Linux Intel, and Sun Solaris Intel

Part Number A90444-01
Go To Documentation Library
Library
Go To Table Of Contents
Contents
Go To Index
Index

Go to previous page Go to next page

3
Sizing and Configuration

This chapter provides guidelines for sizing and configuration which can help you meet performance goals. It also discusses performance factors such as CPU and memory consumption.

This chapter contains the following sections:

Sizing your Hardware and Resources

In addition to the minimum installation recommendations, your hardware resources need to be adequate for the requirements of your specific applications. To avoid hardware-related performance bottlenecks, each hardware component should operate at no more than 80% of capacity. See "Using the sar Utility (AIX, HP-UX, Intel Solaris)" for information on measuring CPU utilization.

Processor and memory resources in particular should be allocated generously, for the maximum user load expected.

See Also:

"Using the sar Utility (AIX, HP-UX, Intel Solaris)" for information on measuring CPU utilization.  

Understanding Concurrent Users and User Population

The amount of hardware resources required varies based on the application. A common mistake is to use resource estimates that do not incorporate user think time and network latencies. In sizing applications, you must have some idea of the relationship between the number of potential users and the number of concurrent users. This is determined by the think time and the average response time for your application.

To determine memory requirements, you also need to consider the number of concurrent executing users (not the total user population) times the cost per user.


Note:

TMaxClients setting in your httpd.conf file limits the number of concurrently executing users. See "Configuring the MaxClients Parameter" for more information.  


Table 3-1 provides an example of the impact of think time and service time on the concurrency and resulting performance of a system.

Table 3-1 Concurrent executing users
User populationFoot 1  Think time
(sec)Foot 2
 
Service time
(sec)Foot 3
 
Range of concurrent
usersFoot 4
 
Average response Time (sec)Foot 5  Requests per
second (throughput)Foot 6
 
CPU
utilization (%)Foot 7
 

100 

0.3 

100 

5.2 

19 

99 

100 

0.3 

65-100 

4.2 

19 

99 

100 

10 

0.3 

0-32 

0.9 

48 

100 

10 

0.6 

0-53 

2.9 

80 

1 User population - total users.
2 Think time - the time the user is not engaged in actual use of the processor (the time between requests).
3 Service time (seconds) - elapsed time to complete the operation measured for a single user.
4 Range of concurrent users - the number of users measured on the server, taken in snapshots from the server-status display (requests currently being processed). See "Using the mod_status Utility to Monitor the Web Server" for information on server-status.
5 Average response time - response time measured at the client under load.
6 Requests per second (throughput) - number of requests processed.
7 CPU utilization - average total CPU utilization as a percentage.

Determining CPU Requirements

For most applications, the majority of the CPU utilization is spent in processing the application's code. The CPU requirement of any application depends on its complexity and workload, as shown in Table 3-2.

You will need to monitor the CPU requirements of applications throughout the development cycle. See Chapter 2, "Monitoring Your Web Server" for information on how to do this.

Table 3-2 Application CPU requirements on a336 MHz Sun SPARC processor
Application  CPU requirement (per request) 

Static page, 20KB 

5 msec 

Simple servlet, JDK (Java Developer's Kit) release 1.2 

20 msec  

Simple servlet, JDK release 1.1.8 

40 msec 

Medium application 

100-200 msec 

Complex application  

400-600 msec 

Secure Sockets Layer Impact on CPU Requirements

Secure Sockets Layer (SSL) is a protocol used for transmitting documents securely over the Internet. URLs for Web pages that require an SSL connection begin with https instead of http.

Establishing an SSL connection is costly in terms of response time and CPU utilization. For example, a request with a response time of 0.5 seconds without SSL generated a response time of 1.7 seconds with SSL (measured on an internal 100 Mbps network). Most of the performance cost in using SSL is in establishing the connection (approximately 125 ms of CPU time per connection on a 336 Mhz processor).

The high connection cost is incurred for the first connection in a client's SSL session, because the HTTP Server can cache the SSL session information, reducing the overhead for subsequent connections. For more information, see "Enabling SSL Session Caching".

Determining Memory Requirements

This section discusses the following memory requirements:

Determining Memory Requirements for Operating System Software

In an idle system with memory resources freely available, your operating system statistics may indicate that the resident memory usage is close to the virtual size. As users place more load on the system, the operating system reclaims unneeded memory from these processes, and the amount of resident memory they consume decreases. If you are monitoring your own system, take snapshots of processes at varying usage levels.

Refer to your operating system hardware and software documentation for more information on measuring and tuning operating system memory usage. You can monitor memory usage and processor statistics with standard operating system tools. See Chapter 2, "Monitoring Your Web Server" for more information.

Sun recommends reserving 15% of the overall real memory on the system for the kernel and other system overhead.

Determining Memory Requirements for the Oracle HTTP Server

In a series of tests of listener memory usage, each HTTP listener used (at startup) approximately 400K of resident memory. This size increased by 500-600K per process when the listener was active. When it was dormant, the operating system reduced the listener's memory usage back to the startup size.

Using standard operating system tools, you can examine resident memory sizes. If you look at a listener process, you will see that it is larger than the figure above because the displayed size includes shared memory.

JServ Memory Requirements

A JServ process using JDK release 1.2 requires 12-15 MB at startup. Using JDK release 1.1.8, it requires 10 MB.

Determining Java Heap Size

For JDK release 1.1.8, the default maximum heap size is 16MB. For JDK release 1.2, it is 24MB.

To maximize performance, set the maximum heap size to accommodate application requirements. To determine how much Java heap you need, include calls in your program to the Runtime.getRuntime().totalMemory() and Runtime.getRuntime().freeMemory methods in the java.lang package. Subtract free memory from total memory; the difference is the amount of heap that the application consumed.

Suppose you determine that you need 128MB of heap. To change the heap size, you would set the maximum Java heap size in the jserv.properties file for automatic mode:

wrapper.bin.parameters=-mx128m

In manual mode, if more than one JServ process is running, the heap size must be set on the command line or in the startup script for each JServ process.

When a JServ process exceeds its maximum heap size, the process terminates. In automatic mode, a new process is started, but performance is degraded significantly. In manual mode, a terminated process will not be restarted, so ensure that the heap size is sufficient.


Note:

The process size reported by utilities such as top or ps will be larger than the maximum heap size, because private memory is added to the maximum heap size.  


Determining Memory Requirements for Servlets and OracleJSP pages

OracleJSP pages (Oracle's implementation of Sun's JavaServer Pages) and servlets require different amounts of memory, depending on the release of the JDK used. Table 3-3 compares memory requirements for a simple servlet and an Oracle JSP page under load with 10-30 active threads. The servlet did not use sessions. The OracleJSP page had sessions on (the default).

Table 3-3 Servlet and OracleJSP pages memory
Component  JDK release 1.1.8  JDK release 1.2 

Servlet 

10MB 

24MB 

OracleJSP page 

10MB 

32MB 

The amount of memory needed depends on whether sessions are used; a session consumes about 0.5KB. For maximum performance, if sessions are not being used, turn them off in the OracleJSP application as follows:

<%@ page session="false" %>
<html><body>
HelloWorld
</body></html>

As a starting point, figure that each active user consumes at least 150 KB to 200 KB for Java applications, plus the size of the server processes. For Java applications, the base process size is approximately 12-15 MB.

An application's memory needs also depend on its size, the amount of data cached, and other factors.

See Also:

The OracleJSP Developer's Guide and Reference in the Oracle9i Application Server documentation library for more information on OracleJSP pages. 

Determining the Number of JServ Processes per CPU

Oracle recommends two JServ processes per CPU as a starting point. The default thread setting (security.maxConnections=50) in the JServ configuration file (jserv.conf) is also a good starting point.

If your application code performs a lot of synchronization, or creates many new Java objects, then you should consider increasing the number of JServ processes, while limiting the number of threads per process to between 10 and 20. In this way you avoid increased queuing and processing required for object synchronization in the JVM (Java virtual machine). This is because the httpd (mod_jserv) process sends incoming requests to the JServ processes in a distributed fashion. (Readers familiar with the Oracle Application Server will recall that requests are sent to a servlet engine until its thread limit is reached, and subsequent requests are sent to the next servlet engine.) This difference is illustrated in Figure 3-1.

Figure 3-1 Request distribution


Text description of threads.gif follows.
Text description of the illustration threads.gif

See Also:

"How to Perform Load Balancing" for instructions on changing parameters in the configuration files, and details on how requests are distributed among the available JServ engines.  


Go to previous page Go to next page
Oracle
Copyright © 2001 Oracle Corporation.

All Rights Reserved.
Go To Documentation Library
Library
Go To Table Of Contents
Contents
Go To Index
Index