9 Tuning Performance in OracleAS Portal

This chapter discusses how you can tune the performance of your OracleAS Portal on the configuration, after you have set up the basic configuration of your Portal system.

This chapter contains the following list of options for tuning the performance of OracleAS Portal:

Setting the Number of Server Processes
Setting the Number of Idle Processes
Setting the Number of PPE Fetchers
Tuning the Oracle HTTP Server
Generating Performance Reports
Tuning File System Cache to Improve Caching Performance

See Also:
Oracle Application Server Performance Guide

9.1 Setting the Number of Server Processes

Oracle HTTP Server processes Web requests by distributing them to HTTP processes. Oracle HTTP Server can serve all types of requests originating in users' browsers, such as those for static files, Java servlets, or PL/SQL procedures.

MaxClients is an Oracle HTTP Server configuration directive that controls the maximum number of Web requests that Oracle HTTP Server can handle at any given time. When the MaxClients value is exceeded, Oracle HTTP Server refuses to handle any new requests until it handles the current load and the HTTP processes are freed. In fact, client browsers may be "locked out" if the number of allowable sessions has been exceeded by other browsers.

One way to think of the MaxClients directive is that it's a throttle that permits just the right flow of concurrent Web requests to your server. Set it too low, and your Web portal performance may suffer. Even though you may have the server and database resources to handle more traffic with quicker response intervals, Web requests can't get through because you haven't set enough processes in MaxClients.

Setting MaxClients too high unnecessarily consumes resources, because each HTTP process server consumes resources, such as CPU time, memory, and I/O. And it may result in poorer rather than better performance. Why? Keep in mind that Oracle HTTP Server can handle all sorts of requests, including those for PL/SQL procedures. When Oracle HTTP Server receives such a request, it hands it off to mod_plsql to communicate with the Portal database. For each server process that executes a mod_plsql request, there will be a need to cache a database connection. The value you set for MaxClients, therefore, sets the upper limit of database connections that mod_plsql can open.

Say you set MaxClients to the maximum number, 1024. At any given time, Oracle HTTP Server is ready to handle 1024 simultaneous Web requests, including some that require database connections. Even if your server is large enough to deal with this, the database it is connected to may not be. And if the ratio of requests for PL/SQL procedures versus other types of requests suddenly becomes very high, you risk overloading your database.

Note:

For Windows platforms, you should look at tuning the Oracle HTTP Server parameter ThreadsPerChild

The key to good performance is determining the number of Web requests the servers in your configuration can process, as well as how much traffic your database can handle. So if your Portal configuration includes multiple middle-tier servers connected to a single database, the number of possible Web requests you can handle is probably going to be limited more by database capacity than the middle-tiers.

9.2 Setting the Number of Idle Processes

MinSpareServers is a UNIX-specific Oracle HTTP Server directive that sets the minimum number of idle sessions. An idle session is one that is not currently handling a Web request. If the number of idle sessions is fewer than the number specified in MinSpareServers, new processes are created at a maximum rate of 1 in every second.

You should consider tuning this parameter only on very busy sites. The default setting is 5. Setting this parameter to a large number is almost always a bad idea. A rule of thumb is to set MinSpareServers at a little over the average number of Web requests your Portal typically handles. Ideally, you can set it so user requests are filled all the time by open ports without having to open a new one, but this is possible if you have the database resources to support a lot of ports.

Unlike UNIX, Windows is a thread-based operating system where one process is started and then additional child processes are threaded as required. For Windows machines, the directive is called MaxThreadsPerChild. This is the number of concurrent requests the server will allow. Set this value according to the responsiveness of the server and the amount of system resources you want to allow the server to consume. MaxThreadsPerChild on Windows is equivalent to MaxClients on UNIX.

9.3 Setting the Number of PPE Fetchers

A request for a Portal page originates in the form of a URL sent from a user's browser to the HTTP server. If the request is for a Portal page, it is forwarded to the Parallel Page Engine (PPE). The PPE then asks each Web provider that owns a portlet on the page to execute the portlet and return content to the Portal page.

There are two options available to enable you to increase the concurrency of the PPE:

Option 1: Create a New OC4J Instance to Create Another Set of PPE Threads

Complete these steps to change the number of OC4J_Portal processes:

Access the Application Server Control Console.

Typically the Application Server Control Console is located at http://www.abc.com:1812. Refer to Chapter 7, "Monitoring and Administering OracleAS Portal" for more information about using the Application Server Control Console.
Click the link for the application server middle-tier where OracleAS Portal is installed.
Click the OC4J_Portal link.
Click the Administration link.
Click the Server Properties link.
In the Under the Multiple VM Configuration section, change the Number of Processes for the default_island as shown in Figure 9-1.

Figure 9-1 Multiple VM Configuration Section

Description of the illustration cg_perf_multi_vm.gif
Click Apply.
Navigate back to the OC4J_Portal home page.
Click Restart, to restart the OC4J_Portal instance.

Alternatively, you can edit the file opmn.xml manually, though the use of Application Server Control Console is the recommended approach.

The parameter to create multiple Oracle Application Server Containers for J2EE instances is called numProcs and is configured in the file ORACLE_HOME/opmn/conf/opmn.xml

