This chapter discusses how you can tune the performance of your Oracle 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 Oracle Portal:
See Also:
The Performance page on Portal Center:
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.
To increase the concurrency of the PPE, perform the following step:
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 DOMAIN_HOME\config\fmwconfig\servers\WLS_PORTAL\applications\portal\configuration\appConfig.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 parameter for the PPE is:
<poolSize>50</poolSize>
For the configuration changes to take effect restart the Oracle Fusion Middleware middle tier.
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 Oracle 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:
Typical requests that are concurrently being serviced at any point in time consist of a wide variety of request types (for example, static images, portal page requests, and other Oracle HTTP Server requests), and the real number of concurrent requests that simultaneously need to access the portal repository is quite small.
As Oracle Portal leverages Oracle Web Cache and the Portal File Cache to cache content, many times Oracle Portal does not need to contact the portal repository at all, thereby reducing the database session requirements.
For portal page requests, the poolSize parameter in the PPE acts like a throttle, which reduces the possibility of flooding the system with concurrent requests for portal pages.
This section only talks about sessions needed by the Portal Services running inside Oracle Portal. Other entities which connect to the same repository must also be accounted for.
Configuring the MaxClients Setting
Because login frequency is generally lower than Oracle 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_INSTANCE\config\OHS\ohs1
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 Oracle Portal listener, you can separately tune the MaxClients parameter according to the needs of the OracleAS Single Sign-On and the needs of Oracle 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:
# MaxClients: maximum number of server processes allowed to start # MaxRequestsPerChild: maximum number of requests a server process serves <IfModule prefork.c> StartServers 5 MinSpareServers 5 MaxSpareServers 10 MaxClients 150 MaxRequestsPerChild 0 AcceptMutex fcntl
Notes:
If you tune the OracleAS Single Sign-On and the Oracle Portal separately, each will have a separate listener. The Oracle Portal will control the resources (sessions) on the portal database and the OracleAS Single Sign-On will control the resources on the OracleAS Single Sign-On database.
The number of sessions and connections that the database permits is limited by the value set in the Oracle Database's init.ora file. Refer to the Oracle Database documentation library for more information.
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, Oracle 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 Fusion Middleware User's Guide for mod_plsql.
Portal Services leverage Oracle Net Services to connect to the Oracle Portal schema in the Oracle 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 Oracle Portal.