|
Oracle® Application Server Best Practices Guide
10g Release 2 (10.1.2) B28654-01 |
|
 Previous |
 Next |
|
Oracle® Application Server Best Practices Guide
10g Release 2 (10.1.2) B28654-01 |
|
|
Previous |
Next |
This chapter describes best practices for Oracle HTTP Server. It includes the following topics:
Section 3.2, "Tune TCP/IP Parameters to Improve Oracle HTTP Server Performance"
Section 3.3, "Tune KeepAlive Directives to Improve Connection Performance"
Section 3.4, "Tune MaxClients Directive to Improve Request Performance"
Section 3.5, "Avoid Any DNS Lookup to Prevent Performance Degradation"
Section 3.7, "Use FollowSymLinks and Not SymLinkIfOwnerMatch to Configure Symbolic Links"
Section 3.8, "Set AllowOverride to None to Prevent Unnecessary Directive Checking"
Section 3.9, "Use mod_rewrite to Hide URL Changes For End-Users"
Section 3.10, "Use mod_oc4j Sticky Routing Instead of Configuring the External Router"
|
See Also: Oracle HTTP Server Administrator's Guide for information about directives mentioned in this chapter |
Some Web sites have visitors connecting from slow modems. Sometimes, it takes longer for data to transfer over these slow connections than for data to be computed by the application server. Thus, an Oracle HTTP Server process can be blocked doing the transfer, and CPU processing power is not available for another request to perform computation.
If this is perceived to be a problem in your environment, you should front-end Oracle HTTP Server with either:
OracleAS Web Cache, which uses a threaded architecture
Oracle HTTP Server in reverse proxy mode, which can spawn more lightweight processes to handle the transfer
In both cases, the backend Oracle HTTP Server is reserved to do the computation work. This separation of data computation and data transfer responsibilities buffers a site from latency due to slow modem connections.
Setting TCP/IP parameters can improve Oracle HTTP Server performance.
The KeepAlive, KeepAliveTimeout, and MaxKeepAliveRequests directives are used to control persistent connections. Persistent connections are supported in HTTP 1.1 to allow a client to send multiple sequential requests through the same connection.
Setting KeepAlive to On allows Apache to keep the connection open for that client when the client requests it. This setting can improve performance, because the connection has to be set up only once. The trade-off is that the httpd server process cannot be used to service other requests until either the client disconnects, the connection times out (controlled by the KeepAliveTimeout directive), or the MaxKeepAliveRequests value has been reached.
You can change these KeepAlive parameters to meet your specific application needs, but you should not set the MaxKeepAliveRequests to 0. A value of 0 in this directive means there is no limit. The connection will be closed only when the client disconnects or times out.
You may also consider setting KeepAlive to Off if your application has a large population of clients who make infrequent requests.
The MaxClients directive controls the maximum number of clients who can connect to the server simultaneously. This value is set to 1024 by default. If your requests have a short response time, you may be able to improve performance by setting MaxClients to a lower value. When this value is reached, no additional processes will be created, causing other requests to fail. In general, increasing the value of MaxClients does not improve performance when the system is saturated.
If you are using persistent connections, you may require more concurrent httpd server processes, and you may need to set the MaxClients directive to a higher value. Tune this directive according to the KeepAlive parameters.
Any DNS lookup can affect Oracle HTTP Server performance. The HostNameLookups directive in Apache informs Apache whether it should log information based on the IP address (if the directive is set to Off), or look up the host name associated with the IP address of each request in the DNS system on the Internet (if the directive is set to On).
Performance degraded by a minimum of about three percent in Oracle 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 much higher. Unless you really need to have host names in your logs in real time, it is best to log IP addresses and resolve IP addresses to host names off-line.
It is generally useful to have access logs for your Web server, both for load tracking and for the detection of security violations. If you find that you do not need this data, turn it off and reduce the overhead of writing the data to this log file.
The FollowSymLinks and SymLinksIfOwnerMatch options are used by Apache to determine if it should follow symbolic links. If the SymLinksIfOwnerMatch option is used, Apache will check the symbolic link and make sure the ownership is the same as that of the server.
If the AllowOverride directive is not set to None, Apache will check for directives in the htaccess files at each directory level until the requested resource is found for each URL request.
The mod_rewrite module can transparently map the URLs visible to the end users to a different URL. You can accomplish this result without a round-trip through the Web browser or any code change.
This feature makes it very easy to re-organize directories on the server side or perform other changes; you can do this even after an application has been developed and deployed. There is a slight performance impact, however, as this configuration change for mod_rewrite is preferred.
The mod_oc4j module is able to do sticky routing independent of any external router or OracleAS Web Cache. Thus, for J2EE requests, do not set the external router to perform sticky routing. If there are other non-J2EE requests that require sticky routing, then perform the necessary sticky routing setup on the external load balancer.
