| Oracle® HTTP Server mod_plsql User's Guide 10g Release 1 (10.1) Part Number B12303-01 |
|
|
View PDF |
This chapter discusses the techniques for improving PL/SQL performance in Oracle HTTP Server.
This chapter contains th e following sections:
This chapter describes several techniques to improve the performance of PL/SQL base d Web applications in Oracle HTTP Server.
Table 4-1
lists recommendations for Database Access Descriptor (DAD) parameters and settings. By default, these DAD parameters are specified i
n the file dads.conf. On UNIX systems, this is in the ORACLE_HOME/Apache/modplsql/conf directory. On Windows systems, by default, this file is in the directory ORACLE_HOME\Apache\Apache\modp
lsql\conf directory. The file dads.README in this directory describes the DAD parameters in detail.
| Parameter | Recommended Setting |
|---|---|
|
|
Set this to Default Value: |
|
|
For
newer DADs, use the Note: for HA configurations of the database, it is recommended that the connect string parameter gets resolve d through an LDAP lookup. |
|
|
For multibyte character
sets like Japanese or Chinese, setting this to Default Value: |
|
|
Increasing this parameter allows pooled database connections to remain available, in the pool, for the specified time See Also: Section 4.3.3, "Restarting the mod_plsql Connection Pool" |
|
|
This parameter should be set to Default Value: |
|
|
If the PL/SQL based Web application does not leak resources or memory, this parameter can be set t o a higher value (for example, 5000). See Also: Section 4.3.2, "Closing Pooled Database Sessions" and Section 4.4.2, "Connection Pooling Tips and Oracle HTTP Server Configuration". |
|
|
Set this parameter to match the database Globalization Support parameters to eliminate overheads in character set conversions in Oracle Net Services |
|
|
Set this parameter to |
Table 4-2 lists mod_ plsql caching options and the sections that describe these caching options.
| See Also:
Chapter 6 "Oracle HTTP Server Modules" in the Oracle HTTP Server Administrator's Guide for details on the DAD Parameters shown in Table 4-1. |
This chapter describes PL/SQL perfor mance issues that apply on platforms where the Oracle HTTP Server is process-based and thread-based. On a process-based Oracle HTTP S erver, such as those running on UNIX-based platforms, each process servers all types of HTTP requests, including servlets and PL/SQL, static files. On a thread-based Oracle HTTP Server, such as Windows-based platforms, there is just one Oracle HTTP Server process wi th multiple threads within the process; individual threads can be used serve all types of HTTP requests.
|
a>Note: In some ca ses in this chapter we make references to performance optimizations that apply for PL/SQL based Web applications where the distinctio n between platforms, either process-based or thread based is significant. |
When tuning mod_plsql to improve the performance of PL/SQL base d Web applications, it is important to be familiar with some mod_plsql internals. This section presents a basic overview of some mod_ plsql functionality.
This section covers the following topics:
The Database Server connection pooling logic supplied with mod_p lsql can be best explained with an example.
For example, consider the following typical sce nario:
httpd process P1) starts servicing the request R1.
li>
In the worst-case scenario, the total number of database connections pooled by mod_plsql is a factor of the total numb
er of active DADs multiplied by the number of Oracle HTTP Server (httpd) processes running at any given time for a singl
e Oracle HTTP Server instance. If you have configured the Oracle HTTP Server processes to a high number, you need to configure the ba
ck-end database to handle a corresponding number of database sessions, and remember that this configuration value needs to be multipl
ied times the number of Oracle HTTP Server instances that use the back-end database.
For ex
ample, if there are three Oracle HTTP Server instances configured to spawn a maximum of 50 httpd processes each, plus tw
o active DADs, you need to set up the database to allow 300 (3*50*2) sessions. This number does not include any sessions
that are needed to allow other Web applications to connect.
On UNIX systems, database conn
ections cannot be shared across httpd processes, and process-based platforms have more of a Connectio
n Reuse feature than Connection Pooling. Note that this is an artifact of the process-model in Oracle HT
TP Server.
|
Note: Refer to Section 4.4.4, "Two-Listener Strategy" if the number of database sessions is a concern for details on how to address this problem. On Windows syste ms, the Oracle HTTP Server runs as a single process, and the connection pool is shared. Therefore, Sec tion 4.4.4, "Two-Listener Strategy" does not apply to Windows systems. |
Pooled database sessions are closed under the following circum stances:
By default each connection pooled by mod_pl
sql is used to service a maximum of 1000 requests and then the database connection is shut down and reestablished. This is done to ma
ke sure that any resource leaks in the PL/SQL based Web application, or in the Oracle client server side, do not adversely affect the
system. To change the default value of 1000 by tuning the DAD configuration parameter PlsqlMaxRequestsPerSession<
/code>.
By default, each pooled connection gets automatically cleaned up after 15 m
inutes of idle time. This operation is performed by the cleanup thread in mod_plsql. For heavily loaded sites, each connection could
be used at least once every 15 minutes and the connection cleanup might not happen for a long period of time. In such a case, the con
nection would be cleaned up based on the configuration value of PlsqlMaxRequestsPerSession. Change the default value of
15 minutes by tuning the mod_plsql configuration parameter PlsqlIdleSessionCleanupInterval. Consider increasing the defa
ult for better performance in cases where the site is not heavily loaded.
On UNIX systems,
the Oracle HTTP Server configuration parameter MaxRequestsPerChild governs when an Oracle HTTP Server process will be s
hut down. For example, if this parameter is set to 5000, each Oracle HTTP Server process would serve exactly 5000 reques
ts before it is shut down. Oracle HTTP Server processes could also start up and shut down as part of Oracle HTTP Server maintenance b
ased on the configuration parameters MinSpareServers, MaxSpareServers, and MaxClients. For mod
_plsql connection pooling to be effective, it is extremely important that Oracle HTTP Server is configured so that each Oracle HTTP S
erver process remains active for some period of time. An incorrect configuration of Oracle HTTP Server could result in a setup where
Oracle HTTP Server processes are heavily started up and shut down. Such a configuration would require that each new Oracle HTTP Serve
r process replenish the connection pool before subsequent requests gain any benefit of pooling.
| <
font face="Arial, Helvetica, sans-serif">See Also:
Chapter 6 "Oracle HTTP Server Modules" in the Oracle HTTP Server Administrator's Guide. |
This depends primarily on the amount of time the database is shut down. If the database is
restarted after more than 15 minutes from being shut down, the users do not experience any problems when trying to use the Oracle HT
TP Server listener. This is because the cleanup thread in mod_plsql cleans up database sessions that are unused for more than 15 minu
tes. The time specified for cleaning up idle sessions is tunable using the PlsqlIdleSessionCleanupInterval, configuratio
n parameter (the default value is 15 minutes).
If the database is restarted in less than 15 minutes, then a few initial requests return with errors, but the system quickly becomes usable again. The number of requests that ex perience failure is equal to the number of connections that were pooled by mod_plsql.
While using mod_plsql, there are three areas that affect performance and scalability:
PL/SQL Gateway users should consider the following topics when developing PL/SQL based Web applications:
Try to restrict the number of DADs that each Oracle HTTP Server node uses.
PL/SQL provides the ability to create t ables. To build PL/SQL tables, you build a table that gives the datatype of the table, as well as the index of the table. The index o f the table is the binary integer ranging from -2147483647 to +2147483647. This table index option is known as spa rsity, and allows meaningful index numbers such as customer numbers, employee number, or other useful index keys. Use PL/SQL tab les to process large amounts of data.
PL/SQL provides TABLE and VARRAY<
/code> (variable size array) collection types. The TABLE collection type is called a nested table. Nested tables are unl
imited in size and can be sparse, which means that elements within the nested table can be deleted using the DELETE proc
edure. Variable size arrays have a maximum size and maintain their order and subscript when stored in the database. Nested table data
is stored in a system table that is associated with the nested table. Variable size arrays are suited for batch operations in which
the application processes the data in batch array style. Nested tables make for efficient queries by storing the nested table in a st
orage table, where each element maps to a row in the storage table.
PL/SQL bas ed Web applications should use the procedure name overloading feature with caution. It is best if procedure name overloading is avoid ed by having multiple procedures with different names.
PL/SQL based Web applications should be aware of the overhead in trying to execute procedures where the URL does not provide enough details to know about the type of the parameter, such as scalar or array. In such cases, the first a ttempt to execute a procedure fails and the procedure signature needs to be described before it can be executed by mod_plsql.
Procedures should make use of the more performant 2-parameter styl e flexible parameter passing rather than the 4-parameter style parameter passing
Consider the following topics when configuring connection pooling with Oracle HTTP Server:
PlsqlMaxRequestsPerSession
Creating new database connections is an expensive ope
ration and it is best if every request does not have to open and close it own database connections. The optimal technique is to make
sure that database connections opened in one request are reused in subsequent requests. In some rare situations, where a database is
accessed very infrequently and performance is not a major concern, connection pooling can be disabled. For example, if the administra
tor accesses a site infrequently to perform some administration tasks, then the DAD used to access the administrator applications can
choose to disable connection pooling. To disable connection pooling, set the DAD parameter PlsqlMaxRequestsPerSession t
o the value 1.
httpd processes
can handle the average load on the system. In addition, the configuration parameter MaxClients in the httpd.conf
code> file should be able to handle random load spikes as well.MaxRequestsPerChild co
nfiguration parameter is set to a high number. For PL/SQL based Web applications, this should not be set to 0.
KeepAlive should be disabled. This ensures that each proc
ess is available to service requests from other clients as soon as a process is done with servicing the current request. For sites wh
ich are not heavily loaded, and where it is guaranteed that the number of Oracle HTTP Server processes are always greater than the nu
mber of simultaneous requests to the Oracle HTTP Server listener, enabling the KeepAlive parameter results in performanc
e improvements. In such cases, make sure to tune the KeepAliveTimeout parameter appropriately.Timeout in the Oracle HTTP Server configuration.
This ensures that Oracle HTTP Server processes are freed up earlier if a client is not responding in a timely manner. Do not set thi
s value too low, otherwise slower responding clients could time out.mo
d_expires. You should also consider front-ending your Web site with Oracle Application Server Web Cache.
mod_expires?
<
ul class="LD3">
View In
fo from the pop up menu (or the equivalent command for your browser). If the top panel in the page information window lists ma
ny different images and static content, then the site could benefit from the use of mod_expires.grep utility to search for 304 in the access_log and d
ivide this resulting number of lines by the total number of lines in the access_log. If this percentage is high, then th
e site could benefit from the use of mod_expires.
Location directive used to serve your static image files. Add the ExpiresActive and ExpiresDefault d
irectives to it.
Alias /images/ "/u01/app/oracle/myimages/" <Direct ory "/u01/app/oracle/myimages/"> AllowOverride None Order allow, deny Allow from all ExpiresActive On ExpiresDefault A25920 00 </Directory>
The browser caches a
ll static files served off the /images path for 30 days from now. Refer to the Oracle HTTP Server Administrator's Guide for more details.
Expires heade
r?
Expires header. Right click the mouse on the page and select View Info, from
the pop up menu. or use the equivalent command for your browser.Expires header.Expires header should be set t
o a valid date. If this entry is No date given, then the file is not being tagged with the Expires header.<
/li>Consid er the following topics when tuning the number of database sessions:
processes and sessions parameters in the Oracle init$SID.ora config
uration file should be set so that Oracle is able to handle the maximum number of database sessions. This number should be proportion
al to the number of DADs times the maximum number of Oracle HTTP Server processes, times the number of Oracle HTTP Server instances.<
/li>
On platforms where the Oracle HTTP Server is process-based, such as all UNIX-based platforms, ea
ch process serves all types of HTTP requests, including servlets, PLSQL, static files, and CGI. In a single Oracle HTTP Server listen
er setup, each httpd process maintains its own connection pool to the database. The maximum number of database sessions
is governed by the setting in httpd.conf configuration file for StartServers, MinSpareServers,
and MaxSpareServers, plus the load on the system. This architecture does not allow for tuning the number of database se
ssions based on the number of mod_plsql requests. To tune the number of database sessions based on the number of mod_plsql requests,
install a separate HTTP listener for mod_plsql requests only. This approach greatly reduces the number of database sessions that are
needed to serve mod_plsql requests.
For example, assume a main Oracle HTTP Server listener
is running on port 7777 of mylsnr1.mycompany.com. First, you can install another Oracle HTTP Server listener on port 888
8 on mylsnr2.mycompany.com. Next, redirect all mod_plsql requests made to mylsnr1.mycompany.com:7777 to the
second listener on mylsnr2.mycompany.com:8888. Review the following steps:
mylsnr1.mycompany.com:7777 to mylsn
r2.mycompany.com:8888, make the following configuration changes:
ORACLE_HOME/Apache/
modplsql/conf/plsql.conf file. Comment out the following line by putting a # in front of the line:
#LoadModule plsql_module...
mylsnr1.mycompany.com to the configuration file O
RACLE_HOME/Apache/modplsql/conf/dads.conf in mylsnr2.mycompany.com.
Comment out the DAD location configuration parameters on mylsnr1.mycompany.com by prefixing the line
with a "#" character.
#<Location /pls/dad> #... #</Location>
dads.conf:
ProxyPass /pls/dad http://mylsnr2.mycompany.com:8888/pls/dad
Repeat the configuration procedures for all DAD Locations.
mylsnr2.mycompany.com:8888. Depending on how the URLs are being generated in the PL/SQL based Web application, there are three options:
S
ERVER_NAME and SERVER_PORT, then it is easy to change the configuration of the listener on mylsnr2.mycompan
y.com. Edit the file and change the lines ServerName and Port in the ORACLE_HOME/Apache/Apache/conf/httpd.conf file for the second listener as follows:
Server Name mylsnr1.mycompany.com (was mylsnr2.mycompany.com) Port 7777 (was 8888)
HTTP_HOST, you need to override the CGI environment variables for the Oracle HTTP Server listener running on Por
t 8888. Add the following lines to the ORACLE_HOME/Apache/modplsql/conf/dads.conf file for each DA
D to override the default CGI environment variables HOST, SERVER_NAME, and SERVER_PORT:
PlsqlCGIEnvironmentList SERVER_NAME mylsnr1.mycompany.com PlsqlCGIEnvironm entList SERVER_PORT 7777 PlsqlCGIEnvironmentList HOST mylsnr1.us.oracle.com:7777
In all cases, the intent is to fool the application to generate URLs as if there never was a second listener.
mylsnr1.mycompany.com can be configured based on the total load on the Oracle HTTP Server listener. The second
listener on mylsnr2.mycompany.com can be fine-tuned based on just the mod_plsql requests being made.While executing some of the stored procedures, mod_plsql may incur
a Describe overhead, which would result in two extra round trips to the database for a successful execution. This has p
erformance implications.
In order to execute st
ored procedures, mod_plsql needs to know about the datatype of the parameters being passed in. Based on this information, mod_plsql b
inds each parameter either as an array or as a scalar. One way to know the procedure signature is to describe the procedure before ex
ecuting it. However, this approach is not efficient because every procedure has to be described before execution. To avoid the descri
be overhead, mod_plsql looks at the number of parameters passed for each parameter name. It uses this information to assume the datat
ype of each variable. The logic is simply that if there is a single value being passed, then the parameter is a scalar, otherwise it
is an array. This works for most cases but fails if there is an attempt to pass a single value for an array parameter or pass multipl
e values for a scalar. In such cases, the first attempt to execute the PL/SQL procedure fails. mod_plsql issues a Describe call to get the signature of the PL/SQL procedure and binds each parameter based on the information retrieved from the Descr
ibe operation. The procedure is re-executed and results are sent back.
This De
scribe call occurs transparently to the procedure, but internally mod_plsql has encountered two extra round trips, one for the
failed execute call and the other for the describe call.
You can avoid performance problems with the following:
CREATE OR REPLACE PACKAGE testpkg AS TYPE myArrayType is TABLE of VARCHAR2(32 767) INDEX BY binary_ integer; PROCEDURE arrayproc (arr myArrayType); END testpkg; /
/pls/.../testpkg.arrayproc? arr= 1, change the specification to be similar to the following:
CREATE OR REPLACE PACKAGE testpkg AS TYPE myArrayType is TABLE of VARCHAR2( 32767) IN DEX BY binary_integer; PROCEDURE arrayproc (arr varchar2); PROCEDURE arrayproc (arr m yArrayType); END testpkg; /
arrayproc should be similar to:
CR EATE OR REPLACE PACKAGE BODY testpkg AS PROCEDURE arrayproc (arr varchar2) IS localArr myArrayType; BEGIN localArr( 1) := arr; arrayproc (localArr); < a name="1023212">END arrayproc;
Round-trip overhead exists if a PL/SQL pro cedure is using the older style four-parameter interface. The PL/SQL Gateway first tries to execute the procedure by using the two-pa rameter interface. If this fails, the PL/SQL Gateway tries the four-parameter interface. This implies that all four-parameter interfa ce procedures experience one extra round-trip for execution.
To avoid this overhead, it is recommend ed that you write corresponding wrappers that use the two-parameter interface and internally call the four-parameter interface proced ures. Another option is to change the specification of the original procedure to default to the parameters that are not passed in the two-parameter interface. The four-parameter interface has been provided only for backward compatibility and will be deprecated in th e future.
The flexible parameter passing mode in Oracle HTTP Server expects the PL/SQL procedure to have the e
xclamation mark before the procedure name. Due to performance implications of the auto-detect method used in Oracle HTTP Server, the
exclamation mark is now required for flexible parameter passing in Oracle HTTP Server. In Oracle HTTP Server, each procedure is descr
ibed completely before being executed. The procedure Describe call determines the signature of the procedure and require
s around-trip to the database. The PL/SQL Gateway in Oracle HTTP Server avoids this round trip by having end-users explicitly indicat
e the flexible parameter passing convention by adding the exclamation mark before the procedure.
Caching can improve the performance of PL/SQL base d Web applications. To improve performance, you can cache Web content generated by PL/SQL procedures in the middle-tier and decrease the database workload.
This section covers the techniques used in caching, including the fo llowing:
These techniques and levels
are implemented using owa_cache packages located inside the PL/SQL Web Toolkit.
In gene ral, the validation technique basically asks the server if the page has been modified since it was last presented. If it has not been modified, the cached page will be presented to the user. If the page has been modified, a new copy will be retrieved, presented to t he user and then cached.
There are two methods which use the Validation Technique: Last-Mod ified method, and the Entity Tag method. The next two sections show how these techniques are used in the HTTP protocol. Although the PL/SQL Gateway does not use the HTTP protocol, many of the same principles are used.
When a Web page is generated using the HTTP protocol, it contains a Last-Modified< /strong> Response Header. This header indicates the date, relative to the server, of the content that was requested. Browsers save th is date information along with the content. When subsequent requests are made for the URL of the Web page, the browser then:
Cache-enabled servers look for the
If the two do not match, an HTTP Response header such as "HTTP/1.1 200 OK" is generated and the new content is streamed, along with a new Last-Mo dified Response header. Upon receipt of this status code, the browser must replace its cache entry with the new content and new date information.
Another validation method pro vided by the HTTP protocol is the ETag (Entity Tag) Response and Request header. The value of this head er is a string that is opaque to the browser. Servers generate this string based on their type of application. This is a more generic validation method than the If-Modified-Since header, which can only contain a date value.
The ETag method works very similar to the Last Modified method. Servers g enerate the ETag as part of the Response Header. The browser stores this opaque header value along with the content that is steamed b ack. When the next request for this content arrives, the browser passes the If-Match header with the op aque value that it stored to the server. Because the server generated this opaque value, it is able to determine what to send back to the browser. The rest is exactly like the Last-Modified validation method as described earlier.
Using HTTP validation caching as a framework, the following is the Validation Model for mod_plsql.
PL/SQL based Web appli cations that want to control the content being served should use this type of caching. This technique offers some moderate performanc e gains. One example of this would be a Web application that serves dynamic content that could change at any given time. In this case , the Web application needs full control over what is being served. Validation caching always asks the Web application whether the ca ched content is stale or not before serving it back to the browser.
Figure 4-1 shows the use of the validation technique for mod_plsql.
owa_cache procedure from the PL/SQL Web Toolkit to set the tag and cache level:
owa_cache.set_cache(p_etag, p_level);
Text description of the illustration asper016.gif
Using the Validation Technique for mod_plsql, a second request is made by the client browser for the same PL/SQL proce dure.
Figure 4-2 shows the second request using the Validation Technique.
owa_cache functions from the PL/SQL Web Toolkit:
owa_cache.get_etag; owa_cache.get_level;
These owa functions get the tag and caching level.
o
wa_cache.set_not_modified procedure and generates no content. This causes mod_plsql to use its cached content. The cached cont
ent is directly streamed back to the browser.
Text description of the illustration asper017.gif
In the validation model, mod_plsql always asks the PL/SQL procedure if it can serve the content from the cache. In the expires model, the procedure pre-establishes the content validity period. Therefore, mod_plsql can serve the content from its cache without asking the procedure. This further improves performance because no interaction with the dat abase is required.
This caching technique offers the best performance. Use if your PL/SQL b ased Web application is not sensitive to serving stale content. One example of this is an application that generates news daily. The news can be set to be valid for 24 hours. Within the 24 hours, the cached content is served back without contacting the application. This is essentially the same as serving a file. After 24 hours, mod_plsql will again fetch new content from the application.
Assume the same scenario described for the Validation model, except the procedure uses the Expires model for caching.
Figure 4-3 shows the use of the expires technique for mod_plsql.
owa_cache procedure from the PL/SQL Web Toolkit to set the validity period and cache level:
owa_cache.set_expires(p_expires, p_level);
Text description of the illustration asper01 8.gif
Using the same expires model explained earlier, a second request is made by t he client browser for the same PL/SQL procedure.
Figure  ;4-4 shows the second request using the Expires Technique.
Text description of the illustration asper019.gif
A PL/SQL procedure determines whether generated content is system-level content or user-level. This help s the PL/SQL Gateway cache to store less redundant files if more than one user is looking at the same content. It decides this by:
SYSTEM as the caching level parameter to the owa_cache functions (set_cache
code> for validation model or set_expires for expires model). This is for every user that shares the cache.
By using system-level caching, you can save both space in your file system and time for all users i
n the system. One example of this would be a Web application that generates content that is intended for everybody using the Web appl
ication. By caching the content with the system-level setting, only one copy of the content is cached in the file system. Furthermore
, every user on that system benefits since the content is served directory from the cache.
USER as the parameter for th
e caching level. This is for a specific user that is logged in. The stored cache is unique for that user. Only that user can use the
cache. The type of user is determined by the authentication mode. Refer to the following table for the different types of users.
| Authentication Mode | |
|---|---|
|
Single Sign On (SSO) |
Lightweight user p> |
|
Basic |
|
|
Custom |
Remote user |
For example, if no user customizes a PL/SQL based Web application, then the output can be stored in a system-level cache. There will be only one cache copy for every user on the syste m. User information is not used since the cache can be used by multiple users.
However, if a user customizes the application, a user-level cache is stored for that user only. All other users still use the system level cache. For a user-level cache hit, the user information is a criteria. A user-level cache always overrides a system-level cache.
| See Also:
a>
Section 3.1, "Authenticating Users Through mod_plsql" for more information on authentication modes. |
Your decision whether to use the V
alidation technique or the Expires technique determines which owa_cache functions to call.
owa_cache package contains procedures to set and get special caching headers and environment variables.
These allow developers to use the PL/SQL Gateway cache more easily. This package should already be installed in your database.
<
a name="1024611">
Table 4-6 lists the primary functions to call.
You can configure and use a File System Cache to improve the performance of PL/SQL based Web applications.
This section covers the following topics:
This section covers mod_plsql related File System Cache tuning options. Cache contents are cached using Operating System supplied file system calls; the cached contents are not store d in the mod_plsql memory space. Using the mod_plsql File System Cache, the contents of the cache may be in memory when the Operating System supports, and the system is configured to use features such as memory disk (some UNIX platforms support memory disk based fas t storage).
The information in this section can improve the performance of PL/SQL based Web applications when mod_plsql is configured to use the File System Cache.
Table 4-7 lists the cache related parameters that you can set for mod_plsql. Set these parameters in the
cache.conf file that is available on UNIX in the directory, ORACLE_HOME/Apache/modplsql/conf, and on Windows, this is found in the directory, ORACLE_HOME\Apache\modplsql\conf.
|
Note: The file |
| Parameter | Description< /font> |
|---|---|
|
|
Sets the interval for running cache cleanup routines. Default: |
|
|
Defines the directory that holds the mod_plsql cache. On UNIX systems, the
default directory for the error log is: On Windows systems, the default directory is: See Also: Section 4.6.3, "Configuring File System Cache to Reside on a Faster File System" |
|
|
|
|
|
Controls the aging, in days for the cache contents. See Also: Section 4.6.4.2, "Sett ing the Days of Aging for Cache with PlsqlCacheMaxAge" |
|
|
Sets the maximum size, in bytes, for an individual file stored in the cache. See Also: Section 4.6 .4.3, "Setting the Maximum File Size for a Cache File with PlsqlCacheMaxSize" |
|
|
Limits the total size of the cache. The value is specified in bytes. |
The cache.conf parameter PlsqlCacheEnable enables mod_plsql caching.
For maximum performance, enable PlsqlCacheEnable by setting the value of this parameter to On.
This section describes how to configure a File System Cache to reside on a separate disk. When you use File System Cache and stor e the cache on a faster separate disk, performance should improve for all types of Web applications using File System Cache, includin g OracleAS Portal and generic PL/SQL based Web applications.
When you configure File System Cache, the cache can reside either on a separate physical disk or in a memory disk.
To set up a File System Cache on a separate disk:
On UNIX: /u01/ca
che
On Windows: E:\cache
On UNIX: ORACLE_HOME/
Apache/modplsql/conf/cache.conf
On Windows: ORACLE_HOME
\Apache\modplsql\conf\cache.conf
PlsqlCacheDirectory:
On UNIX: PlsqlCacheDirectory /u01/cache<
/p>
On Windows: PlsqlCacheDirectory E:\cache
This section covers the following topics:
The default installation sets the mod_plsql file system cache size to 2097152 bytes (20 Megabytes). I f your PL/SQL application does not make use of the OWA_CACHE packages, or uses them to cache small amounts of content, then the defau lt setting should be sufficient. If your PL/SQL application caches a lot of content in the mod_plsql file system cache, you should co nsider specifying a higher value.
To control the cache size, set the PlsqlCacheTotalS
ize parameter in the file cache.conf. On UNIX systems, this file is located under ORACLE_HOME/Apache/modplsql/conf directory. On Windows systems, this file is located under ORACLE_HOME\Apache\modplsql\conf.
You need to set the cache size high enough to achieve a high cache hit ratio. Try to set the cache size large enough so that frequently accessed content stays cached. It is also important to li mit the amount of disk space, so that the cache size does not grow too large. Correct tuning for the cache size provides enough cache to hold all frequently accessed content while preventing the cache size from growing too large, since a very large cache is ineffici ent to search.
The value for PlsqlCacheTotalSize is specified as a number of b
ytes. 1MB equals 1048576 bytes. This setting is a soft limit on the amount of cache allocated. In some cases, the cache size may grow
beyond this limit until the next cleanup operation. Therefore, the hard limit on the cache size is the underlying physical hard disk
size. When this limit is reached, no cache content can be written out to disk until space is available.
To determine a reasonable cache size, do the following:
LogLevel in httpd.conf to the
info level to enable mod_plsql logging.
error_log on a daily basis. On UNIX systems, the default directory for the error log is: ORACLE_HOMEORACLE_HOME\Apache\Apache\log<
/code>.The mod_plsql error_log entries have the form:
[info] mod_plsql: cachecleanup deleted=2571 max_age=96,2178852b kept=1042,25585368b time=128s limit=256000 00b
where:
delete
d is the number of cache files that got deleted during the cleanup process.
ma
x_age is the number of cache files and total size that got deleted because they haven't been used for some time.
kept is the number of cache files and total size that was kept after the cleanup process.
p>
time is the amount of time to perform the cleanup.
limit is the total cache size. This is the value of the PlsqlCacheTotalSize setting.
Interpret the entries in the error log as follows:
Using the PlsqlCacheMaxAge parameter, you can control the "stalene
ss" of cache content. The value for parameter is specified in units of days. The default value for this parameter is 30 (days). This
means cache content is kept in the cache if it is less than 30 days old. After 30 days, the content is considered for deletion during
the cleanup process.
The max_age information in mod_plsql error_log shows cache file aging information. If your site is a highly dynamic site, it would make sense to configure this setting to a low
er value, since the older cache content will usually not be used again and, therefore, the lower value does not affect the cache hit
ratio. If the site contains many static pages, it would make sense to increase the value of PlsqlCacheMaxAge so that the
cleanup process does not deliberately delete the cache content.
Using the PlsqlCacheMaxSize parameter, you can specify
the maximum size for individual files in the cache. Using this parameter prevents the case in which one cache file fills up the enti
re cache.
The default value for this parameter is 1048576 (bytes). In general, set this par ameter to a value that represents about 1-3% of the total cache size.
The cache cleanup parameter determines the frequency in which the File System Cache is examined and, if nece
ssary, cleaned up. The cache cleanup parameter, PlsqlCacheCleanupTime is specified in the cache.conf file.
The frequency can be set to daily, weekly, or monthly. When specifying weekly cleanup, it is possible to specify the day of the week
and the time of the day.
The default mod_plsql setting of PlsqlCacheCleanupTime is daily at 11PM local time. Therefore, by default, every night at 11PM, the cleanup routine runs. When you select the monthly freq
uency, the cleanup occurs on the first Saturday of each month.
Configuring this parameter c orrectly is important since cleaning up too often can result in a lower cache hit ratio and when cleaning does not occur often enough , the cache's disk usage may be excessive.
Monitor the cleanup activities using the entries
in the mod_plsql error_log; then tune the cleanup parameter, PlsqlCacheCleanupTime by analyzing the entrie
s.
[info] mod_plsql: cachecleanup deleted=2571 max_age=96,2178852b kept=1042,25585368b ti me=128s limit=25600000b
Note the following:
To improve PL/SQL performance i n Oracle HTTP Server, you need to tune the Oracle HTTP Server directives appropriately for your configuration.