Skip Headers
Oracle® Fusion Middleware Administrator's Guide for Oracle HTTP Server
11g Release 1 (11.1.1)

Part Number E10144-05
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

5 Managing and Monitoring Server Processes

This chapter describes how to manage and monitor Oracle HTTP Server. It discusses the procedures and tools to manage Oracle HTTP Server in your environment.

Note:

The information in this document is applicable when Oracle HTTP Server is installed with Oracle WebLogic Server and Oracle Fusion Middleware Control. It is assumed that readers are familiar with the key concepts of Oracle Fusion Middleware, as described in the Oracle Fusion Middleware Concepts Guide and the Oracle Fusion Middleware Administrator's Guide.

For information about installing Oracle HTTP Server in standalone mode, see “Installing Oracle Web Tier Without Oracle WebLogic Server” in the Oracle Fusion Middleware Installation Guide for Oracle Web Tier."

This chapter includes the following sections:

5.1 Oracle HTTP Server Processing Model

The following sections explain the processing model for Oracle HTTP Server.

5.1.1 Request Process Model

After Oracle HTTP Server is started, it is ready to listen for and respond to HTTP(S) requests. The request processing model on Microsoft Windows systems differs from that on UNIX systems.

  • On Microsoft Windows, there is a single parent process and a single child process. The child process creates threads that are responsible for handling client requests. The number of created threads is static and can be configured for performance.

  • On UNIX, there is a single parent process that manages multiple child processes. The child processes are responsible for handling requests. The parent process brings up additional child processes as necessary, based on configuration. Although the server has the ability to dynamically bring up additional child processes, it is best to configure the server to start enough child processes initially so that requests can be handled without having to spawn more child processes.

5.1.2 Single Unit Process Model

Oracle HTTP Server provides functionality that allows it to terminate as a single unit if the parent process fails. The parent process is responsible for starting and stopping all the child processes for an Oracle HTTP Server instance. The failure of the parent process without first shutting down the child processes leaves Oracle HTTP Server in an inconsistent state that can only be fixed by manually shutting down all the orphaned child processes. Until all the child processes are closed, a new Oracle HTTP Server instance cannot be started because the orphaned child processes still occupy the ports the new Oracle HTTP Server instance needs to access.

To prevent this from occurring, the DMS instrumentation layer in child processes on UNIX and monitor functionality within WinNT MPM on Windows monitor the parent process. If they detect that the parent process has failed, then all of the remaining child processes are shut down.

When this functionality is combined with OPMN, it means that Oracle HTTP Server is easily restarted in case of a parent process failure. The DMS instrumentation layer on UNIX and a monitor within WinNT MPM on Windows ensures that all of the Oracle HTTP Server child processes are shut down, leaving the ports open for a new Oracle HTTP Server instance. OPMN ensures that a new instance is started once the failure of the original instance is detected.

5.2 Monitoring Oracle HTTP Server Performance

Oracle Fusion Middleware automatically and continuously measures run-time 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 that Fusion Middleware Control provides real-time data. If you are interested in viewing historical data, consider using Grid Control.

5.2.1 Viewing Oracle HTTP Server Performance Metrics

You can view metrics from the Oracle HTTP Server home menu of Fusion Middleware Control:

  1. Select the Oracle HTTP Server that you want to monitor.

    The Oracle HTTP Server home page is displayed.

  2. From the Oracle HTTP Server menu, choose Monitoring, and then select Performance Summary.

    The Performance Summary page is displayed. It shows performance metrics, as well as information about response time and request processing time for the Oracle HTTP Server instance.

  3. To see additional metrics, click Show Metric Palette and expand the metric categories.

    Tip:

    Oracle HTTP Server port usage information is also available from the Oracle HTTP Server home menu.

    The following figure shows the Oracle HTTP Server Performance Summary page with the Metric Palette displayed:

    MAS home page showing status
    Description of the illustration perf_summary.gif

  4. Select additional metrics to add them to the Performance Summary.

5.2.2 Understanding Oracle HTTP Server Performance Metrics

This section lists some of the most commonly-used metrics that can help you analyze Oracle HTTP Server performance.

OHS Server Metrics

The OHS Server Metrics folder contains performance metric options for Oracle HTTP Server. The following table describes the metrics in the OHS Server Metrics folder:

Element Description
CPU Usage CPU usage and idle times
Memory Usage Memory usage and free memory, in MB
Processes Busy and idle process metrics
Request Throughput Request throughput, as measured by requests per second
Request Processing Time Request processing time, in seconds
Response Data Throughput Response data throughput, in KB per second
Response Data Processed Response data processed, in KB per second
Active HTTP Connections Number of active HTTP connections
Connection Duration Length of time for connections
HTTP Errors Number of HTTP 4xx and 5xx errors

OHS Virtual Host Metrics

The OHS Virtual Host Metrics folder contains performance metric options for virtual hosts, also known as access points. The following table describes the metrics in the OHS Virtual Host Metrics folder:

Element Description
Request Throughput for a Virtual Host Number of requests per second for each virtual host
Request Processing Time for a Virtual Host Time to process each request for each virtual host
Response Data Throughput for a Virtual Host Amount of data being sent for each virtual host
Response Data Processed for a Virtual Host Amount of data being processed for each virtual host

OHS Module Metrics

The OHS Module Metrics folder contains performance metric option for modules. The following table describes the metrics in the OHS Module Metrics folder.

Element Description
Request Handling Throughput Request handling throughput for a module, in requests per second
Request Handling Time Request handling time for a module, in seconds
Module Metrics Modules including active requests, throughput, and time for each module

5.3 Configuring Oracle HTTP Server Performance Directives

