|
Oracle® Application Server Portal Configuration Guide
10g Release 2 (10.1.4) B19305-03 |
|
 Previous |
 Next |
|
Oracle® Application Server Portal Configuration Guide
10g Release 2 (10.1.4) B19305-03 |
|
|
Previous |
Next |
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:
|
See Also:
|
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 regulator that permits 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 cannot get through because you have not 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. It may also result in poorer rather than better performance. 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 Portal Services to communicate with the portal database. For each server process that executes a portal database 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 Portal Services 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. If the ratio of requests for PL/SQL procedures versus other types of requests suddenly becomes very high, you risk overloading your database.
|
Note: On Windows, consider tuning the Oracle HTTP Server parameterThreadsPerChild.
|
The key to good performance is determining the number of Web requests the servers in your configuration can process, and 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.
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 computers, 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.
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 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 Oracle Enterprise Manager 10g Application Server Control Console.
For details, see Section 7.2.1, "Accessing 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
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 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 perform 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 to 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, thePoolSize 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. Refer to "Option 1: Create a New OC4J Instance to Create Another Set of PPE Threads" for the procedure to do this.
|
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.
The total number of database sessions needed to run OracleAS Portal is a factor of the total number of concurrent requests that simultaneously need to access the portal repository. The total number of concurrent requests of any type that can be serviced by a given instance is itself a factor of the Oracle HTTP Server configuration parameter called MaxClients.
Each connection to the portal repository results in 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.
Therefore, if MaxClients is set to 150, but the maximum number of concurrent requests that ever need to simultaneously access the portal repository is 50, then you need to ensure that the database is configured to allow for (50*2) = 100 sessions.
It is theoretically possible, though extremely remote, that all 150 requests have to simultaneously access the portal repository, in which case the number of database sessions required would be (150*2) = 300.
If the number of concurrent requests that need to simultaneously access the portal repository is high, and the allowed number of sessions has been exceeded, then clients may be "locked out". However, setting a very high value for the number of sessions will unnecessarily consume resources.
|
Notes:
|
Configuring the MaxClients Setting
Because 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.
Perform the following steps to configure the MaxClients setting:
For the OracleAS Single Sign-On's listener, once you've determined the approximate value to set for the MaxClients parameter, edit this accordingly in the configuration file, httpd.conf, which is located in:
ORACLE_HOME/Apache/Apache/conf/
Tune down the MaxClients setting to control the number of requests that Oracle HTTP Server services on the Oracle HTTP Server listener. This controls the maximum number of sessions that can be established.
For the OracleAS Portal listener, you can separately tune the MaxClients parameter according to the needs of the OracleAS Single Sign-On and the needs of OracleAS Portal, without creating a conflict. This parameter directly corresponds to the number of sessions established and to the maximum workload that the Oracle HTTP Server listener can handle on the portal listener.
The following example shows the MaxClients section in the httpd.conf file:
# Limit on total number of servers running, that is, limit on the number # of clients who can simultaneously connect --- if this limit is ever # reached, clients are LOCKED OUT, so it should NOT BE SET TOO LOW. # It is intended mainly as a brake to keep a runaway server from taking # the system with it as it spirals down... # MaxClients 150
|
Notes:
|
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
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.
|
Note: Starting with this release, OracleAS Portal implements in-memory caching of the session cache. This functionality reduces the possibility of contention for reading frequently used session cache objects, thereby reducing the need to move the session cache content to a more performant file system. |
More information on how to do this can be found in the section describing how to optimize PL/SQL performance, in the Oracle Application Server mod_plsql User's Guide.
Portal Services leverage Oracle Net Services to connect to the OracleAS Portal schema in the OracleAS Metadata Repository. By tuning Oracle Net Services, you can improve database access performance
Refer to the paper, "Tuning Oracle Net Services to optimize mod_plsql Database access times" on the Oracle Technology Network (OTN) at http://www.oracle.com/technology/. The tuning steps mentioned in this document are still applicable to OracleAS Portal.
