The purpose of this note is to address some consideration for tuning Tuning Apache 1.3 for Oracle Access Manager Web Components.
Tuning Apache 1.3 for Oracle Access Manager Web Components
Apache 1.3 uses a process model for serving multiple http requests at once. This is different from the single process (thread) model employed by other Web servers, which manage several requests simultaneously in one process.
Each subordinate Apache worker-process responds to an incoming http request independently of every other worker-process. Several parameters in the Apache server configuration file (httpd.conf) affect how an Apache server decides to create or destroy worker processes.
The following affect the performance of the server:
MaxServers: The number of simultaneous http requests that a system can handle depends on the maximum performance of the system.
Performance Tuning: Performance tuning for a system should be done using an http load generating tool such as the ab program supplied with Apache.
MaxSpareServers: Sets the desired maximum number of idle child server processes. An idle process is one which is not handling a request. If there are more than MaxSpareServers idle, then the parent process will kill off the excess processes.
To preserve as much state as possible in the server, set the MaxSpareServers to a high value.
Setting this value to the maximum of 255 keeps all Apache worker-processes available indefinitely, but it does not provide an opportunity for worker-process recycling during low-load periods.
MaxClients: Sets the limit on the number of simultaneous requests that can be supported. As child processes are spawned to handle requests, no more than MaxClients number of processes will be created. Any connection attempts over the MaxClients limit will normally be queued, up to a number based on the ListenBacklog directive. Once a child process is freed at the end of a different request, the connection is then serviced.
To configure more than 256 clients the HARD_SERVER_LIMIT entry in httpd.h must be modified and Apache must be recompiled. With a high MaxClients setting and high load, the server will attempt to serve all requests immediately.
Memory constraints must be taken into account when setting this option. If the memory consumption of a child process (~1 MB in plain Apache, ~10 MB with mod_perl enabled) multiplied by the number of running child processes is larger than available system memory, then child processes will be swapped out of main memory to disk. A high number of disk swaps can have a severe impact on server performance.
MaxClients should be configured as small as possible to preserve performance. Calculation of this value is straight-forward:
MaxClients = (Total RAM dedicated to web server) / (Child's max memory consumption) Or, taking into account memory shared by child processes:
MaxClients = (Total_RAM – Min_Shared_RAM_per_Child) / (Max_Child_Process_Size – Min_Shared_RAM_per_Child)
MaxRequestsPerChild: The MaxRequestsPerChild directive sets the limit on the number of requests that an individual child server process will handle. After MaxRequestsPerChild requests, the child process will die. If MaxRequestsPerChild is 0, then the process will never expire.
The primary purpose of this option is as a safety mechanism. Regularly recycling child processes prevents poorly behaving child processes from consuming memory resources. This safety mechanism is not unreasonable, but the start-up delay for Oracle Access Manager Web components (also known as plug-ins) is noticeable at the Web browser.
If you use this parameter, set it high enough for end users to rarely notice the startup delay. Oracle Access Manager plug-ins are designed to run under Web servers without this safety mechanism.
ThreadsPerChild
Available only with Apache 1.3 running on Windows. This directive tells the server how many threads it should use. This is the maximum number of connections the server can handle at once; be sure and set this number high enough for your site if you get a lot of hits.
This directive has no effect on Unix systems. Unix users should look to StartServers and MaxRequestsPerChild.
MinSpareServers: Sets the desired minimum number of idle child server processes. An idle process is one that is not handling a request.
If there are fewer than MinSpareServers idle, then the parent process creates new children at a maximum rate of 1 every second. Use this with the Policy Manager.
Note:
Setting this directive to some value m ensures that you will always have at least n + m httpd processes running when you have n active client requests.
Because of the fact that Oracle Access Manager plug-in initialization is deferred until the first request, using a high value for the MinSpareServers parameter provides minimal advantage.
However, it is useful to keep this parameter as high as possible. For dedicated Web server systems, this should pose no great burden.
StartServer: As with the MinSpareServers parameter, the advantage of the StartServers parameter is limited by the delayed initialization of the Oracle Access Manager plug-ins.
Appropriate values for the preceding parameters depend on the expected load and the performance class of the systems involved, including the Access Server and LDAP server. Apache servers on very high performance systems with high expected loads may be recompiled with a larger limit on the number of worker processes.
These systems may see a greater performance impact on the StartServers and MinSpareServers parameters for dealing with sudden load spikes.
You may need to adjust operating system limits for the Access Server for proper operation. In particular, the maximum number of file descriptors available for any one Access Server may need to be increased beyond the default value.
Configuring more than one connection between each Apache-based WebGate and an Access Server may quickly exceed this limit.
Access Server Tuning and Resolving Bottlenecks
Configuration of Apache 1.3 has an impact through the chain of communication from the WebGate to Access Server. Configuration changes may need to take place at Access Server, WebGate, and Apache levels to achieve desired performance levels and avoid bottlenecks. The four major configuration options are:
1. The number of Access Server connections allocated to the WebGate
2. The MaxClient Apache configuration option
3. The ThreadsPerChild Apache configuration option (on Windows only)
4. Number of Access Servers and/or number of Service Threads allocated to the Access Server(s)
Fine-tuning WebGate Connections to Access Server:
Take the following hypothetical examples:
Assumption: Access Server services each WebGate request in one second.
Configuration Scenario 1:
One Access Server (60 service threads) configured with one WebGate (Number of connections from WebGate to Access Server = 1) on Apache 1.3 Windows (MaxClient=1, ThreadsPerChild=60)
To fully utilize Access Server's 60 service threads, 60 requests per second should be sent by the WebGate. The bottleneck in this scenario is the number of connections from WebGate to Access Server as a single connection will be used by all requests.
Configuration Scenario 2:
One Access Server (60 service threads) configured with one WebGate (Number of connections from WebGate to Access Server = 5) on Apache 1.3 Windows (MaxClient=1, ThreadsPerChild=60)
Scenario 2 eases the bottleneck as 5 connections should be sufficient to handle the 60 req/sec load.
Configuration Scenario 3:
One Access Server (60 service threads) configured with one WebGate (Number of connections from WebGate to Access Server = 1) on Apache 1.3 Windows (MaxClient=2, ThreadsPerChild=30)
Scenario 3 eases the bottleneck by adding another Apache child process to service requests, however each child process may still have contention on the single Access Server connection allocated to it.
Configuration Scenario 4:
One Access Server (60 service threads) configured with one WebGate (Number of connections from WebGate to Access Server = 5) on Apache 1.3 Windows (MaxClient=2, ThreadsPerChild=30)
Scenario 4 uses both approaches.
Fine-Tuning MaxClient:
Configuration Scenario 1:
One Access Server (60 service threads) configured against one WebGate (no of connection from WG to AAA is 5) on Apache (ThreadsPerChild =10).
Assuming still that Access Server handles a request in one second, each thread will generate 1 request per second. Here each process of Apache has 10 threads and so the total rate of requests per Apache child process will be 10 req/sec. To fully utilize Access Server's 60 service threads, we can set the the MaxClient option to 6.
Configuration Scenario 2:
Two Access Server (60 service threads) configured against one WebGate (no of connection from WG to AAA is 5) on Apache (ThreadsPerChild =10).
With two Access Servers, 120 service threads are available to handle requests. To fully utilize these threads, MaxClient may be set to 12
Fine-Tuning ThreadPerChild
Configuration scenario 1:
One Access Server (60 service threads) configured against one WebGate (no of connection from WG to AAA is 5) on Apache (MaxClient=1).
Here we can set ThreadsPerChild to 60.
Configuration Scenario 2:
One Access Server (60 service threads) configured against one WebGate (no of connection from WG to AAA is 5) on Apache (MaxClient=2).
Here we can set ThreadsPerChild to 30.
Configuration Scenario 3:
Two Access Server (60 service threads) configured against one WebGate (no of connection from WG to AAA is 5) on Apache (MaxClient=10).
Here we can set ThreadsPerChild to 12.
Summary:
Achieving the proper balance of options to support desired load requires that the options be taken together. Load requirements or resource constraints tend to dictate one or more of these configuration options and the rest are derived from there.
1. Depending on the load to be supported on the webserver, configure values of MaxClient and ThreadsPerChild as follows
a. Compute MaxClient value
b. ThreadsPerChild = "Number of parallel requests on web server" / MaxClient
2. Once this is done, Access Server and WebGate configurations must be tuned accordingly
a. Threads in each Apache process share the same set of connections to the Access Server. If ThreadsPerChild is high, there may be contention for a small number of connections. To solve this increase the number of connections WebGate has available to it.
b. The maximum number of connections that may be established to Access Server is MaxClient * (Number of WebGate-to-Access Server connections). If this value approaches very high levels, resource constraints (memory, socket, network load) may be reached, causing system stability issues. To solve this, decrease connections or MaxClients.
c. The maximum possible number of requests that may be simultaneously sent to the Access Server is a product of (MaxClient * ThreadsPerChild). If the number of Service Threads configured in Access Server is less than the in-flow of requests, the average wait-time for requests will increase. In this case, increasing the number of service threads in the Access Server or adding additional Access Servers to the environment will help resolve the bottleneck.
Policy Manager Tuning Factors
Policy Manager performance may be impacted by both Apache and Policy Manager configuration parameters.
The following factors should be considered when tuning the Policy Manager for Apache:
• The idle child processes ensure that a new incoming request is serviced immediately. The more spare child processes, the faster the ramp up.
• Each child process opens separate connections to the directory server. The more child processes you have, the more directory server connections you have.
Assuming that each user is using one browser, there are four to five simultaneous requests to the Web server for images and js and HTML from the browser.
Assuming that there are four simultaneous users, the total number of simultaneous requests to the Web server is 4 * 5 = 20.
Given these factors, Oracle recommends the following to maintain a balance between how fast a new user is serviced and the number of connections to the directory server:
• MaxClients = 25
• MinSpareServers = 4
• MaxSpareServers = 5
Note:
The Policy Manager does not open connections on Web Server startup.
Instead, the Policy Manager creates connections on the first request.
To help compensate for any delay when the Policy Manager creates connections, the Policy Manager may be configured such that all directory server connections for all directory server profiles are set to 1
In this case, the Apache configuration may be as follows:
• MinSpareServers = 1
• MaxSpareServers = 2
• MaxServers = 2
In the preceding case, the Policy Manager responds in a reasonable time with some delay on the initial request.
