| Oracle® Application Server Release Notes 10g Release 2 (10.1.2) for Solaris Operating System (SPARC) B14500-23 |
|
 Previous |
 Next |
| Oracle® Application Server Release Notes 10g Release 2 (10.1.2) for Solaris Operating System (SPARC) B14500-23 |
|
Previous |
Next |
This chapter describes issues associated with Oracle COREid Federation. It includes the following topic:
This section describes a general issue and workaround. It includes the following topic:
This note explains how to tune the Oracle COREid Federation Web Proxy. It contains these topics:
The Oracle COREid Federation product consists primarily of two components:
The federation server, a J2EE application which is packaged with the Apache Tomcat servlet container;
and
A web proxy, which is based on the Apache 2.0 HTTP server and includes the ability to communicate with the federation server for client certificate authentication.
As a site moves from the pilot and testing stages to production deployment of Oracle COREid Federation, it is important to pay attention to performance, in particular:
scalability
reliability and failure handling
Essential to both these areas is the tuning of the Apache 2.0 HTTP server which performs the request handling tasks. This document describes the Apache process models, tuning parameters, and performance considerations for your Oracle COREid Federation deployment.
|
Note: The Apache 2.0 HTTP server is a third-party product and is discussed here solely in connection with and support of Oracle COREid Federation deployment. For definitive product details about Apache 2.0 HTTP server, contact the Apache Software Foundation. |
Various Apache MPM models are available:
On Windows, the Apache 2.0 HTTP server supports an MPM architecture named Windows MPM, which uses a single multi-threaded process to handle all the requests.
Two Multi-Processing Module (MPM) architectures are available for the Apache 2.0 HTTP server on UNIX/Linux platforms:
Apache MPM Prefork
The Apache MPM prefork module implements a non-threaded, pre-forking web server which provides a process model that is equivalent to the Apache 1.3 model. In this model, a single control process launches multiple child processes, each of which is single threaded. Each child process listens for connection requests and serves them when they arrive. Thus, each request is handled by one single-threaded process.
MPM prefork is the default MPM for the Apache 2.0 HTTP server. It is the MPM model utilized in the Oracle COREid Federation web proxy.
Apache MPM Worker
The Apache MPM worker module implements a multi-process, multi-threaded web server. In this model, a single control process launches multiple child processes; each child process launches a fixed number of server threads as well as a listener thread which listens for connection requests and passes them to a server thread for processing when they arrive.
|
Note: The COREid Federation web proxy only provides the prefork MPM on Linux. MPM is a compile-time setting for Apache, so the proxy cannot be reconfigured to use the worker MPM. Hence, the worker MPM configuration options cannot be applied to the COREid Federation web proxy. |
If you have a relatively small number of concurrent requests and the machine is not resource-constrained, there should be no significant performance difference between the worker and prefork MPMs.
An advantage afforded by the worker MPM is its scalability. It can handle more requests using fewer (albeit larger) processes. But this scalability comes at a cost:
Added complexity in terms of threading
A downside in terms of failure handling
In the single-threaded prefork MPM case, in the event of failure of a loaded module, the core dump only affects a single request, namely the request that was being processed by that process. In the worker model, such a core dump will bring down all the requests being handled by all the threads in the given process.
Increasing the number of threads (in the worker model) to increase the scalability also increases the number of requests exposed to a process failure.
Several parameters factor into the tuning of the prefork MPM model utilized in the Oracle COREid Federation web proxy:
MaxClients - This parameter controls the maximum number of concurrent requests the server can handle.
StartServers - This is the number of child processes to start when the listener is started. Set this parameter to approximately the average number of concurrent users you would like the server to handle.
MinSpareServers and MaxSpareServers - These parameters define the desired minimum and maximum number of idle child processes respectively. They can be set to relatively large numbers unless memory is very constrained.
MaxRequestsPerChild - This parameter indicates how many requests a child process should handle before it is recycled (by the server killing old processes and starting new ones). It is provided for use with less reliable modules that may leak memory or other resources. You can typically set this value to 0, which means the child processes will never recycle.
So for example, if on average you expect the server to be handling 75 concurrent requests with sporadic peaks of say 150, settings like the following are suggested:
MaxClients 200 StartServers 75 MinSpareServers 20 MaxSpareServers 50
Several parameters factor into the tuning of the worker MPM model:
ThreadsPerChild - This parameter controls the number of threads deployed by each child process.
MaxClients - This parameter determines the maximum total number of threads that can be launched.
StartServers - This is the number of processes that will initially be launched.
MinSpareThreads and MaxSpareThreads - Apache tracks the total number of idle threads in all processes, and keeps this number within the limits specified by MinSpareThreads and MaxSpareThreads by forking or killing processes.
MaxRequestsPerChild - This parameter controls how frequently the server recycles child processes by killing old ones and launching new ones.
ServerLimit - This is a hard limit on the number of active child processes.
For suggested configuration values and related information, see http://httpd.apache.org/docs/2.0/mod/worker.html.
You will find it helpful to collect the following information for Oracle COREid Federation web proxy performance analysis:
Settings of key tuning parameters.
For Apache MPM prefork, these include:
MaxClients
StartServers
MinSpareServers
MaxSpareServers
MaxRequestsPerChild
For Apache MPM worker, they include:
MaxClients
StartServers
ThreadsPerChild
MinSpareThreads
MaxSpareThreads
MaxRequestsPerChild
Output of mod_status
This output is very useful to show what every processing unit (thread/process) in Apache is doing, including what URL is being processed, the state of the request (reading from client, processing requests, writing response, and so on).
A dump from mod_status while there are requests hanging tells which processes are handling those requests and the state of those processes when this occurs.
For information about interpreting mod_status output, see:
Stack Trace of Processes
Examine the dump of mod_status to obtain pid of a hanging process, and use this to obtain a stack trace of the processes. This should be very useful in determining where the request is stuck.
See appropriate platform documentation for the relevant tool to obtain the stack trace. For example, the Linux man pages provide details about pstack:
Monitoring the performance of the Oracle COREid Federation web proxy is critical as you scale up the number of users. Performance tuning is achieved by managing key Apache MPM configuration parameters, and by gathering mod_status output and stack dumps of hanging processes for analysis.
Additional information about Apache MPM modules is available on the Web at:
http://httpd.apache.org/docs/2.0/mod/prefork.html (prefork model)
http://httpd.apache.org/docs/2.0/mod/worker.html (worker model)
