Oracle 9i Application Server Oracle HTTP Server powered by Apache Performance Guide Release 1.0.2 for Windows NT Part Number A86676-01 |
|
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:
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.
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.
Table 3-1 provides an example of the impact of think time and service time on the concurrency and resulting performance of a system.
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 |
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. |
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.
Application | CPU requirement (per request) |
---|---|
Static page, 20KB |
5 msec |
Simple servlet, JDK (Java Developer's Kit) release 1.2 |
50 msec |
This section discusses the following memory requirements:
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.
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.
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=-mx
128m
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.
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.
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.
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. |
|
Copyright © 2000 Oracle Corporation. All Rights Reserved. |
|