Oracle HTTP Server uses directives in httpd.conf. This configuration file specifies the maximum number of HTTP requests that can be processed simultaneously, logging details, and certain limits and timeouts. Oracle HTTP Server supports and ships with the following three Multi-Processing Modules (MPMs) which are responsible for binding to network ports on the machine, accepting requests, and dispatching children to handle the requests:

The discussion and recommendations in this section are based on the use of Worker or WinNT MPM, which uses threads. The thread-related directives listed below are not applicable if you are using the Prefork MPM.

The Performance Directives page allows you to tune performance-related directives for Oracle HTTP Server, as illustrated in the following figure:

MAS home page showing status
Description of the illustration directive2.gif

Performance directives management consists of three areas: request configuration, connection configuration, and process configuration. You can set these configurations using the Performance Directive page of Fusion Middleware Control and by following the instructions in the following sections:

5.3.1 Using Fusion Middleware Control to Set the Request Configuration

To specify the Oracle HTTP Server request configuration using Fusion Middleware Control, do the following:

  1. Select Administration from the Oracle HTTP Server menu.

  2. Select Performance Directives from the Administration menu. The Performance Directives page appears.

  3. Enter the maximum number of requests in the Maximum Requests field (MaxClients directive). This setting limits the number of requests that can be dealt with at one time. The default and recommended value is 150. This is applicable for all Linux/Unix platforms.

  4. Set the maximum requests per child process in the Maximum Request per Child Process field (MaxRequestPerChild directive). You can choose to have no limit, or a maximum number. If you choose to have a limit, enter the maximum number in the field.

  5. Enter the request timeout value in the Request Timeout (seconds) field (Timeout directive). This value sets the maximum time, in seconds, Oracle HTTP Server waits to receive a GET request, the amount of time between receipt of TCP packets on a POST or PUT request, and the amount of time between ACKs on transmissions of TCP packets in responses.

  6. Review the settings. If the settings are correct, click Apply to apply the changes. If the settings are incorrect, or you decide to not apply the changes, click Revert to return to the original settings.

  7. Restart Oracle HTTP Server. See Section 4.1.4.

The request configuration settings are saved, and shown on the Performance Directives page.

5.3.2 Using Fusion Middleware Control to Set the Connection Configuration

To specify the connection configuration using Fusion Middleware Control, do the following:

  1. Select Administration from the Oracle HTTP Server menu.

  2. Select Performance Directives from the Administration menu. The Performance Directives page appears.

  3. Enter the maximum connection queue length in the Maximum Connection Queue Length field (ListenBacklog directive). This is the queue for pending connections. This is useful if the server is experiencing a TCP SYN overload, which causes numerous new connections to open up, but without completing the pending task.

  4. Set the Multiple Requests per Connection field (KeepAlive directive) to indicate whether or not to allow multiple connections. If you choose to allow multiple connections, enter the number of seconds for timeout in the Allow With Connection Timeout field.

    The Allow With Connection Timeout value sets the number of seconds the server waits for a subsequent request before closing the connection. Once a request has been received, the specified value applies. The default is 15 seconds.

  5. Review the settings. If the settings are correct, click Apply to apply the changes. If the settings are incorrect, or you decide to not apply the changes, click Revert to return to the original settings.

  6. Restart Oracle HTTP Server. See Section 4.1.4.

The connection configuration settings are saved, and shown on the Performance Directives page.

5.3.3 Using Fusion Middleware Control to Set the Process Configuration

The child process and configuration settings impact the ability of the server to process requests. You may need to modify the settings as the number of requests increase or decrease to maintain a well-performing server.

For UNIX, the default number of child server processes is 2. For Microsoft Windows, the default number of threads to handle requests is 150.

To specify the process configuration using Fusion Middleware Control, do the following:

  1. Select Administration from the Oracle HTTP Server menu.

  2. Select Performance Directives from the Administration menu. The Performance Directives page appears.

  3. Enter the number for the initial child server processes in the Initial Child Server Processes field (StartServers directive). This is the number of child server processes created when Oracle HTTP Server is started. The default is 2. This is for UNIX only.

  4. Enter the number for the maximum idle threads in the Maximum Idle Threads field (MaxSpareThreads directive). An idle thread is a process that is running, but not handling a request.

  5. Enter the number for the minimum idle threads in the Minimum Idle Threads field (MinSpareThreads directive).

  6. Enter the number for the threads per child server process in the Threads per Child Server Process field (ThreadsPerChild directive).

  7. Review the settings. If the settings are correct, click Apply to apply the changes. If the settings are incorrect, or you decide to not apply the changes, click Revert to return to the original settings.

  8. Restart Oracle HTTP Server. See Section 4.1.4.

The process configuration settings are saved, and shown on the Performance Directives page.

5.4 Understanding Process Security

By default, Oracle HTTP Server runs as a non-root user (the user that installed Oracle Fusion Middleware). Therefore, on UNIX systems, if you plan on running Oracle HTTP Server on a privileged port (for example, port 80), you must enable Oracle HTTP Server to run as root. See "Starting Oracle HTTP Server on a Privileged Port".

For additional security on UNIX, you can change the User directive in the httpd.conf configuration file to nobody. Be sure that the child processes can accomplish their tasks as the user nobody.

If your PL/SQL application is using the file system caching functionality in mod_plsql, then the httpd processes should have read and write privileges to the cache directory, specified through the parameter PlsqlCacheDirectory in ORACLE_INSTANCE/config/OHS/<ohs_name>/mod_plsql/cache.conf. By default, this parameter points to ORACLE_INSTANCE/OHS/<ohs_name>.

Finally, given that the cached content might contain sensitive data, the contents of the file system cache should be protected. So, although Oracle HTTP Server might run as nobody, access to the system as this user should be well-protected.