You can tune Oracle HTTP Server (OHS) to optimize its performance as the web server component for Oracle Fusion Middleware.
The configuration examples and recommended settings are for illustrative purposes only. Consult your own use case scenarios to determine the configuration options that can provide performance improvements.
Oracle HTTP Server (OHS) is the Web server component for Oracle Fusion Middleware.
It provides a listener for Oracle webLogic Server and the framework for hosting static pages, dynamic pages, and applications over the web. Oracle HTTP Server is based on the Apache 2.4.x infrastructure, and includes modules developed specifically by Oracle. The features of single sign-on, clustered deployment, and high availability enhance the operation of the Oracle HTTP Server.
For more information on the Apache open-source software infrastructure, see the Apache Software Foundation at
Oracle Fusion Middleware automatically and continuously measures runtime performance for Oracle HTTP Server.
The performance metrics are automatically enabled; you do not need to set options or perform any extra configuration to collect them. If you encounter a problem, such as an application that is running slowly or is hanging, you can view particular metrics to find out more information about the problem.
Fusion Middleware Control provides real-time data. See Managing and Monitoring Server Processes in Oracle Fusion Middleware Administering Oracle HTTP Server.
For monitoring, Oracle HTTP Server uses the Dynamic Monitoring Service (DMS), which collects metrics for every functional piece. You can review these metrics as needed to understand system behavior at a given point of time. This displays memory, CPU information and the minimum, maximum, and average times for the request processing at every layer in Oracle HTTP Server. The metrics also display details about load level, number of threads, number of active connections, and so on, which can help in tuning the system based on real usage.
Tuning configurations may improve the performance of the Oracle HTTP Server. Always consult your own use case scenarios to determine if these settings are applicable to your deployment.
Oracle HTTP Server uses directives in the
httpd.conf configuration file. This configuration file specifies the maximum number of requests that can be processed simultaneously, logging details, and certain limits and time outs.
See the Oracle HTTP Server, see Understanding Oracle HTTP Server Management Tools in Oracle Fusion Middleware Administering Oracle HTTP Server.
Oracle HTTP Server supports three different Multi-Processing Modules (MPMs) by default. The MPMs supported are:
Worker: It uses Multi-Process-Multi-Threads model and is the default MPM on all platforms other than Microsoft Windows platforms. Multithread support makes it more scalable by using fewer system resources and multiprocess support makes it more stable.
WinNT: This MPM is for Windows platforms only. It consists of a parent process and a child process. The parent process is the control process, and the child process creates threads to handle requests.
Prefork: This is Apache 1.3.x style and uses processes instead of threads. It is considered the least efficient MPM.
Event: This MPM is designed to allow more requests to be served simultaneously by passing off some processing work to supporting threads, freeing up the main threads to work on new requests. It is based on the worker MPM, which implements a hybrid multiprocess multithreaded server.
The directives for each MPM type are defined in the
ORACLE_INSTANCE/config/fmwconfig/components/OHS/<componentName>/httpd.conf. The default MPM type is the event MPM. To use a different MPM (such as prefork MPM), edit the
The information here is based on the use of worker and WinNT MPMs, which use threads. The directives listed might not be applicable if you are using the prefork MPM. If you are using Oracle HTTP Server based on Apache 1.3.x or Apache 2.2 with prefork MPM, refer to the Oracle Application Server 10g Release 3 documentation at
Table 6-1 Oracle HTTP Server Configuration Properties
This directive maps to the Maximum Queue Length field on the Performance Directives screen.
Specifies the maximum length of the queue of pending connections. Generally no tuning is needed. Some operating systems do not use exactly what is specified as the backlog, but use a number based on, but normally larger than, what is set.
Default Value: 511
This directive maps to the Maximum Requests field on the Performance Directives screen.
This parameter is not available in mod_winnt (Microsoft Windows). Winnt uses a single process, multithreaded model and is controlled by the
Specifies a limit on the total number of servers running, that is, a limit on the number of clients who can simultaneously connect. If the number of client connections reaches this limit, then subsequent requests are queued in the TCP/IP system up to the limit specified with the
You can configure the
Conversely, when system resources are saturated, increasing
If the server handles persistent connections, then it might require sufficient concurrent httpd or thread server processes to handle both active and idle connections. When you specify
If you have sufficient capacity,
The maximum allowed value for
Default Value: 150
This directive maps to the Initial Child Server Processes field on the Performance Directives screen.
Specifies the number of child server processes that are created on startup. If you expect a sudden load after restart, set this value based on the number of child servers that are required.
The following parameters are inter-related and applicable only on UNIX platforms (worker_mpm):
On the Windows platform (mpm_winnt), as well as UNIX platforms, the following parameters are important to tune:
Each child process has a set of child threads that are defined for them and that can actually handle the requests. Use
The values of
Default Value: 2
This parameter is not available in mod_winnt (Microsoft Windows). Winnt uses a single process, multithreaded model
Specifies an upper limit on the number of server (child) processes that can exist or be created. This value overrides the
Default Value: 16
Specifies the upper limit on the number of threads that can be created under a server (child) process. This value overrides the
This directive maps to the Threads Per Child Server Process field on the Performance Directives screen.
Sets the number of threads created by each server (child) process at startup.
Default Value: 64 when mpm_winnt is used and 25 when worker MPM is used.
At startup, Oracle HTTP Server creates a parent process, which creates several child (server) processes as defined by the
After startup, based on load conditions, the number of server processes and server threads (children of server processes) in the system are controlled by
This directive maps to the Max Requests Per Child Server Process field on the Performance Directives screen.
Specifies the number of requests that each child process is allowed to process before the child process dies. The child process ends to avoid problems after prolonged use when Apache (and any other libraries it uses) leak memory or other resources. On most systems, it is not needed, but some UNIX systems have notable leaks in the libraries. For these platforms, set
This value does not include
Note: Windows systems
These directives map to the Maximum Idle Threads and Minimum Idle Threads fields on the Performance Directives screen.
These parameters are not available in
Controls the server-pool size. Rather than estimating how many server threads you need, Oracle HTTP Server dynamically adapts to the actual load. The server tries to maintain enough server threads to handle the current load, plus a few more server threads to handle transient load increases such as multiple simultaneous requests from a single browser.
The server periodically checks how many server threads are waiting for a request. If there is fewer than
This directive maps to the Request Timeout field on the Performance Directives screen.
The number of seconds to wait for an incoming request to be received before sending a time-out.
Default Value: 300
This directive maps to the Multiple Requests Per Connection field on the Performance Directives screen.
Whether to allow persistent connections (more than one request per connection). Set to Off to deactivate.
Default Value: On
The maximum number of requests to allow during a persistent connection. Set to 0 to allow an unlimited amount.
If you have long client sessions, consider increasing this value.
Default Value: 100
This directive maps to the Allow With Connection Timeout (seconds) field, which is located under the Multiple Requests Per Connection field, on the Performance Directives screen.
Number of seconds to wait for the next request from the same client on the same connection.
Default Value: 5 seconds
Number of objects that a program uses to read or write to an open file or open network sockets. A lack of available file descriptors can impact operating system performance.
Tuning the file descriptor limit can be accomplished by configuring the hard limit (
Configuring file descriptor limits is platform-specific. Refer to your operating system documentation for details.
If your browser supports persistent connections, you can support them on the server by using the
KeepAlive directives in the Oracle HTTP Server. Persistent connections can improve performance by reducing the work load on the server. With persistent connections enabled, the server does not have to repeat the work to set up the connections with a client.
The default settings for the
KeepAlive directives are:
KeepAlive on MaxKeepAliveRequests 100 KeepAliveTimeOut 5
These settings allow enough requests per connection and time between requests to reap the benefits of the persistent connections, while minimizing the drawbacks. Consider the size and behavior of your own user population when you set these values. For example, if you have a large user population and the users make small infrequent requests, you may want to reduce the
keepAlive directive default settings, or even set
KeepAlive to off. If you have a small population of users that return to your site frequently, you may want to increase the settings.
KeepAlive option should be used judiciously along with
MaxClients directive. The
KeepAlive option would tie a worker thread to an established connection until it times out or the number of requests reaches the limit specified by
MaxKeepAliveRequests. This means that the connections or users in the
ListenBacklog queue would be starving for a worker until the worker is relinquished by the keep-alive user. The starvation for resources happens on the
KeepAlive user load with the user population consistently higher than the specified
Maxclients property is applicable only to UNIX platforms. On Windows, the same functionality is achieved through the
MaxClients may impact the performance in the following ways:
A high number of
MaxClients can overload the system resources and may lead to poor performance.
For a high user population with fewer requests, consider increasing the
MaxClients to support the
KeepAlive connections to avoid starvation. This can impact overall performance when the user concurrency increases. System performance is impacted by increased concurrency and can possibly cause the system to fail.
MaxClients must always be set to a value where the system would be stable or performing optimally (~85% CPU).
Typically for high user population with less frequent requests, consider turning off the
KeepAlive option or reduce it to a low value to avoid starvation.
KeepAlive connection may impact performance in the following ways:
Connection establishment for every request has a cost.
If the frequency of creating and closing connections is higher, then some system resources are used. The TCP connection has a
time_wait interval before it can close the socket connection and open file descriptors for every connection. The default
time_wait value is 60 seconds and each connection can take 60 seconds to close, even after it is relinquished by the server.
To avoid potential performance issues, values for any parameters should be set only after you consider the nature of the workload and the system capacity.
The logging options for Oracle HTTP Server include types of logging, log levels, and the performance implications for using logging.
Access logs are generally enabled to track who accessed what. The
access_log file, available in the
ohsname directory, contains an entry for each request that is processed. This file grows as time passes and can consume disk space. Depending on the nature of the workload, the
access_log has little impact on performance. If you notice that performance is becoming an issue, the file can be disabled if some other proxy or load balancer is used and gives the same information.
By default, the
HostNameLookups directive is set to Off. The server writes the IP addresses of incoming requests to the log files. When
HostNameLookups is set to On, the server queries the DNS system on the Internet to find the host name that is associated with the IP address of each request, then writes the host names to the log. Depending on the server load and the network connectivity to your DNS server, the performance impact of the DNS
HostNameLookup may be high. When possible, consider logging only IP addresses. On UNIX systems, you can resolve IP addresses to host names offline, with the
logresolve utility found in the
The server notes unusual activity in an error log. The
.log file, available in
ohsname directory, contains errors, warnings, system information, and notifications (depending on the
d.conf file contains the error log configuration for OHS. The
OraLogMode directive defines the logging mode. The default is
odl-text, which produces the Oracle diagnostic logging format in a text file. Alternatively, change it to
odl-xml to produce the Oracle diagnostic logging format in an XML file.
For Oracle diagnostic-style logging,
OraLogSeverity directive is used for setting the log level.
For Apache-style logging, the ErrorLog and LogLevel directives identify the log file and the level of detail of the messages recorded. The default debug level is
Excessive logging can have some performance cost and might also fill disk space. The log level control must be used based on need. For requests that use dynamic resources, like
mod_plsql, there is a performance cost associated.
Advanced tuning recommendations may or may not apply to your environment. Review the following recommendations to determine if the changes would improve your Oracle HTTP Server performance.
You can follow the topics to avoid or debug potential Oracle HTTP Server performance problems.
It is important to understand where your server is spending resources so you can focus your tuning efforts in the areas where the most stands to be gained. When you configure your system, it can be useful to know what percentage of the incoming requests are static and what percentage are dynamic.
Generally, you want to concentrate your tuning effort on dynamic pages because dynamic pages can be costly to generate. Also, by monitoring and tuning your application, you may find that much of the dynamically generated content, such as catalog data, can be cached, sparing significant resource usage.
Oracle HTTP Server, based on Apache 2.2, has a slight change in architecture, in the way the requests are handled, compared to the previous release.
The new architecture, Oracle HTTP Server invokes the service function of each module that is loaded (in the order of definition in the
d.conf file) until the request is serviced. This indicates that there is some cost associated with invoking the service function of each module, to know if the service is accepted or declined.
Because of this change in architecture, consider placing the most frequently hit modules above the others in the
For the static page requests, which are directly deployed to Oracle HTTP Server and served by the default handler, the request has to go through all the modules before the default handler is invoked. This process can impact performance of the request so consider enabling only the modules that are required by the deployed application. For example, if
mod_plsql is never used by the deployed application, disable it to maintain performance.
In addition, there are a few modules that register their hooks to do some work during the URL translation phase, which would add to the cost of request processing time. For example, mod_security, when enabled, has a cost of about 10% on CPU Cost per Transaction for the specweb benchmark. Again, enable only those modules that are required by your deployed applications to save CPU time.
A lack of available file descriptors can cause a wide variety of symptoms, which are not always easily traced back to the operating system's file descriptor limit. You can tune the file descriptor limit by configuring the operating system's hard limit for the user who starts the OHS. Once configured, the OHS adjusts the soft limit to match the operating system limit.
Configuring file descriptor limits is platform-specific. Refer to your operating system documentation for details. The following code example shows the command for Linux:
APACHECTL_ULIMIT=ulimit -S -n `ulimit -H -n`
Note that this limit must be reconfigured after you apply a patch set.
Tuning Oracle HTTP Server includes tuning the SSL and Port Tunneling.
Secure Sockets Layer (SSL) is a protocol developed by Netscape Communications Corporation that provides authentication and encrypted communication over the Internet. Conceptually, SSL resides between the application layer and the transport layer on the protocol stack. While SSL is technically an application-independent protocol, it has become a standard for providing security over and all major web browsers support SSL.
SSL can become a bottleneck in both the responsiveness and the scalability of a web-based application. Where SSL is required, the performance challenges of the protocol should be carefully considered. Session management, in particular session creation and initialization, is generally the most costly part of using the SSL protocol, in terms of performance.
When an SSL connection is initialized, a session-based handshake between client and server occurs that involves the negotiation of a cipher suite, the exchange of a private key for data encryption, and server and, optionally, client, authentication through digitally signed certificates.
After the SSL session state has been initiated between a client and a server, the server can avoid the session creation handshake in subsequent SSL requests by saving and reusing the session state. The Oracle HTTP Server caches a client's SSL session information by default. With session caching, only the first connection to the server incurs high latency.
SSLSessionCacheTimeout directive in the
ssl.conf file determines how long the server keeps a saved SSL session (the default is 300 seconds). The session state is discarded if it is not used after the specified time period, and any subsequent SSL request must establish a new SSL session and begin the handshake again. The
SSLSessionCache directive specifies the location for saved SSL session information. The default location is the following directory:
Multiple Oracle HTTP Server processes can use a saved session cache file.
Saving the SSL session state can significantly improve performance for applications using SSL. For example, in a simple test to connect and disconnect to an SSL-enabled server, the elapsed time for 5 connections was 11.4 seconds without SSL session caching. With SSL session caching enabled, the elapsed time for 5 round trips was 1.9 seconds.
The reuse of the saved SSL session state has some performance costs. When the SSL session state is stored to disk, reuse of the saved state normally requires locating and retrieving the relevant state from disk. This cost can be reduced when you use persistent connections. Oracle HTTP Server uses persistent connections by default, assuming they are supported on the client-side. In over SSL as implemented by Oracle HTTP Server, the SSL session state is kept in memory while the associated connection is persisted, a process which essentially eliminates the performance impacts that are associated with SSL session reuse (conceptually, the SSL connection is kept open along with the connection). For more information, see Reducing Process Availability with Persistent Connections.
In most applications using SSL, the data encryption cost is small compared with the cost of SSL session management. Encryption costs can be significant where the volume of encrypted data is large, and in such cases the data encryption algorithm and key size chosen for an SSL session can be significant. In general there is a trade-off between security level and performance.
Oracle HTTP Server negotiates a cipher suite with a client based on the SSLCipherSuite attribute specified in the
ssl.conf file. OHS 11g uses the 128 bit Encryption algorithm by default and no longer supports lower encryption.
The previous release [10.1.3x] used 64 bit encryption for Windows. For UNIX, the 10.x releases used the 128 bit encryption by default.
The following recommendations can assist you to determine performance requirements when you work with Oracle HTTP Server and SSL.
The SSL handshake is a resource-intensive process in terms of both CPU usage and response time. Thus, use SSL only where needed. Determine the parts of the application that require the security, and the level of security required, and protect only those parts at the requisite security level. Attempt to minimize the need for the SSL handshake by using SSL sparingly, and by reusing the session state as much as possible. For example, if a page contains a small amount of sensitive data and several non-sensitive graphic images, use SSL to transfer the sensitive data only. If the application requires server authentication only, do not use client authentication. If additional hardware is required, the performance goals of an application cannot be met by this method.
Design the application to use SSL efficiently. Group secure operations to take advantage of SSL session reuse and SSL connection reuse.
Use persistent connections, if possible, to minimize the cost of SSL session reuse.
Tune the session cache timeout value (the
SSLSessionCacheTimeout directive in the
ssl.conf) file. A trade-off exists between the cost of maintaining an SSL session cache and the cost of establishing a new SSL session. As a rule, any secured business process, or conceptual grouping of SSL exchanges, must be completed without incurring session creation more than once. The default value for the
SSLSessionCacheTimeout attribute is 300 seconds. Test the application usability to help tune this setting.
If large volumes of data are being protected through SSL, pay close attention to the cipher suite being used. The
SSLCipherSuite directive specified in the
ssl.conf file controls the cipher suite. If lower levels of security are acceptable, use a less-secure protocol by using a smaller key size (improves performance significantly). Finally, test the application by using each available cipher suite for the specified security level to find the optimal suite.
If SSL remains a bottleneck to the performance and scalability of your application, after taking the preceding considerations into account, consider deploying multiple Oracle HTTP Server instances over a hardware cluster or consider the use of SSL accelerator cards.
When OracleAS Port Tunneling is configured, every request processed passes through the OracleAS Port Tunneling infrastructure. Thus, using OracleAS Port Tunneling can have an impact on the overall Oracle HTTP Server request handling performance and scalability.
Except for the number of OracleAS Port Tunneling processes to run, the performance of OracleAS Port Tunneling is self-tuning. The only performance control available is to start more OracleAS Port Tunneling processes; it increases the number of available connections and the scalability of the system.
The number of OracleAS Port Tunneling processes is based on the degree of availability required, and the number of anticipated connections. This number cannot be automatically determined because for each additional process a new port must be opened through the firewall between the DMZ and the intranet. Ensure to check the number of open ports. Start processes equivalent to the number of open ports.
To measure the OracleAS Port Tunneling performance, determine the request time for servlet requests that pass through the OracleAS Port Tunneling infrastructure. The response time running with OracleAS Port Tunneling must be compared with a system without OracleAS Port Tunneling to determine whether your performance requirements can be met by using OracleAS Port Tunneling.