6 Tuning Oracle HTTP Server

You can tune Oracle HTTP Server (OHS) to optimize its performance as the web server component for Oracle Fusion Middleware.

Note:

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.

About Oracle HTTP Server

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 http://www.apache.org/.

Monitoring Oracle HTTP Server Performance

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.

Note:

Fusion Middleware Control provides real-time data. See Managing and Monitoring Server Processes in 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.

See Viewing Metrics with WLST (Oracle WebLogic Server).

Basic Tuning Considerations

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.

Tuning Oracle HTTP Server Directives

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 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 DOMAIN_HOME/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 ohs.plugins.nodemanager.properties file found in the same directory.

Note:

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 https://docs.oracle.com/en/middleware/webcenter/index.html.

Table 6-1 Oracle HTTP Server Configuration Properties

Directive Description

ListenBackLog

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

MaxRequestWorkers

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 ThreadLimit directive.

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 ListenBackLog directive (after the queue of pending connections is full, new requests generate connection errors until a thread becomes available).

You can configure the MaxRequestWorkers directive in the httpd.conf file up to a maximum of 8000 (8K) (the default value is 150). If your system is not resource-saturated and you have a user population of more than 150 concurrent HTTP/Thread connections, you can improve your performance by increasing MaxRequestWorkers to increase server concurrency. Increase MaxRequestWorkers until your system becomes fully utilized (85% is a good threshold).

Conversely, when system resources are saturated, increasing MaxClients does not improve performance. In this case, the MaxRequestWorkers value could be reduced as a throttle on the number of concurrent requests on the server.

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 MaxRequestWorkers to act as a throttle for system concurrency, you must consider that persistent idle httpd connections also consume httpd/thread processes. Specifically, the number of connections includes the currently active persistent and non-persistent connections and the idle persistent connections. A persistent KeepAlive http connection consumes an httpd child process, or thread, during the connection, even if no requests are currently being processed for the connection.

If you have sufficient capacity, KeepAlive must be enabled; using persistent connections improves performance and prevents wasting CPU resources reestablishing connections. Normally, you should not change KeepAlive parameters.

The maximum allowed value for MaxRequestWorkers is 8192 (8K).

Default Value: 150

StartServers

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):

  • MaxRequestWorkers

  • MaxSpareThreads and MinSpareThreads

  • ServerLimit and StartServers

On the Windows platform (mpm_winnt), as well as UNIX platforms, the following parameters are important to tune:

  • ThreadLimit

  • ThreadsPerChild

Each child process has a set of child threads that are defined for them and that can actually handle the requests. Use ThreadsPerChild with this directive.

The values of ThreadLimit, ServerLimit, and MaxRequestWorkers can indirectly affect this value. Read the notes for these directives and use them with this directive.

Default Value: 2

ServerLimit

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 StartServers value if that value is greater than the ServerLimit value. It is used to control the maximum number of server processes that can be created.

Default Value: 16

ThreadLimit

Specifies the upper limit on the number of threads that can be created under a server (child) process. This value overrides the ThreadsPerChild value if that value is greater than the ThreadLimit value. It is used to control the maximum number of threads created per process to avoid conflicts or issues.

Default Values:

  • Windows Multi-Processing Module (mpm_winnt): 1920

  • All others: 64

ThreadsPerChild

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: 150 when mpm_winnt is used and 25 when worker MPM is used.

The ThreadsPerChild directive works with other directives, as follows:

At startup, Oracle HTTP Server creates a parent process, which creates several child (server) processes as defined by the StartServers directive. Each server process creates several threads (server or worker), as specified in ThreadsPerChild, and a listener thread, which listens for requests and transfers the control to the worker or server threads.

After startup, based on load conditions, the number of server processes and server threads (children of server processes) in the system are controlled by MinSpareThreads (minimum number of idle threads in the system) and MaxSpareThreads (maximum number of idle threads in the system). If the number of idle threads in the system is more than MaxSpareThreads, Oracle HTTP Server terminates the threads and processes if there are no child threads for a process. If the number of idle threads is fewer than MinSpareThreads, it creates new threads and processes if the ThreadsPerChild value has already been reached in the running processes.