The changed file would look something like this:

    <oc4j instanceName="OC4J_Portal" gid="OC4J_Portal" numProcs="2"> 
      <config-file path="E:\Ora902\j2ee\OC4J_Portal\config\server.xml"/> 
      <java-option value="-server -Xincgc -Xnoclassgc -Xmx100m "/> 
      <oc4j-option value="-properties"/> 
      <port ajp="3001-3100" rmi="3101-3200" jms="3201-3300"/> 
      <environment> 
        <prop name="PATH" value="E:/Ora902/bin"/> 
        <prop name="DISPLAY" value="localhost:0"/> 
      </environment> 
    </oc4j>

For the configuration changes to take effect follow the following steps:

Run the following command:

ORACLE_HOME/dcm/bin/dcmctl updateconfig -ct opmn

Restart the Oracle Application Server middle-tier as follows:

ORACLE_HOME/opmn/bin/opmnctl stopall
ORACLE_HOME/opmn/bin/opmnctl startall

Option 2: Increase the Value of Default Number of Threads

The PPE uses a pool of fetchers to forward requests over the Internet to Web providers and wait for data to be returned. Once it is finished with the request, the fetcher is available to handle another new request.

The parameter to tune the number of PPE threads is called poolSize and is configured in the file ORACLE_HOME/j2ee/OC4J_Portal/applications/portal/portal/WEB-INF/web.xml.

The default setting is 25. For most Web portals, you should never have to change pool size. But keep in mind that if pool size is too low, the user notices that pages take too long to draw at peak periods. If pool size is set too high, a possible resource drain may occur because too many concurrent URL requests can overwhelm the PPE.

The changed file would look something like this:

<web-app> 
  <servlet> 
    <servlet-name>page</servlet-name> 
      <servlet-class>oracle.webdb.page.ParallelServlet</servlet-class> 
    <init-param> 
      <param-name>logpath</param-name> 
      <param-value>./</param-value> 
    </init-param> 
    ... 
    <init-param> 
      <param-name>poolSize</param-name> 
      <param-value>50</param-value> 
    </init-param> 
    ... 
  </servlet> 
...

For the configuration changes to take effect:

Run the following command:

ORACLE_HOME/dcm/bin/dcmctl updateconfig

Restart the Oracle Application Server middle-tier.

Note:

Even for a site with high traffic, the PoolSize parameter should not be set to beyond the range of 50-125. If there is a need to set the value higher than this, then consider adding more OC4J instances as mentioned in "Option 1: Create a New OC4J Instance to Create Another Set of PPE Threads".

9.4 Tuning the Oracle HTTP Server

However you choose to configure the Oracle HTTP Server listener, you can optimize performance by setting an approximate number of simultaneous requests that can be handled by the Oracle HTTP Server listener.

On UNIX, in particular, since the Oracle HTTP Server is process-based, each process must open a database connection for each DAD that has requested it. As a result, the number of requests can be quite high, which may result in clients being "locked out" if the number of sessions allowable has been exceeded. However, setting too high of a value unnecessarily consumes resources.

The scenario in the preceding text is described here:

For every service request from an OracleAS Portal DAD, there is one network connection and two sessions (the two sessions use the same physical connection).

The first session is for portal and the second is for portal_public.
If you are logging in to OracleAS Portal, then you have to open a connection for the OracleAS Single Sign-On DAD (SSO DAD). This consumes one network connection and two sessions.

In this case, the first session is for orasso and the second session is for orasso_public.
The Oracle HTTP Server configuration setting that determines the maximum number of requests being handled simultaneously is named MaxClients. It defaults to 150.

If each user were logging in and working in OracleAS Portal, then scenario (1) and (2) earlier would result in four sessions for every process. The total number of sessions for such a scenario is calculated as follows:
```
150 * 4 = 600 
```
600 sessions and approximately 300 database connections (2 sessions for every connection)

Configuring the MaxClients Setting

Since login frequency is generally lower than OracleAS Portal access frequency, it makes sense to configure the OracleAS Single Sign-On on a separate Oracle HTTP Server listener. The objective is to tune down the MaxClients setting to a value that is reasonable, without affecting the needs of the portal system.

OracleAS Portal makes extensive use of mod_plsql, which maintains a pool of connections to the database. The MaxClients parameter tunes the number of processes, which directly relates to the number of database connections pooled by mod_plsql.

9.5 Generating Performance Reports

This release includes a set of SQL scripts that can generate performance reports for OracleAS Portal. Other than using these scripts, there is no way to obtain performance-reporting information. These scripts allow a portal administrator to load OracleAS Portal log files into a database table and create reports based on that information. The scripts are located in the following directory:

ORACLE_HOME/portal/admin/plsql/perf

The file README.html in the scripts subdirectory explains how the scripts can be used to monitor OracleAS Portal performance.

The statistics collected indicate, among other things, how long overall requests take to complete, how much of that time was spent in the user's procedure, which user made the request, whether a database connection was obtained from the connection pool, and what type of caching was used. The performance scripts also enable you to extract information similar to that, which was available in earlier releases of OracleAS Portal. Some of the performance reports that you can generate include:

Unique logins for each day, or hour
Page views for each day, or hour
Top ten pages and portlets and their response time
Response times
Peak login time each day
Logins for each day
Portlets execution time
Slowest portlet
Total hits for each day
Most and least popular portlets
Unique users logged in each day
Page hits for each day
Portlet hits for each day
Request breakdown by IP address and hostname

9.6 Tuning File System Cache to Improve Caching Performance

Tuning the File system cache can increase caching performance. Two ways of tuning the file system cache are:

Configuring File System Cache to Reside on a Faster File System.
Moving Session Cache Directory to More Performant File System.

More information on how to do this can be found in section describing how to optimize PL/SQL performance, in the Oracle Application Server mod_plsql User's Guide.