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 memory consumption, I/O issues, and network and software constraints.

Contents

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" for information on measuring CPU utilization.

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

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:
The MaxClients setting in your httpd.conf file limits the number of concurrently executing users. See "MaxClients" for information on the MaxClients directive.

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 population^{Foot 1}	Think time (sec)^{Foot 2}	Service time (sec)^{Foot 3}	Range of concurrent users^{Foot 4}	Average response Time (sec)^{Foot 5}	Requests per second (throughput)^{Foot 6}	CPU utilization (%)^{Foot 7}
100	0	0.3	100	5.2	19	99
100	1	0.3	65-100	4.2	19	99
100	10	0.3	0-32	0.9	9	48
100	10	0.6	0-53	2.9	8	80

^{Foot 1} User population - total users.
^{Foot 2} Think time - the time the user is not engaged in actual use of the processor (the time between requests).
^{Foot 3} Service time (seconds) - elapsed time to complete the operation measured for a single user.
^{Foot 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" for information on server-status.
^{Foot 5} Average response time - response time measured at the client under load.
^{Foot 6} Requests per second (throughput) - number of requests processed.
^{Foot 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 a 336 MHz SPARC processor

Application	CPU requirement (per request)
Static page, 20K	5 ms
Simple servlet, JDK 1.2	20 ms
Simple servlet, JDK 1.1.8	40 ms
Medium application	100-200 ms
Complex application	400-600 ms

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 "SSL Session Caching".

Determining Memory Requirements

This section discusses memory requirements for the following components:

Memory for Non-HTTP Server Software and Operating System

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.

For a discussion on memory usage in Solaris, see the white paper entitled "The Solaris Memory System: Sizing, Tools and Architecture" at:

http://www.sun.com/sun-on-net/performance/vmsizing.pdf

HTTP Server Memory Requirements

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 1.2 requires 12-15 MB at startup. Using JDK 1.1.8, it requires 10 MB.

Determining Java Heap Size

For JDK 1.1.8, the default maximum heap size is 16MB. For JDK 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 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.

Servlet and OracleJSP pages Memory Requirements

OracleJSP pages (Oracle's implementation of Sun's JavaServer Pages) and servlets require different amounts of memory, depending on the version of the JDK used. The chart below 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 1.1.8	JDK 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 150K to 200K for Java applications, plus the size of the server processes. For Java applications, the base process is approximately 12-15 MB.

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

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

Number of JServ Processes

Oracle recommends about 2 JServ processes per CPU as a starting point. The default thread setting (security.maxConnections=50) in the JServ configuration file is also a good starting point. (See "Load Balancing" for instructions on changing parameters in the configuration files.)

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. This is because the httpd process (mod_jserv) sends incoming requests to the JServ processes in a distributed fashion. See "Load Balancing" for details on how the requests are distributed among the available JServ engines. (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.)

Figure 3-1 Request distribution

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

3 Sizing and Configuration