4
Optimizing HTTP Server Performance

This chapter provides information on improving the Oracle HTTP Server's performance, including tuning network parameters, the effects of changing the ThreadsPerChild parameter, and the performance impacts of logging.

This chapter contains the following sections:

• Network Tuning

• Configuring the ThreadsPerChild Parameter

• Enabling SSL Session Caching

• Understanding Performance Implications of Logging

• Benefits of the HTTP/1.1 Protocol

Network Tuning

There are a number of things to keep in mind when running the Oracle HTTP Server.

1. Be certain that you have sufficient memory. System memory usage can be monitored by watching the display under the performance tab in the Task Manager.

2. Be certain that only the TPC/IP protocol stack is running. If another protocol is running, it will be listed in the list under the Protocols tab of the Control Panel/Network dialog box. To remove it, select it with the mouse, and click Remove. If you close the Network dialog box, you will be prompted to restart the system. It will be easier, however, to first continue with step 3.

3. Select the "Maximize Throughput for File Sharing" network optimization scheme. Under the Services tab of the Control Panel/Network dialog box, you can examine the Server properties. Select "Server" in the list, and click Properties. This will bring up a dialog box that allows you to choose the criteria for which TCP will be optimized. The default setting is "Maximize Throughput for File Sharing". We recommend you use the setting. If this has been otherwise set, reset it to the default and click "OK". Then close the Control Panel/Network dialog box. If you changed this setting, you will be prompted to restart the system, and if you have made any changes in Step 1 above, or in this box, you should do so.

   Note: The performance is much better when either "Maximize Throughput for File Sharing" or "Maximize Throughput for Network Applications" is chosen, than when either of the other options is chosen. We have also see that the response time under load is cut in half when we maximize for file sharing rather than for network applications.

In addition to the above, one can adjust individual TCP/IP parameters in the registry. We do not recommend that you do so as it is complex. Unless you have plenty of time to test the impact for your environment, we recommend you limit your TCP/IP tuning to the steps above.

Configuring the ThreadsPerChild Parameter

The ThreadsPerChild parameter in the httpd.conf file specifies the number of requests that can be handled concurrently by the HTTP server. Requests in excess of the ThreadsPerChild parameter value wait in the TCP/IP queue. Allowing the requests to wait in the TCP/IP queue often results in the best response time and throughput.

Configuring ThreadsPerChild for Servlet Requests

If the HTTP server will handle servlets exclusively, then the ThreadsPerChild parameter value must be much smaller than the number of concurrent requests that the JServ process can service. If a JServ process is handling all the requests it can (as specified by security.maxConnections in the jserv.properties file), then a delay occurs when the HTTP server tries to establish a connection to it.

To prevent the corresponding increase in latency, set ThreadsPerChild to half the number of requests that all of the JServ processes can handle. For example, suppose you have four JServ processes, and each has a security.maxConnections value of 10. The total number of requests that the JServ processes can handle is 40, so set ThreadsPerChild to 20.

Configuring ThreadsPerChild for Static Page Requests

The more concurrent threads you make available to handle requests, the more requests your server can process. But be aware that with too many threads, under high load, requests will be handled more slowly and the server will consume more system resources.

In in-house tests of static page requests, a setting of 20 ThreadsPerChild per CPU produced good response time and throughput results. For example, if you have four CPUs, set ThreadsPerChild to 80. If, with this setting, CPU utilization does not exceed 85%, you can increase ThreadsPerChild, but ensure that the available threads are in use. You can determine this using the mod_status utility.

See Also: "Using the mod_status Utility to Monitor the Web Server" for information.

Enabling SSL Session Caching

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. For example, in a simple test to connect and disconnect to an SSL-enabled server, the elapsed time for 5 connections was 5.54 seconds without SSL session caching. With SSL session caching enabled, the elapsed time for 5 round trips was 1.18 seconds.

The SSLSessionCacheTimeout directive in httpd.conf determines how long the server keeps a session alive (the default is 300 seconds). The session information is kept in a file. You can specify where to keep the session information using the SSLSessionCache directive; the default location is the $ORACLE_HOME/Apache/Apache/logs/ directory. The file can be used by multiple Oracle HTTP Server processes.

The duration of an SSL session is unrelated to the use of HTTP persistent connections.

Understanding Performance Implications of Logging

This section discusses the performance implications of using access logging and the HostNameLookups directive.

Access Logging

For static page requests, access logging of the default fields results in a 2-7% performance cost.

HostNameLookups

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 associated with the IP address of each request, then writes the host names to the log.

Performance degraded by about 10-12% (best case) in Oracle in-house tests with HostNameLookups set to on. Depending on the server load and the network connectivity to your DNS server, the performance cost of the DNS lookup could be high. Unless you really need to have host names in your logs in real time, it is best to log IP addresses.

Benefits of the HTTP/1.1 Protocol

The Oracle HTTP server can use HTTP/1.1. Netscape Navigator release 4.0 still uses HTTP/1.0, with some 1.1 features, such as persistent connections. Internet Explorer uses HTTP/1.1. The performance benefit of persistent connections comes from reducing the overhead of establishing and tearing down a connection for each request. A persistent connection accepts multiple requests from a user.

For a small static page request, the connection latency can equal or exceed the response latency (the time to fulfill the request after the connection is established), so using persistent connections can result in major performance gains.

Supporting Persistent Connections

If your users' browsers support persistent connections (the default behavior of HTTP/1.1), you can support them on the server using the KeepAlive directives in the Oracle HTTP Server. (Some browsers that do not support all HTTP/1.1 features do support persistent connections; for example, recent versions of Netscape.)

How Persistent Connections Improve Response Times

Persistent connections can improve total response time for a web interaction that involves multiple HTTP requests, because the delay of setting up a connection only happens once.

Consider the total time required, without persistent connections, for a client to retrieve a web page with three images from the server.

Activity	Seconds
Establish connection	1
Produce and send the text portion of the page	5
Establish connection	1
Transfer first image file	2
Establish connection	1
Transfer second image file	2
Establish connection	1
Transfer third image file	2
Total	15

With persistent connections, the response time for the same request is reduced:

Activity	Seconds
Establish connection	1
Produce and send the text portion of the page	5
Transfer first image file	2
Transfer second image file	2
Transfer third image file	2
Total	12

This is a 20% reduction in service time.

How Persistent Connections Reduce Server Workload

Another benefit of persistent connections is reduction of the work load on the server. Because the server need not repeat the work to set up the connection with a client, it is free to perform other work.

In-house tests using an OracleJSP application (lotto.jsp, one of the samples that ships with Oracle9i Application Server) and persistent connections showed an improvement of about 20%, with a single user making 5 requests per connection. With an increased number of users (10-100), the performance improvement was less dramatic, but still significant (6% or better).