| Oracle® Application Server Performance Guide 10g Release 3 (10.1.3.1.0) Part Number B28942-01 |
|
|
View PDF |
| Oracle® Application Server Performance Guide 10g Release 3 (10.1.3.1.0) Part Number B28942-01 |
|
|
View PDF |
This chapter discusses the techniques for optimizing Oracle HTTP Server performance in Oracle Application Server.
This chapter contains:
Oracle HTTP Server uses directives in httpd.conf to configure the application server. This configuration file specifies the maximum number of HTTP requests that can be processed simultaneously, logging details, and certain limits and timeouts.
Table 6-1 lists directives that may be significant for performance.
Table 6-1 Oracle HTTP Server Configuration Properties
| Directive | Description |
|---|---|
|
Specifies the maximum length of the queue of pending connections. Generally no tuning is needed or desired. Note that 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 |
|
|
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 The maximum allowed value for Default Value: 150 |
|
|
The number of requests each child process is allowed to process before the child dies. The child will exit so as to avoid problems after prolonged use when Apache (and maybe the libraries it uses) leak memory or other resources. On most systems, this isn't really needed, but some UNIX systems have notable leaks in the libraries. For these platforms, set This value does not include Note: On Windows systems |
|
|
Server-pool size regulation. Rather than making you guess how many server processes you need, Oracle HTTP Server dynamically adapts to the load it sees, that is, it tries to maintain enough server processes to handle the current load, plus a few spare servers to handle transient load spikes (for example, multiple simultaneous requests from a single Netscape browser). It does this by periodically checking how many servers are waiting for a request. If there are fewer than The default values are probably ok for most sites. Default Values:
|
|
|
Number of servers to start initially. If you expect a sudden load after restart, set this value based on the number child servers required. Default Value: 5 |
|
|
The number of seconds before incoming receives and outgoing sends time out. Default Value: 300 |
|
|
Whether or not to allow persistent connections (more than one request per connection). Set to 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, you might want to increase this value. Default Value: 100 |
|
|
Number of seconds to wait for the next request from the same client on the same connection. Default Value: 15 seconds |
The default settings for the KeepAlive directives are:
KeepAlive on MaxKeepAliveRequests 100 KeepAliveTimeOut 15
These settings allow enough requests per connection and time between requests to reap the benefits of the persistent connections, while minimizing the drawbacks. You should consider the size and behavior of your own user population in setting these values on your system. 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.
This section discusses types of logging, log levels, and the performance implications for using logging.
For static page requests, access logging of the default fields results in a 2-3% 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 3% (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.
On UNIX systems, you can resolve IP addresses to host names off-line, with the logresolve utility found in the $ORACLE_HOME/Apache/Apache/bin/ directory.
The server notes unusual activity in an error log. The ErrorLog and LogLevel directives identify the log file and the level of detail of the messages recorded. The default level is warn. There was no difference in static page performance on a loaded system between the warn, info, and debug levels.
For requests that use dynamic resources, for example requests that use mod_osso, mod_plsql, or mod_oc4j, there is a performance cost associated with setting higher debugging levels, such as the debug level.
This section covers the following topics:
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 HTTP, 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.
This section covers the following SSL Performance related information:
|
See Also: Oracle Application Server Security Guide |
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 Secure Sockets Layer (SSL) session information by default. With session caching, only the first connection to the server incurs high latency.
The SSLSessionCacheTimeout directive in httpd.conf determines how long the server keeps a saved SSL session (the default is 300 seconds). 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 on UNIX is the $ORACLE_HOME/Apache/Apache/logs/ directory or on Windows systems, %ORACLE_HOME%\Apache\Apache\logs\. Multiple Oracle HTTP Server processes can use a saved session cache file.
Saving 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 saved SSL session state has some performance costs. When 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 using HTTP persistent connections. Oracle HTTP Server uses persistent HTTP connections by default, assuming they are supported on the client side. In HTTP over SSL as implemented by Oracle HTTP Server, SSL session state is kept in memory while the associated HTTP connection is persisted, a process which essentially eliminates the overhead of SSL session reuse (conceptually, the SSL connection is kept open along with the HTTP connection).
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. For example, on a modern processor, RSA estimates its RC4 cipher to take in the vicinity of 8-16 machine operations per output byte. Standard DES encryption will incur roughly 8 times the overhead of RC4, and triple DES will take about 25 times the overhead of DES. However, when using triple DES, the encryption costs will not be noticeable in most applications. Oracle HTTP Server supports these three cipher suites, and other cipher suites as well.
Oracle HTTP Server negotiates a cipher suite with a client based on the SSLCipherSuite attribute specified in httpd.conf.
The following recommendations can assist you with determining performance requirements when working with Oracle HTTP Server and SSL.
The SSL handshake is an inherently expensive 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 session state as much as possible. For example, if a page contains a small amount of sensitive data and a number of non-sensitive graphic images, use SSL to transfer the sensitive data only, use normal HTTP to transfer the images. If the application requires server authentication only, do not use client authentication. If the performance goals of an application cannot be met by this method alone, additional hardware may be required.
Design the application to use SSL efficiently. Group secure operations together to take advantage of SSL session reuse and SSL connection reuse.
Use persistent connections, if possible, to minimize cost of SSL session reuse.
Tune the session cache timeout value (the SSLSessionCacheTimeout attribute in httpd.conf). 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, should be completed without incurring session creation more than once. The default value for the SSLSessionCacheTimeout attribute is 300 seconds. It is a good idea to test an application's 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 httpd.conf controls the cipher suite. If lower levels of security are acceptable, use a less-secure protocol using a smaller key size (this may improve performance significantly). Finally, test the application using each available cipher suite for the desired security level to find the most performant suite.
Having taken the preceding considerations into account, if SSL remains a bottleneck to the performance and scalability of your application, 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.
With the exception of 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, this increases the number of available connections and hence 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. You cannot start more processes than you have open ports, and you do not want less processes than open ports, since in this case ports would not have any process bound to them.
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 of an Oracle Application Server instance running with OracleAS Port Tunneling should be compared with a system without OracleAS Port Tunneling to determine whether your performance requirements can be met using OracleAS Port Tunneling.
|
See Also: Oracle HTTP Server Administrator's Guide for information on configuring OracleAS Port Tunneling |
The following tips can enable you to avoid or debug potential Oracle HTTP Server (OHS) 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. In configuring 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.
In some cases, you may notice a high discrepancy between the average time to process a request in Oracle Containers for J2EE (OC4J) and the average response time experienced by the user. If the time is not being spent actually doing the work in OC4J, then it is probably being spent in transport.
If you notice a large discrepancy between the request processing time in OC4J and the average response time, consider tuning the Oracle HTTP Server directives shown in the section, "Configuring Oracle HTTP Server Directives".
You can get unrepresentative results when data outliers appear. This can sometimes occur at start-up. To simulate a simple example, assume that you ran a PL/SQL "Hello, World" application for about 30 seconds. Examining the results, you can see that the work was all done in mod_plsql.c:
/ohs_server/ohs_module/mod_plsql.c handle.maxTime: 859330 handle.minTime: 17099 handle.avg: 19531 handle.active: 0 handle.time: 24023499 handle.completed: 1230
Note that handle.maxTime is much higher than handle.avg for this module. This is probably because when the first request is received, a database connection must be opened. Later requests can make use of the established connection. In this case, to obtain a better estimate of the average service time for a PL/SQL module, that does not include the database connection open time which causes the handle.maxTime to be very large, recalculate the average as in the following:
(time - maxTime)/(completed -1)
For example, in this case this would be:
(24023499 - 859330)/(1230 -1) = 18847.98
