Oracle9i Application Server Oracle HTTP Server powered by Apache Performance Guide Release 1.0.2.2 for Windows NT Part Number A86676-02 |
|
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:
There are a number of things to keep in mind when running the Oracle HTTP Server.
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.
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.
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.
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.
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.
This section discusses the performance implications of using access logging and the HostNameLookups
directive.
For static page requests, access logging of the default fields results in a 2-7% performance cost.
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.
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.
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.)
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.
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.
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).
|
Copyright © 2001 Oracle Corporation. All Rights Reserved. |
|