The ServerLimit, ThreadLimit, and MaxRequestWorkers directives affect the other directives as follows:

  • ServerLimit: Defines the upper limit on the number of servers that can be created. This affects MaxRequestWorkers and StartServers.

  • ThreadLimit: Defines the upper limit on ThreadsPerChild. If ThreadsPerChild is greater than ThreadLimit, then it is automatically trimmed to the latter value.

  • MaxRequestWorkers: Defines the upper limit on the number of server threads that can process requests simultaneously. This must be equal to the number of simultaneous connections that can be made. This value must be a multiple of ThreadsPerChild. If MaxRequestWorkers is greater than ServerLimit multiplied by ThreadsPerChild, it is automatically trimmed to the latter value.

MaxRequestsPerChild

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 MaxRequestsPerChild to 10000; a setting of 0 means unlimited requests.

This value does not include KeepAlive requests after the initial request per connection. For example, if a child process handles an initial request and 10 subsequent keep alive requests, it would only count as 1 request toward this limit.

Default Value: 0

Note: Windows systems MaxRequestsPerChild must always be set to 0 (unlimited) since there is only one server process.

MaxSpareThreads

MinSpareThreads

These directives map to the Maximum Idle Threads and Minimum Idle Threads fields on the Performance Directives screen.

These parameters are not available in mod_winnt (Windows platform).

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 MinSpareThreads, it creates a new spare. If there is more than MaxSpareThreads, some of the spares are removed.

Default Values:

MaxSpareThreads: 75

MinSpareThreads: 25

Timeout

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

KeepAlive

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

MaxKeepAliveRequests

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

KeepAliveTimeout

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

limit

ulimit

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 (ulimit) in a shell script, which starts the OHS. Once the hard limit has been set, the OHS then adjusts the soft limit (limit) to match.

Configuring file descriptor limits is platform-specific. Refer to your operating system documentation for details.

Reducing Process Availability with Persistent Connections

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.

The 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.

Note:

The Maxclients property is applicable only to UNIX platforms. On Windows, the same functionality is achieved through the ThreadLimit and ThreadsPerChild parameters.

Increasing 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.

Disabling the 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.

WARNING:

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.

Logging Options for Oracle HTTP Server

The logging options for Oracle HTTP Server include types of logging, log levels, and the performance implications for using logging.

Access Logging

Access logs are generally enabled to track who accessed what. The access_log file, available in the ORACLE_INSTANCE/diagnostics/logs/OHS/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.

Configuring the HostNameLookups Directive

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 /Apache/Apache/bin/ directory.

Error logging

The server notes unusual activity in an error log. The ohsname.log file, available in ORACLE_INSTANCE/diagnostics/logs/OHS/ohsname directory, contains errors, warnings, system information, and notifications (depending on the log-level setting).

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 Warn.

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_osso or mod_plsql, there is a performance cost associated.

Advanced Tuning Considerations

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.

Tuning Oracle HTTP Server

You can follow the topics to avoid or debug potential Oracle HTTP Server performance problems.

Analyzing Static Versus Dynamic Requests

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.

Limiting the Number of Enabled Modules

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 d.conf file.

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.

Tuning the File Descriptor Limit

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:

Note that this limit must be reconfigured after you apply a patch set.

Tuning Oracle HTTP Server Security

Tuning Oracle HTTP Server includes tuning the SSL and Port Tunneling.

Tuning Oracle HTTP Server Secure Sockets Layer (SSL)

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.

Caching SSL on Oracle HTTP Server

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.

The 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:

$ORACLE_INSTANCE/diagnostics/logs/$COMPONENT_ TYPE/$COMPONENT_NAME

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.

Using SSL Application Level Data Encryption

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.

Note:

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.

Tuning SSL Performance

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.

Tuning Oracle HTTP Server Port Tunneling

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.