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.

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 ThreadsPerChild setting in your httpd.conf file limits the number of concurrently executing users.

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 to Monitor the Web Server" 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 400 MHz x86 processor

Application	CPU requirement (per request)
Static page, 20KB	5 msec
Simple servlet, JDK (Java Developer's Kit) release 1.2	50 msec

Determining Memory Requirements

This section discusses the following memory requirements:

Determining Memory Requirements for the Oracle HTTP Server

The parent HTTP server process consumes up to 6 MB in the resident set. The child process, which handles the requests, consumed up to 12 MB in in-house tests.

Determining Memory Requirements for JServ

A JServ process using JDK 1.2 requires about 7 MB in the resident set at startup. The process will grow to use up to 12MB physical memory. While the memory required may grow to be much larger, it is important to note that NT limits the amount that can be kept in the working set in physical memory. If the process grows quite large, then there may be a large number of page faults in the JServ process, and the paging that results will cause reduced throughput and increased response times. If there is sufficient memory on the host, however, the process will be allowed to cache pages in the system file cache, thereby reducing the necessity to fetch pages from disk. The system file cache memory will be reclaimed by the system if necessary. This means that the most important counter to watch for in the Apache and Jserv processes is the number of page faults (see the Processes tab in the Task Manager). If this is consistently higher than 5 faults per second, and there is little or no system memory available (see the Performance tab in the Task Manager), then adding physical memory is likely to improve performance.

Determining Java Heap Size

For JDK release 1.2, the default maximum heap size is 67 MB.

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.

Determining Memory Requirements for Servlets and OracleJSP pages

In general, OracleJSP pages require more memory than servlets. In in-house tests using JDK release 1.2, a servlet and an OracleJSP required just under 7 MB at startup. In the OracleJSP, the JServ process size continued to grow up to about 12 MB, and then a large number of page faults occurred, decreasing throughput and increasing the average response time.

In the servlet, the JServ process size for a simple "Hello, World" servlet stabilized at 8 MB. The amount of memory needed also depends on whether sessions are being used. With sessions turned off, the OracleJSP page and the servlet stabilized at around 8 MB. You can turn sessions off by including the following line at the top of the page:

<%@ page session="false" %>

You should also set developer mode to false in the jserv.properties file.

Determining the Number of JServ Processes per CPU

Oracle recommends two JServ processes per CPU as a starting point. In-house tests on a server with four CPUs and one JServ process produced many failed requests under load. With two JServ processes, there were occasional errors, but the response time increased dramatically as the load increased.

Using four JServ processes, performance was acceptable. Under heavy load, with 8 JServ processes and the number of concurrent requests per JServ process limited to 10, response time was reduced by 50% and throughput increased.

To limit the number of concurrent requests per JServ process, change the security.maxConnections parameter in the jserv.properties file. This parameter specifies the maximum number of JServ requests that can be handled simultaneously. The default setting of 50 results in exponential increases in response time under load, unless the overall incoming load is restricted (by reducing the ThreadsPerChild value in the httpd.conf file). Oracle recommends that you limit security.maxConnections to 10, to avoid synchronization bottlenecks in the JServ processes.

Note:
If your servlets implement the SingleThreadModel interface, you must reduce security.maxConnections to a value less than the singleThreadModelServlet.maximumCapacity value (the default is 10).

Unless a significant number of the requests on your HTTP server are non-JServ, ensure that the following is true:

(number of JServ processes) x (security.maxConnections)

= (the ThreadsPerChild value) x 2

Otherwise, under high loads, requests will fail due to connection failures between the HTTP server and the JServ engine. The HTTP server passes the request to the next JServ process in the list, but because the security.maxConnections value is exceeded, response time is degraded significantly in waiting for a connection.

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 process sends incoming requests to the JServ processes in a distributed fashion.

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.

3 Sizing and Configuration