|
Oracle® Application Server Web Cache Administrator's Guide
10g Release 2 (10.1.2) B14046-05 |
|
 Previous |
 Next |
|
Oracle® Application Server Web Cache Administrator's Guide
10g Release 2 (10.1.2) B14046-05 |
|
|
Previous |
Next |
This chapter describes the main tasks to begin caching content with OracleAS Web Cache.
This chapter contains these topics:
OracleAS Web Cache is installed with several default settings that you can either use or modify. Table 8-1 describes the main default configuration settings and where in the Oracle Enterprise Manager 10g Application Server Control Console and OracleAS Web Cache Manager interfaces you can change the values.
Table 8-1 OracleAS Web Cache Default Settings
| Configuration Settings | Default Value | Location to Change Value in Oracle Enterprise Manager 10g Application Server Control Console and OracleAS Web Cache Manager |
|---|---|---|
|
Security |
|
|
|
Password for the |
Password entered for the administrator username during installation |
Application Server Control Console: Web Cache Home page > Administration tab > Properties > Web Cache > Security OracleAS Web Cache Manager: Properties > Security |
|
Password for the |
Password entered for the administrator username during installation. |
Application Server Control Console: Web Cache Home page > Administration tab > Properties > Web Cache > Security OracleAS Web Cache Manager: Properties > Security |
|
Process identity for OracleAS Web Cache (UNIX only) |
User and group ID of user that installed OracleAS Web Cache |
Application Server Control Console: Web Cache Home page > Administration tab > Properties > Web Cache > Security OracleAS Web Cache Manager: Properties > Process Identity |
|
Auto-Restart |
Enabled/Disabled: Enabled Failover threshold: 3 Ping URL: Polling interval for polling: 15 seconds Ping timeout: 30 seconds |
Application Server Control Console: Web Cache Home page > Administration tab > Properties > Web Cache > Auto-Restart OracleAS Web Cache Manager: Properties > Auto-Restart |
|
Network Timeouts |
|
|
|
Keep-Alive timeouts |
5 seconds |
Application Server Control Console: Web Cache Home page > Administration tab > Properties > Web Cache > Resource Limits and Timeouts OracleAS Web Cache Manager: Properties > Network Timeouts |
|
Origin server timeout |
3600 seconds |
Application Server Control Console: Web Cache Home page > Administration tab > Properties > Web Cache > Resource Limits and Timeouts OracleAS Web Cache Manager: Properties > Network Timeouts |
|
Resource Limits |
|
|
|
Maximum cache size |
500 MB |
Application Server Control Console: Web Cache Home page > Administration tab > Properties > Web Cache > Resource Limits and Timeouts OracleAS Web Cache Manager: Properties > Resource Limits |
|
Maximum incoming connections |
700 |
Application Server Control Console: Web Cache Home page > Administration tab > Properties > Web Cache > Resource Limits and Timeouts OracleAS Web Cache Manager: Properties > Resource Limits |
|
Maximum size of single cached object |
100 KB |
Application Server Control Console: Web Cache Home page > Administration tab > Properties > Web Cache > Resource Limits and Timeouts OracleAS Web Cache Manager: Properties > Resource Limits |
|
Logging and Diagnostics |
|
|
|
Event logs |
|
Application Server Control Console: Web Cache Home page > Administration tab > Properties > Web Cache > Logging OracleAS Web Cache Manager: Logging and Diagnostics > Event Logs |
|
Access logs |
|
Application Server Control Console: Web Cache Home page > Administration tab > Properties > Web Cache > Logging OracleAS Web Cache Manager: Logging and Diagnostics > Access Logs |
|
Ports |
|
|
|
OracleAS Web Cache |
Application Server Control Console: Web Cache Home page > Administration tab > Properties > Web Cache > Ports OracleAS Web Cache Manager: Ports > Ports |
|
|
Administration |
Application Server Control Console: Web Cache Home page > Administration tab > Properties > Web Cache > Ports OracleAS Web Cache Manager: Ports > Operations Ports |
|
|
Invalidation |
Application Server Control Console: Web Cache Home page > Administration tab > Properties > Web Cache > Ports OracleAS Web Cache Manager: Ports > Operations Ports |
|
|
Statistics |
Application Server Control Console: Web Cache Home page > Administration tab > Properties > Web Cache > Ports OracleAS Web Cache Manager: Ports > Operations Ports |
|
|
Origin Servers, Sites, and Load Balancing |
|
|
|
Oracle HTTP Server listening ports |
HTTP: 7778 (for the first installation) |
Application Server Control Console: Web Cache Home page > Administration tab > Properties > Application > Origin Servers OracleAS Web Cache Manager: Origin Servers, Sites, and Load Balancing > Origin Servers |
|
Load balancing and failover settings |
Capacity: 100 Failover threshold: 5 Ping URL: Polling interval for polling: 10 seconds |
Application Server Control Console: Web Cache Home page > Administration tab > Properties > Application > Origin Servers OracleAS Web Cache Manager: Origin Servers, Sites, and Load Balancing > Origin Servers |
|
Site definitions |
A default site definition is established for the Oracle HTTP Server when Oracle Application Server is installed
|
Application Server Control Console: Web Cache Home page > Administration tab > Properties > Application > Sites OracleAS Web Cache Manager: Origin Servers, Sites, and Load Balancing > Site Definitions |
|
Site-to-server mappings |
|
Application Server Control Console: Web Cache Home page > Administration tab > Properties > Application > Sites OracleAS Web Cache Manager: Origin Servers, Sites, and Load Balancing > Site-to-Server Mappings |
|
Error Pages |
|
Application Server Control Console: Web Cache Home page > Administration tab > Properties > Application > Sites > Default Error Pages OracleAS Web Cache Manager: Origin Servers, Sites, and Load Balancing > Error Pages |
|
Rules for Caching, Personalization, and Compression |
|
|
|
Caching rules |
Application Server Control Console: Web Cache Home page > Administration tab > Properties > Application > Rules OracleAS Web Cache Manager: Rules for Caching, Personalization, and Compression > Caching, Personalization, and Compression |
|
|
Expiration policies |
|
Application Server Control Console: Web Cache Home page > Administration tab > Properties > Application > Rules > Expiration Policies OracleAS Web Cache Manager: Rules for Caching, Personalization, and Compression > Expiration Policy Definitions |
|
Session definitions |
Predefined site-specific session identifiers commonly used by components of Oracle Application Server:
The predefined global session identifier is:
|
Application Server Control Console: Web Cache Home page > Administration tab > Properties > Application > Sessions OracleAS Web Cache Manager: Rules for Caching, Personalization, and Compression > Session Definitions |
To set up OracleAS Web Cache, perform the following tasks:
Task 6: Configure OracleAS Web Cache with Listening Ports for Client Requests
Task 9: Configure Origin Server, Load Balancing, and Failover Settings
To start OracleAS Web Cache to begin the initial configuration:
If not currently logged on to the OracleAS Web Cache computer, log in with the user ID of the user that performed the installation.
Start both the admin and cache server processes:
Use opmnctl or webcachectl (for standalone installations) to start the processes:
opmnctl startproc ias-component=WebCache
webcachectl start
|
See Also: Chapter 7 for further information about starting and stopping the OracleAS Web Cache processes |
When OracleAS Web Cache is installed, it is set up with passwords for administration and invalidation requests. In addition, the computer on which you installed OracleAS Web Cache is the default trusted host.
To change the security settings in Application Server Control Console, navigate to Web Cache Home page > Administration tab > Properties > Web Cache > Security.
|
See Also: "Modifying General Security Settings" in Enterprise Manager Online Help for instructions |
To change the security settings in OracleAS Web Cache Manager:
Change the password for the OracleAS Web Cache usernames, administrator and invalidator.
You can perform configuration and operational tasks with either the Application Server Control Console administrator, ias_admin, or the OracleAS Web Cache administrator, administrator, accounts. Before you begin configuration, change the default administrator password to a secure password.
You can send invalidation requests with the invalidator username.
By default, the passwords for these users is the password you supplied during installation for the administrator username. In a cache cluster, the password for all cluster members must be the same.
In the navigator frame, select Properties > Security.
Under Administration User, click Change Administration Password or Change Invalidation Password under the Invalidation User.
When prompted, enter the old password in the Old Password field and a new password, in the New Password and Confirm New Password fields.
Click Submit.
|
See Also: "Classes of Users and Their Privileges" for further information about the administrator role |
The passwords for the administrator and invalidator users have these restrictions:
Passwords must be between 5 and 30 characters.
At least one of the characters must be a number.
Passwords can contain only alphanumeric and underscore (_) characters.
Passwords must begin with an alphabetic character. Passwords cannot begin with a number, the underscore (_), the dollar sign ($), or the number sign (#).
Passwords cannot be Oracle reserved words. The Oracle Database SQL Reference lists the reserved words. You can find this guide on Oracle Technology Network: http://www.oracle.com/technology/documentation/index.html
|
See Also:
|
Optionally, change the trusted subnet or trusted host from which administration, invalidation, and statistics monitoring requests can take place.
By default, the computer on which you installed OracleAS Web Cache is the trusted host.
In the Security page, click Change Trusted Subnets under the Current Trusted Subnets.
The Change Trusted Subnets dialog box appears.
Select one of the following options:
All subnets: Allows requests from all computers in all the subnets in the network.
This machine only: Allows requests from only this computer.
Enter list of IP addresses: Allows requests from all IP addresses you enter in a comma-delimited list. You can enter IP addresses in one of the following formats:
Complete IP address in dot notation, including the network number, subnet address, and unique host number
Example: 10.1.2.3
Network/netmask pair for subnet restriction through masking
Example: 10.1.0.0/255.255.0.0 allows all the hosts in the 10.1 subnet access.
Network/nnn Classless Inter-Domain Routing (CIDR) specification to require nnn bits from high end to match
Example: 10.1.0.0/16 allows all the hosts in the 10.1 subnet access. This example is similar to the network/netmask example, except the netmask consists of nnn high-order 1 bits.
|
Note: Sometimes requests come through a proxy server. If the proxy server is not covered by the trusted subnet settings, the requests will fail. |
Click Submit.
Optionally, change the user ID and group ID for the OracleAS Web Cache processes on UNIX.
By default, the user that performed the installation is the owner of OracleAS Web Cache processes. This user can execute opmnctl commands. Users that belong to the same group ID of the user that performed installation can also execute opmnctl commands.
If the current opmnctl user does not match the configured user in the Process Identity page, the OracleAS Web Cache webcached executable must run as root. If the webcached executable is not able to run as root, error events are reported to the event log file, and OracleAS Web Cache fails to start.
|
See Also: "Running webcached with Root Privilege" for instructions on changing thewebcached executable to run as root
|
To change the user ID and group ID for the OracleAS Web Cache processes on UNIX:
In the navigator frame, select Properties > Process Identity.
The Process Identity page appears.
Select the cache for which you want to modify settings, and then click Change IDs.
The Change Process Identity dialog box appears.
Enter the new user in the User ID field and the group ID of the user in the Group ID field.
Click Submit.
Use the webcache_setuser.sh script as follows to change file and directory ownership:
webcache_setuser.sh setidentity <user_ID>
where <user_ID> is the user you specified in the User ID field of the Process Identity page.
The setidentity command changes the ownership of the following files and directories to the new user ID:
$ORACLE_HOME/webcache
$ORACLE_HOME/webcache/internal.xml
$ORACLE_HOME/webcache/webcache.xml
$ORACLE_HOME/webcache/webcache.xml.bak
$ORACLE_HOME/webcache/.webcache_tmp.xml.tmp
$ORACLE_HOME/webcache/logs/event_log_files
$ORACLE_HOME/webcache/logs/access_log_files
|
See Also: "Script for Setting File Permissions on UNIX" for further information about thewebcache_setuser.sh script
|
If you change the administrator password or the trusted subnets in the Security page or any of the settings in the Process Identity page, then, after applying changes, restart both the cache server process and admin server process with the Oracle Process Manager and Notification (OPMN) Server utility command opmnctl restartproc ias-component=WebCache or the webcachectl utility command webcachectl restart (for standalone installations). You cannot use the Restart option in the Cache Operations page to restart the admin server process. Until the admin server process is restarted, you cannot submit invalidation requests from the Basic Content Invalidation or Advanced Content Invalidation pages.
|
See Also: "Task 12: Restart OracleAS Web Cache" for instructions on applying changes and restarting with command-line tools |
OracleAS Web Cache provides an auto-restart mechanism that checks that the cache server process is running and automatically restarts the cache server process if it is not running.
If auto-restart is enabled, the auto-restart mechanism restarts the cache server if it stops. By default, auto-restart is enabled.
|
Note: If you installed OracleAS Web Cache as part of an Oracle Application Server installation, the auto-restart mechanism is run by Oracle Process Manager and Notification (OPMN) Server. If you installed OracleAS Web Cache from a kit that included only this product, the auto-restart mechanism is run by the OracleAS Web Cache monitor. |
To change the auto-restart settings in Application Server Control Console, navigate to Web Cache Home page > Administration tab > Properties > Web Cache > Auto-Restart.
|
See Also: "Modifying Auto-Restart Settings" in Enterprise Manager Online Help for instructions |
To specify the settings for auto-restart in OracleAS Web Cache Manager:
To change the default settings, click Edit.
The Edit Auto-Restart dialog box is displayed.
If auto-restart is not enabled, in the Enabled field, select Yes.
You can specify that the auto-restart mechanism polls (pings) the OracleAS Web Cache cache server at specified intervals. It does this by sending requests to a specified URL. If it cannot connect to the cache server or if the cache server does not respond within a specified time, the auto-restart mechanism restarts the cache server process.
Note that the auto-restart mechanism will restart the cache server if it has failed, whether or not you enable pinging. However, if you enable pinging, the auto-restart mechanism will attempt to restart the cache if it receives network errors in response to its ping attempts.
If you do not want the auto-start mechanism to actively ping the cache server, disable pinging by selecting No in the Pinging Enabled field.
To enable pinging:
In the Pinging Enabled field, select Yes.
In the Failover Threshold field, enter the number of consecutive failed requests before the auto-restart mechanism considers the cache server to have failed. Only network errors, including timeout errors, are counted as failed requests.
The default is three failures.
For each failed request, OracleAS Web Cache increments the failure counter. When a request is successfully processed by the cache server, OracleAS Web Cache resets the failure counter.
When the failover threshold is met, the auto-restart mechanism starts the cache server.
|
Note: The threshold applies only to network errors and timeouts. If thecache server process is not running, the auto-restart mechanism immediately restarts the cache server.
|
In the Ping URL field, enter the URL that the auto-restart mechanism will use to poll the cache server.
You must use a URL that is cacheable and is guaranteed to be stored in the cache. The default is /_oracle_http_server_webcache_static_.html, which is stored in the cache. If your environment uses a hardware load balancer with pinging capability, then configure the load balancer with this ping URL to ping each OracleAS Web Cache server on a periodic basis.
In the Ping Interval field, enter the time, in seconds, between attempts by the auto-restart mechanism to poll the cache server.
The default value is 15 seconds.
In the Ping Timeout field, enter the time, in seconds, that the auto-restart mechanism will wait for a response from the cache server.
The default value is 30 seconds.
Click Submit.
After OracleAS Web Cache sends a response to a client, the connection is left open for five seconds, which is typically enough time for the client to process the response from OracleAS Web Cache. If the network between the client and OracleAS Web Cache is slow, consider increasing the timeout. Likewise, there is a 3600 second network timeout between OracleAS Web Cache and the origin server. If the origin server is unable to generate a response within that time, OracleAS Web Cache drops the connection and sends a network error page to the client. If applications require a shorter timeout, adjust the timeout.
To modify the default network timeouts from the Application Server Control Console, navigate to Web Cache Home page > Administration tab > Properties > Web Cache > Resource Limits and Timeouts.
|
See Also: "Configuring Network Timeouts" in Enterprise Manager Online Help for instructions |
To modify the default network timeouts from OracleAS Web Cache Manager:
In the navigator frame, select Properties > Network Timeouts.
In the Network Timeouts page, select the cache, and then click Edit.
The Edit Network Timeouts dialog box appears.
In the Keep-Alive Timeout field, enter the time, in seconds, for OracleAS Web Cache to keep a connection open to the client after it has returned a response.
If the timeout is set to 0, the connection to the client is not kept open. In addition, OracleAS Web Cache sends the following response-header field in the response:
Connection: Close
In the Origin Server Timeout field, enter the time, in seconds, for the origin server to generate a response to OracleAS Web Cache. If the origin server is unable to generate a response within that time, OracleAS Web Cache drops the connection and sends a network error page to the client.
Click Submit.
|
See Also:
|
To set resource limits for OracleAS Web Cache, configure the following attributes:
When the maximum cache memory limit is reached, OracleAS Web Cache performs garbage collection. During garbage collection, OracleAS Web Cache removes stale objects based on popularity and validity. In a cache cluster environment, OracleAS Web Cache removes on-demand objects before it removes owned objects.
|
See Also: "Performance Assurance Heuristics" for further information on how OracleAS Web Cache determines when to serve stale content |
To avoid swapping objects in and out of the cache, it is crucial to configure enough memory for the cache. Generally, the amount of memory (maximum cache size) for OracleAS Web Cache should be set to at least 256 MB.
To be more precise in determining the maximum amount of memory required, you can perform the following steps:
Determine which objects you want to cache, how many are smaller than 2 KB and how many are larger than 2 KB. Determine the average size of the objects that are larger than 2 KB. Determine the expected peak load—the maximum number of objects to be processed concurrently.
One way to do this is to look at existing Web server logs for one day to see which objects are popular. From the list of URLs in the log, decide which ones you want to cache. Retrieve the objects and get the size of each object.
Calculate the amount of memory needed. The way you calculate it may differ depending on the version of OracleAS Web Cache.
The amount of memory that OracleAS Web Cache uses to store an object depends on whether the object is larger or smaller than 2 kilobytes (KB):
If an object is smaller than 2 KB, OracleAS Web Cache uses a buffer of 2 KB to store the HTTP body.
If an object is 2 KB or larger, OracleAS Web Cache uses buffers of 8 KB to store the HTTP body. For example, if an object is 42 KB, OracleAS Web Cache uses six 8 KB buffers to store the HTTP body.
Regardless of the size of the body, OracleAS Web Cache uses 8 KB to store the HTTP response header.
Use the following formula to determine an estimate of the maximum memory needed:
(X * (2KB + 8KB)) + (Y * (([m/8] * 8KB) + 8KB)) + basemem
In the formula:
X is the number of objects smaller than 2 KB.
2KB is size of the buffer for the HTTP body for objects smaller than 2 KB.
8KB is the size of the buffer for the HTTP response header.
Y is number of objects that are 2 KB or larger.
[m/8] is the ceiling of m (the average size, in kilobytes, of objects 2 KB or larger) divided by 8. A ceiling is the closest integer that is greater than or equal to the number.
8KB is size of the buffer for the HTTP body for objects that are 2 KB or larger.
8KB is the size of the buffer for the HTTP response header.
basemem is the base amount of memory needed by OracleAS Web Cache to process requests. This amount includes memory for internal functions such as lookup keys and timestamps. The amount needed depends on the number of concurrent requests and on whether or not the requests include Edge Side Includes (ESI).
For non-ESI requests, each concurrent request needs approximately 32 KB of memory. For example, to support 1000 concurrent requests, you need about 32 MB of memory.
For ESI requests, each concurrent request needs roughly the following amount of memory:
32KB + (number of ESI fragments * [8KB to 16KB])
Because objects with more ESI fragments require more metadata for each fragment, use the higher number (16) for objects with 10 or more fragments. For example, for an object with 10 ESI fragments, use the following calculation:
32KB + (10 * [16KB]) = 192KB
That is, you need about 192 KB of memory for one 10-fragment object. To support 1000 concurrent requests, you need roughly 192 MB of memory.
For example, assume that you want to cache 5000 objects that are smaller than 2 KB and 2000 objects that are 2 KB or larger and that the larger objects have an average size of 54 KB. The objects do not use ESI. You expect to process 500 objects concurrently. Use the formula to compute the maximum memory:
(5000 * (2KB + 8KB)) + (2000 * (([54/8] * 8KB) + 8KB)) + (500 * 32KB)
Using the formula, you need:
50,000 KB for the smaller objects.
128,000 KB for the larger objects. For the HTTP body, you need 56 KB (seven 8 KB buffers) for each object, given the average size of 54 KB. For the HTTP response header, you need 8 KB for each object.
Approximately 16,000 KB for the base amount of memory needed to process 500 concurrent requests.
This results in an estimate of 194,000 KB of memory needed.
|
Note: Even though you specify that certain objects should be cached, not all of the objects are cached at the same time. Only those objects that have been requested and are valid are stored in the cache. As a result, only a certain percentage of your objects are stored in the cache at any given time. That means that you may not need the maximum memory derived from the preceding formula. |
Configure OracleAS Web Cache, specify the maximum cache size from the Resource Limits and Timeouts page of Application Server Control Console (Web Cache Home page > Administration tab > Properties > Web Cache > Resource Limits and Timeouts) or the Resource Limits page of OracleAS Web Cache Manager (Properties > Resource Limits).
After applying changes and restarting OracleAS Web Cache, as described in "Task 12: Restart OracleAS Web Cache", use a simulated load or an actual load to monitor the cache to see how much memory it really uses in practice.
Remember that the cache is empty when OracleAS Web Cache starts. For monitoring to be valid, ensure that the cache is fully populated. That is, ensure that the cache has received enough requests so that a representative number of objects are cached.
The Web Cache Statistics page of OracleAS Web Cache Manager (Monitoring > Web Cache Statistics) provides information about the current memory use and the maximum memory use. Note the following metrics in the Cache Overview table:
Size of Objects in Cache shows the current logical size of the cache. The logical size of the cache is the size of the valid objects in the cache. For example, if the cache contains two objects, one 3 KB and one 50 KB, the Size of Objects in Cache is 53 KB, the total of the two sizes. This metric does not show the physical size of the cache.
Configured Maximum Cache Size indicates the maximum cache size as specified in the Resource Limits page.
Current Allocated Memory displays the physical size of the cache. The physical size of the cache is the amount of data memory allocated by OracleAS Web Cache for cache storage and operation. This number is always smaller than the process size shown by operating system statistics because the OracleAS Web Cache process, like any user process, consumes memory in other ways, such as instruction storage, stack data, thread, and library data.
Current Action Limit is 95 percent of the Configured Maximum Cache Size. This number is usually larger than the Current Allocated Memory.
If Current Allocated Memory is greater than Current Action Limit, OracleAS Web Cache begins garbage collection to obtain space for new HTTP responses without exceeding the maximum cache size.
If the Current Allocated Memory is close to or greater than the Current Action Limit, increase the maximum cache size to avoid swapping objects in and out of the cache. Use the Resource Limits and Timeouts page of Application Server Control Console (Web Cache Home page > Administration tab > Properties > Web Cache > Resource Limits and Timeouts) or the Resource Limits page of OracleAS Web Cache Manager (Properties > Resource Limits) to increase the maximum cache size.
In addition to the cache size, it is important to specify a reasonable number for the maximum connection limit for the OracleAS Web Cache server. If you set a number that is too high, performance can be affected, resulting in slower response time. If you set a number that is too low, fewer requests will be served. You must strike a balance between response time and the number of requests processed concurrently.
To help determine a reasonable number, consider the following factors:
The maximum number of clients you intend to serve concurrently at any given time.
The average size of a page and the average number of requests for page.
Network bandwidth. The amount of data that can be transferred at any one time is limited by the network bandwidth.
The percentage of cache misses. If a large percentage of requests are cache misses, the requests are forwarded to the application Web server. Those requests consume additional network bandwidth and result in longer response times.
How quickly a page is processed. Use a network monitoring utility, such as ttcp, to determine how quickly your system processes a page.
The cache cluster member capacity, if you have a cache cluster environment. The capacity reflects the number of incoming connections from other cache cluster members. You set the cluster member capacity from the Cluster Members and Properties page of Application Server Control Console (Web Cache Home page > Administration tab > Cluster Properties > Members and Properties) or the Clustering page of OracleAS Web Cache Manager (Properties > Clustering).
Use various tools, such as those available with the operating system and with OracleAS Web Cache, to help you determine the maximum number of connections. For example, the netstat -a command on UNIX and Windows operating systems enables you to determine the number of established connections; the ttcp utility enables you to determine how fast a page is processed. OracleAS Web Cache Manager provides statistics on hits and misses.
You set the maximum number of incoming connections from the Resource Limits and Timeouts page of Application Server Control Console (Web Cache Home page > Administration tab > Properties > Web Cache > Resource Limits and Timeouts) or the Resource Limits page of OracleAS Web Cache Manager (Properties > Resource Limits).
Do not set the value to an arbitrarily high value, because OracleAS Web Cache sets aside some resources for each connection, which could adversely affect performance. For many UNIX systems, 5000 connections is usually a reasonable number.
On most UNIX platforms, each client connection requires a separate file descriptor. OracleAS Web Cache tries to reserve the maximum number of file descriptors (Max_File_Desc) when it starts. If the OracleAS Web Cache webcached executable is run as root, you can increase this number. For example, on Sun Solaris, you can increase the maximum number of file descriptors by setting the rlim_fd_max parameter. If the webcached executable is not run with the root privilege, OracleAS Web Cache fails to start.
|
See Also:
|
OracleAS Web Cache uses the following formula to calculate the maximum number of file descriptors to be used:
Max_File_Desc = Curr_Max_Conn + Total_WS_Capacity + Outgoing_Cluster_Conn + 100
In the formula:
Max_File_Desc is the maximum number of file descriptors to be used.
Curr_Max_Conn is the current maximum incoming connections limit for OracleAS Web Cache. You set the maximum number of incoming connections from the Resource Limits and Timeouts page of Application Server Control Console (Web Cache Home page > Administration tab > Properties > Web Cache > Resource Limits and Timeouts) or the Resource Limits page of OracleAS Web Cache Manager (Properties > Resource Limits).
In a cache cluster environment, Curr_Max_Conn also includes the cluster member capacity, which is the incoming connections from peer caches. You set the capacity from the Cluster Members and Properties page of Application Server Control Console (Web Cache Home page > Administration tab > Cluster Properties > Members and Properties) or the Clustering page of OracleAS Web Cache Manager (Properties > Clustering).
Total_WS_Capacity is the sum of the capacity for all configured application Web servers. You set the capacity from the Origin Servers page of Application Server Control Console (Web Cache Home page > Administration tab > Properties > Application > Origin Servers) OracleAS Web Cache Manager (Origin Servers, Sites, and Load Balancing > Origin Servers).
In a cache cluster environment, the capacity is divided among the cache cluster members, using the following formula:
Total_WS_Capacity = Sum_Web_Server_Capacity / n
In the formula, Sum_Web_Server_Capacity is the sum capacity of all configured application Web servers, and n is the number of cache cluster members. For example, assume you have two configured application Web Servers. Web_Server_A has a capacity of 200 and Web_Server_B has a capacity of 250. Also, assume you have a cluster with three caches. The Total_WS_Capacity is 150, as the following example calculates:
Total_WS_Capacity = (200 + 250) / 3
Outgoing_Cluster_Conn is the total of outgoing connections to peer caches in a cache cluster. The value is zero if you do not have a cache cluster. To compute this value, use the following formula:
Outgoing_Cluster_Conn = Sum_Cluster_Capacity / (n-1)
In the formula, Sum_Cluster_Capacity is the sum of the capacity of all other caches in a cluster, and n is the number of cache cluster members. For example, assume you have cluster with three caches. Cache_A has a capacity of 100, Cache_B has a capacity of 150, and Cache_C has a capacity of 200. The Outgoing_Cluster_Conn for Cache_A, is 175, as the following example calculates:
Outgoing_Cluster_Conn = (150 + 200) / (3-1)
You set the capacity of caches in a cluster from the Cluster Members and Properties page of Application Server Control Console (Web Cache Home page > Administration tab > Cluster Properties > Members and Properties) or the Clustering page of OracleAS Web Cache Manager (Properties > Clustering).
100 is the number of connections reserved for internal use by OracleAS Web Cache.
|
See Also:
|
On Windows operating systems, the number of file handles as well as socket handles is limited only by available kernel resources, more precisely, by the size of paged and non-paged pools. However, the number of active TCP/IP connections is restricted by the number of TCP ports the system can open.
The default maximum number of TCP ports is set to 5000 by the operating system. Of those, 1024 are reserved by the kernel. You can modify the maximum number of ports by editing the Windows registry. Windows operating systems allow up to 65536 ports.
To change the default, you must add a new value to the following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Add a new value, specifying the following:
Value Name: MaxUserPort
Data Type: REG_DWORD
Data: An integer less than 65536 - 1024
The total of the maximum number of incoming connections and cluster member capacity should not be set to a number greater than the number of TCP ports minus 1024. You set the maximum number of incoming connections from the Resource Limits and Timeouts page of Application Server Control Console (Web Cache Home page > Administration tab > Properties > Web Cache > Resource Limits and Timeouts) or the Resource Limits page of OracleAS Web Cache Manager (Properties > Resource Limits). You set the cluster member capacity from the Cluster Members and Properties page of Application Server Control Console (Web Cache Home page > Administration tab > Cluster Properties > Members and Properties) or the Clustering page of OracleAS Web Cache Manager (Properties > Clustering).
On Windows operating systems, OracleAS Web Cache does not attempt to reserve file handles or to check that the number of current maximum incoming connections is less than the number of TCP ports.
To conserve system resources, you can limit the size of objects that are cached, even if the objects meet other caching rules.
If you specify a maximum cached object size, only objects that are not larger than a specified size and that match the caching rules will be stored in the cache. Objects larger than the specified size will not be cached, even if they meet other caching rules. The default is 100 KB for 10g (9.0.4) and 10g Release 2 (10.1.2) installations. For upgraded caches, the default is that no limit is specified.
If you have objects that are larger than the maximum cached object size and those objects are requested frequently, consider increasing the limit. When you specify a value of 0, no objects will be cached.
If you want to apply the default to upgraded caches or change the limit, then modify the entry for the Maximum Size of Single Cache Object from the Resource Limits and Timeouts page of Application Server Control Console (Web Cache Home page > Administration tab > Properties > Web Cache > Resource Limits and Timeouts) or the entry for Maximum Cached Object Size in the Resource Limits page of OracleAS Web Cache Manager (Properties > Resource Limits).
By default, OracleAS Web Cache listens with the HTTP protocol on port 7777 on UNIX and port 80 on Windows. If this port is in use, the installation procedure attempts to assign another port number from a range of 7777 to 7877.
You can add ports, if necessary. For example, it may be necessary to add an additional listening port if you want to assign OracleAS Web Cache a port that an origin server was previously listening on.
You can add a port and specify the HTTPS protocol to accept HTTPS client requests on that port.
|
See Also: Oracle Application Server Administrator's Guide for information about updating the port numbers for other Oracle Application Server components |
This section contains the following topics:
To specify a listening port from Application Server Control Console, navigate to Web Cache Home page > Administration tab > Properties > Web Cache > Ports.
|
See Also: "Configuring Listen Ports" in Enterprise Manager Online Help for instructions |
To specify a listening port from OracleAS Web Cache Manager:
In the navigator frame, select Ports > Listen Ports.
In the Listen Ports page, click Add.
The Edit/Add Listen Ports dialog box appears.
From the list, select the cache for which you want to modify settings.
In the IP Address field, specify the computer running OracleAS Web Cache:
IP address written in a 32-bit dotted decimal notation
A host name that resolves to an IP address of the computer running OracleAS Web Cache. If you do not want to rely on Domain Name System (DNS) to resolve the host name, use a different name resolution mechanism, such as the UNIX etc/hosts file.
ANY to represent any IP address
In the Port Number field, enter the listening port from which OracleAS Web Cache will receive client requests for the Web site.
Ensure that this port number is not already in use.
Port numbers less than 1024 are reserved for use by privileged processes on UNIX. If you want to configure OracleAS Web Cache to listen on a port less than 1024, such as on port 80, run the OracleAS Web Cache webcached executable with the root privilege. If the webcached executable is not run as root, OracleAS Web Cache fails to start.
|
See Also:
|
From the Protocol list, select either HTTP to accept HTTP client requests on the port or HTTPS to accept HTTPS client requests on the port.
If you selected HTTPS as the listening protocol, you must configure additional information, including the location of the wallet:
|
See:
|
Click Submit.
In a configuration in which the OracleAS Web Cache listening port is the same as the logical site port, changing the OracleAS Web Cache listening port also requires you to change the logical site port in the Sites page of Application Server Control Console (Web Cache Home page > Administration tab > Properties > Application > Sites) or the Site Definitions and Site-to-Server Mapping pages of OracleAS Web Cache Manager (Origin Servers, Sites, and Load Balancing > Site-to-Server Mapping).
When you change the OracleAS Web Cache listening port, you must also perform additional configuration for other Oracle Application Server components.
When you change the OracleAS Web Cache listen port, you must also perform additional configuration for other Oracle Application Server components.
|
See Also: Section "Changing the OracleAS Web Cache Listen Port" in the Oracle Application Server Administrator's Guide for additional tasks required for other Oracle Application Server components |
At installation time, Oracle HTTP Server sets the httpd.conf file with the following directives that impact OracleAS Web Cache:
Port=web_cache_port specifies the OracleAS Web Cache listening ports, enabling dynamically created URLs to be redirected to OracleAS Web Cache.
Listen=Oracle_HTTP_Server_port specifies the HTTP port obtained by Oracle HTTP Server.
ServerName specifies the host name of Oracle HTTP Server.
UseCanonicalName On instructs Oracle HTTP Server to use the host names and port values set in the ServerName and Port directives when redirecting a URL.
For example:
##
## httpd.conf -- Apache HTTP server configuration file
##
...
Port 7777
Listen 7778
...
ServerName http_server_name
...
UseCanonicalName On
....
If you decide to disable OracleAS Web Cache, then the Oracle HTTP Server administrator must modify the value of the Port directive to the same value set for the Listen directive. For example:
## ## httpd.conf -- Apache HTTP server configuration file ## ... Port 7778 Listen 7778 ... ServerName http_server_name ... UseCanonicalName On ....
If OracleAS Web Cache is deployed on a separate computer from the Oracle HTTP Server, then the Oracle HTTP Server administrator must create a <VirtualHost> container directive in httpd.conf for each site hosted by OracleAS Web Cache. This configuration enables Oracle HTTP Server to redirect URLs to OracleAS Web Cache. The following example shows httpd.conf modified to direct requests for www.1st.company.com and www.2nd.company.com to OracleAS Web Cache, which is listening on port 7777:
##
## httpd.conf -- Apache HTTP server configuration file
##
...
Port 7777
Listen 7778
...
ServerName http_server_name
...
UseCanonicalName On
...
<VirtualHost *:*>
ServerName www.1stcompany.com
Port 80
...
</VirtualHost>
<VirtualHost *:*>
ServerName www.2ndcompany.com
Port 80
...
</VirtualHost>
...
The httpd.conf file resides in $ORACLE_HOME/Apache/Apache/conf/httpd.conf on UNIX or ORACLE_HOME\Apache\Apache\conf\httpd.conf on Windows.
|
Note: If you modify the value ofServerName, you must also modify the default site information for OracleAS Web Cache. See "Default Site Example".
|
In addition to receiving HTTP and HTTPS client requests, OracleAS Web Cache also receives administration, invalidation, and statistics monitoring requests on specific HTTP or HTTPS listening ports:
http://web_cache_hostname:http_porthttps://web_cache_hostname:https_port
By default, OracleAS Web Cache listens with the HTTP protocol to receive these requests. The installation procedure assigns port numbers ranging from 9400 to 9499. Default HTTP port numbers are as follows:
9402 for statistics monitoring requests
|
Note:
|
This section contains the following topics:
Configuring Other Oracle Application Server Components with Operations Ports
Starting the admin Server Process After an Administration Port Change
Starting the cache Server Process After an Invalidation or Statistics Port Change
To modify the operations ports from Application Server Control Console, navigate to Web Cache Home page > Administration tab > Properties > Web Cache > Ports.
|
See Also: "Configuring Operations Ports" in Enterprise Manager Online Help for instructions |
To modify the operations ports from OracleAS Web Cache Manager:
In the navigator frame, select Ports > Operations Ports.
Select the cache for which to modify port and protocol settings.
In the Operations Ports page, click Edit.
The Edit Operations Port dialog box appears.
In the IP Address field, specify the computer running OracleAS Web Cache:
IP address written in a 32-bit dotted decimal notation
A host name that resolves to an IP address of the computer running OracleAS Web Cache. If you do not want to rely on Domain Name System (DNS) to resolve the host name, use a different name resolution mechanism, such as the UNIX etc/hosts file.
ANY to represent any IP address
In the Port Number field, enter the operation port.
Port numbers less than 1024 are reserved for use by privileged processes on UNIX. If you want to configure OracleAS Web Cache to listen on a port less than 1024, such as on port 80, run the OracleAS Web Cache webcached executable with the root privilege. If the webcached executable is not run as root, then error events are reported to the event log file, and the OracleAS Web Cache fails to start.
|
See Also:
|
From the Protocol list, select either HTTP or HTTPS to accept requests.
If you selected HTTPS as the listening protocol, you must configure additional information, including the location of the wallet.
Click Submit.
When you change the operations ports, you must also perform additional configuration for other Oracle Application Server components.
|
See Also: Oracle Application Server Administrator's Guide for additional tasks required for other Oracle Application Server components |
After making an Administration port property change, restart the admin server process before you use the OracleAS Web Cache Manager for additional configuration. Use the following OPMN utility command:
opmnctl restartproc ias-component=WebCache process-type=WebCacheAdmin
If you are running a standalone instance of OracleAS Web Cache, use the following webcachectl utility command:
webcachectl restartadm
You cannot use the Restart option in the Cache Operations page (Operations > Cache Operations) to restart the admin server process.
After making Invalidation or Statistics port property changes, restart the cache server process with the Restart option in the Cache Operations page. Until the cache server process is restarted after an Invalidation port change, you receive the following error when you submit invalidation requests from the Basic Content Invalidation or Advanced Content Invalidation pages (Operations > Basic Content Invalidation or Advanced Content Invalidation):
Internal error: can't connect to OracleAS Web Cache Invalidation Listening Port
Likewise, after a Statistics port change, the Cache Operations page does not display the current Uptime and Operation Needed information for the cache. In addition, the Monitoring pages (Web Cache Statistics, Health Monitor, Origin Server Statistics, and Popular Requests) report the following error.
Failure obtaining statistics from Web Cache cache server: error in connect.Please check that the cache server is up and running.
|
See Also: "Task 12: Restart OracleAS Web Cache" for instructions on applying changes and restarting the processes with command-line tools or OracleAS Web Cache Manager |
Configure OracleAS Web Cache with the application Web servers or proxy servers to which it sends cache misses. Typically, OracleAS Web Cache uses application Web servers for internal sites and proxy servers for external sites outside a firewall.
By default, the listening port and host name of the Oracle HTTP Server are configured. When OracleAS Web Cache is installed, Oracle HTTP Server has a default listening HTTP port of 7778 during the first installation sequence.
OracleAS Web Cache only forwards requests to a configured origin server if the server is mapped to a Web site. If you are configuring load balancing for a site, then create one site-to-server mapping that maps all the applicable origin servers to the site.
|
See Also:
|
To configure OracleAS Web Cache with origin server information from Application Server Control Console, navigate to Web Cache Home page > Administration tab > Properties > Application > Origin Servers.
|
See Also: "Configuring Origin Servers" in Enterprise Manager Online Help for instructions |
To configure OracleAS Web Cache with origin server information from OracleAS Web Cache Manager:
In the navigator frame, select Origin Servers, Sites, and Load Balancing > Origin Servers.
Click Add in the Application Web Servers or Proxy Servers section.
The Add Application Web Server or Proxy Server dialog box appears.
In the Hostname field, enter the host name of the origin server.
In the Port field, enter the listening port from which the origin server will receive OracleAS Web Cache requests.
|
Note: OracleAS Web Cache must listen on the same port as the application Web server being proxied. When configuring proxy servers, ensure there is a corresponding listening port for every port that will need to be proxied. |
In the Routing field, select ENABLED to permit OracleAS Web Cache to route requests to the origin server or DISABLED to only serve requests from cache.
Oracle recommends selecting DISABLED if temporary maintenance of an origin server is needed.
OracleAS Web Cache tries to route a request matching a particular site to all origin servers mapped to that site. If all of the origin servers have a routing of DISABLED, OracleAS Web Cache serves a network error page to clients.
In the Capacity field, enter the maximum number of concurrent connections that the origin server can accept.
You determine this number by load testing the origin server until it runs out of CPU, responds slowly, or until a backend database reaches full capacity.
In a cache cluster, OracleAS Web Cache ensures that the total number of connections from all cluster members to the origin server does not exceed the capacity. Each cluster member is allowed a percentage of the maximum connections, using the following formula:
connections_from_each_cluster_member = capacity / number_of_cluster_members
In the Failover Threshold field, enter the number of allowed continuous read/write failures with an origin server on established connections.
The default is five request/response failures.
If any connection failure occurs, OracleAS Web Cache immediately considers an origin server down.
When the threshold is met, OracleAS Web Cache considers the origin server down and performs automatic failover of the origin servers. If an origin server fails at any time after OracleAS Web Cache has started to send a request, then OracleAS Web Cache increments the failure counter. The failure counter is reset in the event of a successful server response. A request is considered failed if:
There are any network errors other than connection failure errors.
The HTTP response status code is less than 100, or is one of the following messages: 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable, or 504 Gateway Timeout.
After the threshold is met, OracleAS Web Cache considers the server down and uses other servers for future requests. OracleAS Web Cache starts polling the down server, by sending requests to the URL specified in the Ping URL field. When OracleAS Web Cache receives a successful response from the server without any network errors and the HTTP response code is not less than 100, or not equal to 500, 502, 503, 504, OracleAS Web Cache considers the server up again and uses it for future requests.
|
Note:
|
In the Ping URL field, enter the URL that OracleAS Web Cache will use to poll an origin server that has reached its failover threshold:
For an application Web Server, enter either a relative or a fully-qualified URL that includes the domain name, or site name, representing the virtual host of the application Web server.
For a proxy server, enter a fully-qualified URL that includes the domain name, or site name, representing the virtual host of the origin server behind the proxy server.
Rather than using a static URL, Oracle recommends using a URL that checks the health of the application logic on the origin server and returns the appropriate HTTP 200 or 500 status codes. The default is "/".
In the Ping Interval (seconds) field, enter the time, in seconds, that OracleAS Web Cache will poll an origin server that has reached its failover threshold.
From the Protocol list, select either HTTP to send HTTP requests on the port or HTTPS to send HTTPS requests on the port.
Click Submit.
If you selected HTTPS as the listening protocol, specify the location of the wallet for OracleAS Web Cache communication to the origin server (Origin Servers, Sites, and Load Balancing > Origin Server Wallet).
|
See Also: "Task 4: Configure HTTPS Port and Wallet Location for the Origin Server" for information about configuring the wallet |
For OracleAS Web Cache to act as a virtual server for one or more Web sites, configure OracleAS Web Cache with information about the Web site. To configure settings for a Web site, perform the following tasks:
The installation process creates a default site definition that uses the host name and listening port of the computer on which Oracle HTTP Server was installed. OracleAS Web Cache forwards requests without host information to this site.
You need to create site definition for any named sites. A site definition consists of a host name, port information, and optional URL path prefix about the site and its aliases. Alias information is essential, because many sites are represented by one or more aliases. OracleAS Web Cache recognizes and caches requests for a site and its aliases. For example, site www.company.com:80 may have an alias of company.com:80. By specifying this alias, OracleAS Web Cache caches the same content from either company.com:80 or www.company.com:80. If a request includes a site alias that is not configured, OracleAS Web Cache sends the request to the default site.
The following sections show examples of site definitions and explain how to configure new site definitions:
For those requests that do not include a Host request-header field, OracleAS Web Cache sends the request to the default site. The default site, established during installation, uses the host name and listening port of the computer on which Oracle HTTP Server was installed. Figure 8-1 shows an example of a default site definition from the Sites page of Application Server Control Console (Web Cache Home page > Administration tab > Properties > Application > Sites).
The rules for the default site are as follows:
The site definition in the Named Sites Definitions section maps HTTP requests to the origin server host-server:7778. If you select to edit this definition, you can view the ESI content policy from the Advanced tab. The ESI content policy is set to Unrestricted, which instructs OracleAS Web Cache to serve site content, as well as assemble ESI include fragments.
The first mapping *.80 in the Server Mapping for Unnamed Site uses a * wildcard host name to map all other virtual site names to the origin server. The ESI content policy is set to Exclude Fragments, which restricts OracleAS Web Cache from fetching ESI content from any sites other than the sites specified in the first rule.
The second mapping *.* in the Server Mapping for Unnamed Site uses a * wildcard host name to map all other virtual site names to the origin server and a * wildcard port number to map the site name to multiple port numbers. The ESI content policy is set to Exclude Fragments, which restricts OracleAS Web Cache from fetching ESI content from any sites other than the sites specified in the first two rules.
|
Note: If you modify the name of the default site, you must also modify theServerName directive in the httpd.conf file. See "Task 7: Provide Directives to Oracle HTTP Server".
|
Figure 8-2 shows how you would configure a virtual host site named www.company.com:80 without ESI content from the Sites page of Application Server Control Console (Web Cache Home page > Administration tab > Properties > Application > Sites).
The site definition in the Named Sites Definitions section maps HTTP requests to site www.company.com:80 and and site alias company.com:80 to origin server host-server:7778. The ESI content policy is set to Exclude Fragments, which restricts OracleAS Web Cache from fetching ESI content from host-server:7778 for this site.
Figure 8-2 Example: Site Settings for a Virtual Host Site
Figure 8-3 shows how you would configure a virtual host site named www.1st.company.com:80 and www.2nd.company.com with ESI content from the Sites page of Application Server Control Console (Web Cache Home page > Administration tab > Properties > Application > Sites).
The rules are as follows:
The site definitions in the Named Sites Definitions section map HTTP requests to sites www.1st.company.com:80 and www.2nd.company.com:80 and respective aliases 1st.company.com and 2nd.company.com to origin server host-server:7778. The ESI content policy is set to Unrestricted, which enables OracleAS Web Cache to serve site content, as well as assemble ESI include fragments.
The mapping www.*.company.com:80 in the Server Mapping for Unnamed Site uses a * wildcard host name to map sites matching www.*.company.com to origin server host-server:7778. The ESI content policy is set to Unrestricted.
Figure 8-3 Example: Site Settings for Multiple Virtual Host Sites
Figure 8-4 shows how you would configure ESI provider sites named www.providersite1.com:80 and www.providersite2.com from the Sites page of Application Server Control Console (Web Cache Home page > Administration tab > Properties > Application > Sites).
The site definitions in the Named Sites Definitions section specify how to map HTTP requests to sites www.providersite1.com:80 and www.providersite2.com:80 and respective aliases providersite1.com and providersite2.com. Requests to www.providersite1.com map to proxy-host:80. There is no origin server specified for www.providersite2.com, because the proxy server is not known. Instead, DNS will be used to resolve the site name to the appropriate server. The ESI content policy is set to Fragments Only, which restricts OracleAS Web Cache from using this mapping for any content that is not ESI.
Figure 8-4 Example: Site Settings for Multiple ESI Provider Sites
If the default site definition is not adequate for your configuration, create additional site definitions.
To create new site definitions from Application Server Control Console, navigate to Web Cache Home page > Administration tab > Properties > Application > Sites.
|
See Also: "Configuring Site Properties for a Named Site" or "Configuring Site Properties for an Unnamed Site" in Enterprise Manager Online Help for instructions |
Using OracleAS Web Cache Manager, you can either discover site and alias information from Oracle HTTP Server, or you can manually create definitions. Oracle recommends using the site discovery feature to initially create the necessary definitions. After discovery is complete, you can manually create additional site definitions. Application Server Control Console does not support site discovery.
To create new site definitions from OracleAS Web Cache Manager:
In the navigator frame, select Origin Servers, Sites, and Load Balancing > Site Definitions.
The Site Definitions page appears.
|
Note:
|
Specify the site information:
In the Site Definitions page, click Add Site.
The Add Site dialog box appears.
In the Host Name field, enter the site host name, for example, www.company.com. To enable OracleAS Web Cache to match requests to this site, do not add protocol information (http:// or https://) to the host name.
|
Note: Do not use the wildcard* in the Host Name field to represent multiple sites.
|
Optionally, in the URL Path Prefix field, enter the path prefix of the URLs to distinguish this site from another site that shares the same host name. Ensure the prefix starts with "/" to distinguish from another site that shares the same host name. Do not include the file name or embedded URL parameters in the prefix.
The prefix is excluded in matching requests to the site.
For example, the following URLs share the same site name, but belong to two entirely differently applications hosted on entirely different origin servers:
http://www.company.com/portal/page?_pageid=33,4232&_dad=portal
http://www.company.com/um/traffic_cop?mailid=inbox
While the first URL shows an email user a front page after login, the second URL displays an inbox. If the site host name is defined as www.company.com, then you specify the prefixes as /portal and /um to distinguish the sites. Requests are matched for www.company.com, not www.company.com/portal and www.company.com/um.
In the Port Number field, enter the port number from which the Web site is listening for incoming HTTP requests.
The port number should be the port used in client requests.
In a configuration in which the OracleAS Web Cache listen port is the same as the logical site port, changing the OracleAS Web Cache listen port requires you to also change the logical site port in both the Site Definitions and Site-to-Server Mapping pages.
In the HTTPS Only Prefix field, enter the URL prefix for which only HTTPS requests will be served. If you must restrict all traffic to HTTPS, enter "/ " for the entire site.
In the URL Parameter to Ignore field, specify site-specific embedded URL or POST body parameters to ignore.
By configuring OracleAS Web Cache to ignore the value of embedded URL or POST body parameters, you enable OracleAS Web Cache to serve one cached object to multiple sessions requesting the same page. OracleAS Web Cache caches the response to the first request and serves subsequent requests for the page from its cache.
If you prefer instead to set a global parameter to apply to all sites, click Global URL Parameters to Ignore from the main Site Definitions page.
|
See Also:
|
In the Client-Side Certificate field, select Required or Not Required to specify that OracleAS Web Cache require or not require client-side certificates from client browsers.
A client-side certificate is a method for verifying the identity of the client. It binds information about the client user to the user's public key and must be digitally signed by a trusted CA.
In the Default Site field, select Yes to specify the site as the default site, or select No to specify this site as a nondefault site.
If you select Yes for a site, another site that previously had the Yes setting will change to No.
If the default site includes a URL path prefix, the prefix is excluded in matching requests to the site. For example, if you specify a default site of www.company.com and a URL path prefix of /portal, requests are matched for www.company.com, not www.company.com/portal.
In the Create Alias from Site Name with/without www field, select either Yes or No.
Select Yes to use the site name as a site alias.
For example, if the site domain name is company.com, a site alias of www.company.com will be used. If the site domain name is www.company.com, a site alias of company.com will be used.
Select No if you do not want to use the site name as a site alias.
If the site uses additional aliases, map the site to those aliases.
|
Important: To ensure requests are directed to the correct site, specify all possible variations of the site name. If a request includes a site alias that is not configured, OracleAS Web Cache sends the request to the default site. |
In the Site Definitions page, select a site, and then click Add Alias.
The Add Alias for Site dialog box appears.
In the Host Name field, enter the site alias name, such as company.com.
|
Note: Do not use the wildcard* in the Host Name field to represent multiple aliases.
|
In the Port Number field, enter the HTTP or HTTPS port number from which the alias is listening for incoming HTTP requests.
The port number should be the port used in client requests.
Click Submit.
To map sites to origin servers from Application Server Control Console, navigate to Web Cache Home page > Administration tab > Properties > Application > Sites.
|
See Also: "Configuring Site Properties for a Named Site" in Enterprise Manager Online Help for instructions |
To map sites to origin servers from OracleAS Web Cache Manager, take the following steps:
In the navigator frame, select Origin Servers, Sites, and Load Balancing > Site-to-Server Mapping.
Click Create if no mappings exist. If mappings already exist, select a mapping, and then click Insert Above or Insert Below.
The Create Site-to-Server Mapping or Edit/Add Site-to-Server Mapping dialog box appears.
In the Edit Site Name section, select one of the following options:
Enter Site Name to enter the site name, such as www.company.com or *.company.com, as well as the HTTP or HTTPS port number from which the site is listening for incoming requests.
Select from Site definitions to select a site definition created in the Site Definitions page.
|
Note: You can use the wildcard* in the Host Name field in the following ways:
You can use the wildcard This option does not enable you to create a site definition. You must create a site definition in the Site Definitions page. |
In the Select either application Web servers or proxy servers to which this Site is mapped, select one of the following options:
Select Application Web Servers to select application Web servers specified in the Origin Servers page
Select Proxy Servers to select proxy servers specified in the Origin Servers page
|
Note: If you configured multiple origin servers in "Task 9: Configure Origin Server, Load Balancing, and Failover Settings" for load balancing, then create one site-to-server mapping that maps all the applicable origin servers to the site. In that site-to-server mapping, select all the origin servers that apply for the site. If you split the origin servers among multiple site-to-server mappings, load balancing for the site will not occur in the intended manner. |
In the Exclude section, select one of the following options to restrict OracleAS Web Cache access to the origin servers for the sites specified in Edit Site Name.
Exclude Fragments restricts OracleAS Web Cache from using this mapping for ESI fragments. Select this option if the site is a virtual host site that does not provide ESI content.
Fragments Only restricts OracleAS Web Cache from using this mapping for any content that is not an ESI fragment. Select this option if the site is an ESI provider site.
Unrestricted does not enforce any OracleAS Web Cache restrictions. Select this option if the site is a virtual host site that supports ESI.
For example, one mapping entry that uses Exclude Fragments does not mean that OracleAS Web Cache is not allowed to assemble ESI content from other origin servers.
Click Submit.
After you create the mappings, order them. For each request, the first matching mapping is used.
In the Site-to-Server Mapping page, select a mapping, and then click Move Up or Move Down to order the mappings. Note the following:
Because mappings that use the wildcard * encompass a broader scope, give these mappings a lower priority than other mappings.
Because requests are resolved to the first matching mapping, give mappings that contain the optional URL path prefix a higher priority than those mappings without an URL path prefix.
For example, you should order the following mappings as follows:
http://www.company.com/portal/page?_pageid=33,4232&_dad=portal
http://www.company.com/um/traffic_cop?mailid=inbox http://www.company.com
If you instead reorder the mappings as follows, the request for URLs http://www.company.com/portal/page?_pageid=33,4232&_dad=portal and http://www.company.com/um/traffic_cop?mailid=inbox will never be reached. Requests for these URLs will instead resolve to http://www.company.com because it is listed first:
http://www.company.com http://www.company.com/portal/page?_pageid=33,4232&_dad=portal http://www.company.com/um/traffic_cop?mailid=inbox
|
Note: If the protocol used in thesrc attribute of an <esi:include> tag attribute does not match the protocol specified in the Site-to-Server Mapping page, then OracleAS Web Cache uses the protocol configured for the origin server in the Site-to-Server Mapping page. OracleAS Web Cache also reports the following warning message to the event log:
ESI include fragment protocol does not match origin server protocol: Origin Server Protocol= For example, if the template page is configured with [25/Jul/2005:19:30:48 +0000] [warning 11250] [ecid: -] ESI include fragment protocol does not match origin server protocol: Origin Server Protocol=http URL=https://www.company.com/gifs/frag1.gif |
For configured sites, specify error pages to be served from OracleAS Web Cache for network communication errors, site busy errors, and ESI <esi:include> errors:
Create error pages and place them in the $ORACLE_HOME/webcache/files directory on UNIX and the ORACLE_HOME\webcache\files directory on Windows. The default settings are as follows:
For network errors, the default setting is set to network_error.html. This error page is served when there is a network problem while connecting, sending, or receiving a response from an origin server for a cache-miss request.
For site busy errors, the default setting is set to busy_error.html. This page is served when origin server capacity is reached.
For ESI default fragments, the default setting is set to esi_fragment_error.txt. This page is served when OracleAS Web Cache is unable to fetch the src specified in an <esi:include> tag and the alt attribute, onerror attribute, or the try |attempt |except block are either not present or fail.
For a production environment, modify the defaults or create entirely new error pages to be consistent with other error pages for the site.
Configure OracleAS Web Cache with the error pages.
You can modify the settings for error pages in one of two ways:
Change the default settings, and apply it to all defined sites.
Modify the error page settings for a specific site.
From Application Server Control Console, navigate to Web Cache Home page > Administration tab > Properties > Application > Sites.
|
See Also: "Configuring Default Error Pages" in Enterprise Manager Online Help for instructions on configuring error pages |
From OracleAS Web Cache Manager, perform these steps to configure error pages:
In the navigator frame, select Origin Servers, Sites, and Load Balancing > Error Pages.
Select either Default Pages or a site name in the table, and then click Edit.
The Edit Error Pages dialog box appears.
In the Network Error Page field, enter the file name of the error page that will be delivered for network communication problems between OracleAS Web Cache and the Web site.
If you are using the default network_error.html page, leave the field as is.
In the Site Busy Page field, enter the file name of the error page that will be delivered when a Web site is saturated with requests.
If you are using the default busy_error.html page, leave the field as is.
In the ESI Default Fragment field, enter the file name of the page that will be delivered when OracleAS Web Cache is unable to retrieve an HTML fragment for an <esi:include> tag.
If you are not using <esi:include> tags for partial page caching or you want to use only ESI language elements for exceptions, do not enter a value.
Click Submit.
If you selected Default Pages in Step b, the new settings will be applied to all defined sites with the default page setting. However, the new setting will not be applied to undefined sites. If you selected a specific site in Step b, the new settings will be applied to just to the site.
|
See Also: "Exceptions and Errors" to understand how exceptions and error are handled for<esi:include> errors
|
|
Notes:
|
You can configure OracleAS Web Cache to support session binding, whereby a user session for a particular site is bound to an origin server in order to maintain state for a period of time. To utilize this feature, the origin server itself must maintain state; that is, it must be stateful.
If a request is forwarded to an origin server for an object requiring session binding, the origin server creates the user session by including the session information to clients through OracleAS Web Cache in the form of a session cookie or an embedded URL parameter. OracleAS Web Cache does not process the value of the parameter or cookie; it simply passes the information back to the client browser. When a client includes the session information in a subsequent request, OracleAS Web Cache forwards the request to the origin server that originally created the user session. OracleAS Web Cache binds the user session to that particular origin server.
If you have configured a cache cluster, you must enable tracking of session bindings through the use of a cookie that tracks session information so that it can be read by all cluster members. OracleAS Web Cache includes a Set-Cookie response-header in the response so that subsequent requests from the client include the cookie. The cookie provides information so that any of the cluster members can resolve the binding regardless of which cache handled the initial request.
|
See Also::
|
By default, session binding is not enabled for any sites. If there is no session binding specified for a site, then the default session binding setting is applied, which uses the Default Session Binding rule. The Default Session Binding rule has a default value of Disable Session Binding. You can enable session binding in one of two ways:
Change the default value of the Default Session Binding rule from Disable Session Binding to a specific session and binding mechanism. OracleAS Web Cache applies these settings to all sites that use the Default Session Binding rule. If you decide to change the value of the Default Session Binding rule, ensure all named sites currently configured with this rule require session binding. If some sites do not require session binding, leave the value of Disable Session Binding, and instead specify session binding settings for the site. Use the next option.
Overwrite the default session binding setting to some other session for a specific site.
To enable session binding in Application Server Control Console, navigate to Web Cache Home page > Administration tab > Properties > Application > Sites.
|
See Also: "Configuring Session Binding Settings" in Enterprise Manager Online Help for instructions |
To enable session binding from OracleAS Web Cache Manager:
In the navigator frame, select Origin Servers, Sites, and Load Balancing > Session Binding.
In the Session Binding page, select Default Session Binding or a specific site name in the table, and then click Edit Selected.
The Edit Session Binding dialog box appears.
From the Please select a session list:
If you selected the Default Session Binding rule in Step 2, change the session value from Use Default Session Binding to another defined session, and then skip to Step 4.
If you selected a specific site in Step 2, change the session value from Disable Session Binding to a defined session, and then skip to Step 3. Table 8-1 provides descriptions of the default session definitions provided at installation time.
If you want OracleAS Web Cache to bind user sessions with multiple cookies when any cookie is set, select a session of Any Set Cookie. When selecting Any Set Cookie, in Please select a session binding mechanism, select Cookie-Based to instruct OracleAS Web Cache to include a Set-Cookie response-header in the response.
If the sessions listed do not contain the definition you require, click Cancel to exit the Edit Session Binding dialog box. Continue to Step 4.
Create a session definition:
In the navigator frame, select Rules for Caching, Personalization, and Compression > Session Definitions.
The Session Definitions page appears.
From the For Site list, select the Web site for which you want to create site-specific site definitions.
Click Add or Create.
The Edit/Add Session Definition dialog box appears.
In the Session Name field, enter an easy-to-remember unique name.
Enter the cookie name in the Cookie Name field and the embedded URL parameter in the URL or Post body parameter field.
If you enter both a cookie name and an embedded URL parameter, keep in mind that both must be used to support the same session. If they support different sessions, create separate session definitions. You can specify up to 20 session definitions for each page.
|
Note: OracleAS Web Cache requires a session cookie to perform session binding. If client browsers do not support cookies and you want to use an embedded URL parameter for the session, then perform the following for OracleAS Web Cache to perform session binding on the session:
OracleAS Web Cache uses the See Also: |
Click Submit.
From the Please select a session binding mechanism list, select one of the following mechanisms:
Cookie-based: Select if the client supports cookies. OracleAS Web Cache uses its own cookie to track a session. This cookie, which contains routing information, is maintained between OracleAS Web Cache and the client browser.
OC4J-based: Select if the application is based on OC4J. OracleAS Web Cache forwards routing information with each request to OC4J through Oracle HTTP Server.
Internal-tracking: Select if the client does not support cookies and the application is not based on Oracle HTTP Server and OC4J. This option is intended for backward compatibility with earlier releases of OracleAS Web Cache. OracleAS Web Cache maintains an in-memory routing table, of which each entry maps a session ID to an origin server. The routing table is not shared among cluster nodes. If you select this option and you have a cache cluster configuration, then you must bind at the load balancer layer.
Click Submit.
If you selected the Default Session Binding rule in Step 2, the new settings will be applied to all defined sites with the default session binding setting. However, the new default will not be applied to undefined sites. If you selected a specific site in Step 2, the new settings will be applied to just the site.
Specify the URLs containing the objects you want OracleAS Web Cache to cache.
After you configure OracleAS Web Cache, restart OracleAS Web Cache. To restart OracleAS Web Cache, use one of the following tools:
For an Oracle Application Server installation, use either the Application Server Control Console or the command-line opmnctl utility.
Both these tools enable you to restart the cache or admin server process, or both.
For a standalone installation of OracleAS Web Cache, use either OracleAS Web Cache Manager or the command-line webcachectl utility.
OracleAS Web Cache Manager enables you to restart only the cache server process; webcachectl enables you to restart the cache or admin server processes, or both.
You must restart both the cache server and admin server processes if you modified one of the following configuration settings:
Administration port properties
Password for the administrator account
Trusted subnets
User and group ID information
Many of the topologies described in Chapter 5 use a hardware load balancer to distribute incoming requests among origin servers. Instead, you can select to configure the following options:
You can configure a special mode of OracleAS Web Cache that enables you to use OracleAS Web Cache solely as a software load balancer of HTTP traffic or reverse proxy to origin servers. This configuration mode is useful for:
Managing traffic to low-volume, departmental, or test Web sites
Proxying traffic in the DMZ between a hardware load balancer and an application using OracleAS Portal or OracleAS Single Sign-On
This mode disables all functions in OracleAS Web Cache, except for load balancing and SSL. For example, this mode disables support for the following features:
Compression: OracleAS Web Cache ignores all compression settings.
ESI: OracleAS Web Cache does not assemble ESI content.
Cache hierarchies: If you plan to configure two caches in a cache hierarchy, then you should not configure one of the caches as a load balancer.
Full cache cluster support: If you configure a cache cluster, OracleAS Web Cache automatically assigns a capacity of 0 to all cluster members, even if you configure other capacity values. When capacity is set to 0 for all cluster members, no requests will be forwarded between cluster members. However, you can still propagate the configuration and OracleAS Web Cache can automatically propagate invalidation requests to cluster members
End-user performance monitoring: OracleAS Web Cache does not monitor the response time of your applications.
You can deploy a single OracleAS Web Cache server as a load balancer. However, this deployment makes the OracleAS Web Cache server a single point of failure for your application. You can instead configure a cache cluster with multiple OracleAS Web Cache servers in conjunction with operating system load balancing capabilities. Take note of the capacity changes mentioned earlier in this section.
In this mode, you can configure OracleAS Web Cache to load balance HTTP traffic in front of an application using ESI or in front of another OracleAS Web Cache. The OracleAS Web Cache load balancer does not process ESI content or participate in hierarchical caching. For example, a typical OracleAS Portal deployment has a built-in OracleAS Web Cache used for ESI assembly. For these configurations, do not configure the OracleAS Web Cache used for ESI assembly as a load balancer.
If you require other OracleAS Web Cache features, such as caching or compression support, do not configure this mode. Instead, configure a hardware load balancer or operating system load balancing support, and use the load balancing feature to manage requests to origin servers.
|
See Also:
|
To configure a single OracleAS Web Cache server as a software load balancer:
Download an Automated Release Update (ARU) for bug 4569559.
You can download ARUs from OracleMetalink:
Follow the instructions provided in the Readme for the patch.
Create a backup copy of the internal.xml file. This file is located in the $ORACLE_HOME/webcache directory on UNIX and ORACLE_HOME\webcache directory on Windows.
Use a text editor to open the internal.xml file.
Locate the CALYPSOINTERNALPARAMS element.
...
<CALYPSOINTERNALPARAMS>
<HEURISTICS CATELMFACTOR="0.0"/>
<CACHE/>
<SEARCHKEY/>
<INVALIDATION/>
<MEMORYMANAGER/>
<PPC/>
<MISCELLANEOUS/>
<OEMPERFTOOL/>
</CALYPSOINTERNALPARAMS>
...
Add the LOADBALANCE subelement directly after the OEMPERFTOOL subelement as follows:
...
<CALYPSOINTERNALPARAMS>
<HEURISTICS CATELMFACTOR="0.0"/>
<CACHE/>
<SEARCHKEY/>
<INVALIDATION/>
<MEMORYMANAGER/>
<PPC/>
<MISCELLANEOUS/>
<OEMPERFTOOL/>
<LOADBALANCE ON="YES"/>
</CALYPSOINTERNALPARAMS>
...
Save internal.xml.
Restart OracleAS Web Cache with the following command:
opmnctl restartproc ias-component=WebCache
Verify OracleAS Web Cache is running in the load balancer mode from the OracleAS Web Cache Manager by verifying the following status message displays beneath the Apply Changes and Cancel Changes buttons:
Web Cache running in Load Balancer Mode with current configuration
Application Server Control Console does not provide an equivalent verification status.
Ensure the auto-restart mechanism is enabled, as described in "Task 3: Configure Auto-Restart Settings".
Configure origin servers, as described in "Task 9: Configure Origin Server, Load Balancing, and Failover Settings".
Create site definitions and map them to the origin servers, as described in "Task 10: Configure Web Site Settings".
If your application deployment requires session stickiness, enable session binding. See "Bind a Session to an Origin Server".
Applications using OracleAS Single Sign-On and Oracle Delegated Administration Services, for example, require session binding.
If the application that requires session stickiness is an OC4J application, then configure session binding using the JSESSIONID cookie.
Consider the topology depicted in Figure 8-5.
Figure 8-5 Deploying OracleAS Web Cache as a Load Balancer
To configure this topology:
Register the IP address of the OracleAS Web Cache server webche-host with www.app1.company.com.
Configure the OracleAS Web Cache server with the following:
Receive HTTP and HTTPS requests on designated listening ports.
Send HTTP and HTTPS requests to application Web servers app1-host1 and app1-host2 on designated listening ports.
Map virtual host site definition for www.app1.company.com mapped to app1-host1 and app1-host2.
Certain operating systems provide load balancing support, which can increase the availability of OracleAS Web Cache, particularly in cache clusters.
When the operating system detects a failure of one of the caches, automatic IP takeover is used to distribute the load to the remaining caches in the cluster configuration. Because requests are sent to the virtual IP address, not to a specific host, requests can be served even if one of the hosts is unreachable.
In addition, some operating systems provide load balancing for incoming requests. You can configure the operating system to balance the load of incoming requests across caches on multiple nodes.
A network load balancer does not provide all the features, such as firewall or ping URL mechanisms, that a hardware load balancer may provide, but if those needs are already met, you could consider using a network load balancer.
The following section, "Configuring Microsoft Network Load Balancing" describes how to configure a network load balancer on one operating system. Refer to your operating system documentation for more information.
On certain Windows platforms, you can use the Microsoft Network Load Balancing (NLB) component of the operating system instead of a hardware load balancer. NLB is part of the Microsoft clustering offerings and is available on the following platforms:
Windows 2000 Advanced Server
Windows 2000 Datacenter Server
Windows 2003 (all editions)
You configure the hosts as a cluster and you configure the operating system to provide load balancing. Then, you configure NLB for hosts that are running Web Cache in a cache cluster, taking the following steps for each host:
Choose Start > Settings > Network and Dial-up Connections.
Select the network adapter. Then, right-click and select Properties.
In the Properties dialog box, select Network Load Balancing. Then, click Properties.
In the Cluster Parameters tab of the Network Load Balancing Properties dialog box, take the following steps:
For Primary IP Address, enter the virtual IP address to be shared by all members of the cluster.
For Subnet mask, enter the subnet mask for the virtual IP address.
For Full Internet Name, enter the full internet name for the virtual IP address.
Note the Network Address, which is a generated address.
For Multicast support, check enabled.
Optionally, enter a Remote password and enable Remote control.
Select the Host Parameters tab and take the following steps:
For Priority, enter an integer between 1 and 32. The lower the number, the higher the priority. Priority establishes the default handling priority among hosts for requests that are not load-balanced by port rules. (See Step 6 for information about configuring port rules.)
For Initial cluster state, check active. This specifies that this host should be included in the cluster array immediately upon Windows startup.
For Dedicated IP address, enter the IP address of this host.
For Subnet mask, enter the subnet mask of this host.
Select the Port Rules tab, and take the following steps:
For Port Range, to balance the load from all client requests with a single port rule, use the default port range (1-65535). Use multiple port rules if different applications require different protocols, filtering modes, or affinity.
For Protocols, select TCP. If your application uses software that requires UDP, select Both.
For Filtering Mode, select Multiple Hosts.
For Affinity, you can select one of three options. None results in load balancing of all requests across all hosts. Single results in all requests from a particular client being processed by the same host. Use this option to maintain session state. Class C results in all client requests from a TCP/IP class C address range being processed by the same host.
For Load Weight, either enter a percentage of the load to be handled by the host or select equal.
Note that Port Rules must be identical for all hosts in the cluster.
For more information about Microsoft Network Load Balancing, see the Microsoft documentation at:
http://www.microsoft.com
This section contains these topics:
A client, such as a browser, can send information about its IP address in a header in a request. However, because a client could use a false IP address in the header, allowing a cache to forward that information to another cache or to the origin server can be a potential security problem. By default, OracleAS Web Cache removes any IP header information forwarded from a client and replaces it with a header that contains the correct IP address of the client. (In this case, a client can be a browser or another cache in a hierarchy.)
In a cache hierarchy, OracleAS Web Cache must be able to preserve the information that is forwarded from one cache to another in the hierarchy or from a cache to the origin server.
To configure these settings in Application Server Control Console, navigate to Web Cache Home page > Administration tab > Properties > Web Cache > Security.
|
See Also: "Ensuring That ClientIP Headers Are Valid" in Enterprise Manager Online Help for instructions |
To configure these settings in OracleAS Web Cache Manager:
In the navigator frame, select Properties > Security.
In the Special Security Header Configuration section of the Security page, check the value of the Accept client IP addresses encoded in ClientIP headers field.
If the value is NO, OracleAS Web Cache removes any ClientIP request-header forwarded from the client and replaces it with a header that contains the correct IP address.
If the value is YES, OracleAS Web Cache accepts the header received from the client and can forward it to another cache or the origin server.
If the settings do not match the following information, click Edit and change the settings in the Special Security Header Configuration dialog box:
For a simple configuration, the value should be NO.
In a cache cluster, the value should be NO for all cluster members.
In an ESI hierarchy, for the subscriber cache, the value should be NO.
In an ESI hierarchy, for the provider cache, the value should be YES.
Because the provider cache received the header from the subscriber cache, it can safely forward it to the origin server.
In a distributed cache hierarchy, for the remote cache, the value should be NO.
In a distributed cache hierarchy, for a central cache that receives requests only from other caches, the value should be YES.
If the central cache receives requests from both browsers and other caches in the hierarchy, OracleAS Web Cache cannot distinguish which is a browser and which is another cache. In this case, if you specify YES, a false IP address could potentially be forwarded from a browser. However, correct information would be forwarded from another cache. If you specify NO, a false IP address could not be forwarded from a browser. However, the information forwarded from another cache would contain the IP address of the cache, not of the original client.
Click Submit, and then click Apply Changes.
By default, OracleAS Web Cache provides the following limits for HTTP request header field:
819000 bytes for the total sum of all HTTP request header fields in requests
Oracle recommends setting the header size to a lower value than the default to ensure security and prevent denial-of-service attacks from malicious clients.
If the length of the request is larger than the allowed limit, OracleAS Web Cache sends an error to the client and reports the error 11356 to the event log:
Total request header length exceeds configured maximum. A forbidden error response is returned to the client.
8152 bytes for an individual HTTP request header field
Oracle recommends setting the individual header size based on how large an application sets HTTP requests header fields.
If the length of the request is larger than the allowed limit, OracleAS Web Cache sends an error to the client and reports the error 11355 to the event log:
Single request header length exceeds configured maximum. A forbidden error response is returned to the client.
To modify the default header limits in Application Server Control Console, navigate to Web Cache Home page > Administration tab > Properties > Web Cache > Security.
|
See Also: "Configuring HTTP Request Header Limits" in Enterprise Manager Online Help for instructions |
To modify the default header limits in OracleAS Web Cache Manager:
In the navigator frame, select Properties > Security.
In the HTTP Request Header Limits section of the Security page, click Edit.
The HTTP Request Header Limits dialog box appears.
In the Maximum combined header size in bytes field, specify the total sum of all HTTP request header fields in requests. Specify a limit of at least 4096 bytes (4 KB).
In the Maximum individual header size in bytes field, specify the allowed length limit of an individual HTTP request header fields. Specify a limit of at least 256 bytes.
Click Submit, and then click Apply Changes.
On UNIX, you must configure webcached to run with root privilege in the following cases:
Privileged port numbers less than 1024 are being used for OracleAS Web Cache listening ports.
There are more than 1,024 file descriptors being used for connections to OracleAS Web Cache.
The current opmnctl or webcachectl user does not match the configured process identity user in the Security page (Web Cache Home page > Administration tab > Properties > Application > Origin Servers) of Application Server Control Console or the Process Identity page (Properties > Process Identity) of OracleAS Web Cache Manager.
This section contains the following topics:
For a configuration with privileged ports or to increase the file descriptor limit for OracleAS Web Cache, use the setroot command of webcache_setuser.sh to provide OracleAS Web Cache with root privilege without requiring changing the process identity settings:
From $ORACLE_HOME/webcache/bin, execute:
webcache_setuser.sh setroot user_ID
where user_ID is the user that performed installation.
|
See Also: "Script for Setting File Permissions on UNIX" for further information about thewebcache_setuser.sh script
|
Log out of the computer, and re-login as the user that installed Oracle Application Server.
Start OracleAS Web Cache.
For a configuration in which the current user does not match the configured user settings, change the process identity of the OracleAS Web Cache processes and use the setidentity command of webcache_setuser.sh to provide OracleAS Web Cache with root privilege:
Change the process identity of the OracleAS Web Cache processes.
Oracle recommends running OracleAS Web Cache using a restricted user.
|
See Also: "Task 2: Modify Security Settings" for instructions on setting the group ID and user ID to establish process identity |
Use the webcache_setuser.sh script as follows to run OracleAS Web Cache as a different user and add set-user ID permission to the webcached executable:
webcache_setuser.sh setidentity user_ID
where user_ID is the user ID you specified in Step 2.
|
See Also: "Script for Setting File Permissions on UNIX" for further information about thewebcache_setuser.sh script
|
Log out of the computer, and re-login as the user you configured in Step 2.
Start OracleAS Web Cache.
You can revert permissions back to the installation state with the revert command of webcache_setuser.sh. It is necessary to revert permissions if you used the setidentity command and plan to install a patch release. Otherwise, you will be unable to write to files in the $ORACLE_HOME/webcache directory. After the patch installation is complete, you can choose to change the process identity again with the setidentity command.
To revert file permissions:
Use the webcache_setuser.sh script as follows to revert file permissions back to the installed state:
webcache_setuser.sh revert user_ID
where user_ID is the user that performed installation.
|
See Also: "Script for Setting File Permissions on UNIX" for further information about thewebcache_setuser.sh script
|
Log out of the computer, and re-login as the user that installed Oracle Application Server.
Start OracleAS Web Cache.
