Oracle®
Application Server Web Cache Administrator's Guide
10g Release 2 (10.1.2) B14046-05 |
This chapter describes the main tasks to begin caching
content with OracleAS Web Cache.
This chapter contains these topics:
- Using the Default Configuration
- Tasks for Setting Up OracleAS Web Cache
- Configuring for High Availability Without a Hardware
Load Balancer
- Advanced Configuration 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.
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 theadministratoraccount
|
Application Server Control Console:
Web Cache Home page > Administrationtab
> Properties > Web Cache > Security
OracleAS Web Cache Manager:
Properties > Security
|
|
Password for theinvalidatoraccount
|
Application Server Control Console:
Web Cache Home page > Administrationtab
> 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 > Administrationtab
> Properties > Web Cache > Security
OracleAS Web Cache Manager:
Properties > Process
Identity
|
Auto-Restart
|
Enabled/Disabled: Enabled
Failover threshold: 3
Ping URL: /_oracle_http_server_webcache_static_.html
Polling interval for polling: 15 seconds
Ping timeout: 30 seconds
|
Application Server Control Console:
Web Cache Home page > Administrationtab
> 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 > Administrationtab
> 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 > Administrationtab
> 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 > Administrationtab
> 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 > Administrationtab
> 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 > Administrationtab
> 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 > Administrationtab
> Properties > Web Cache > Logging
OracleAS Web Cache Manager:
Logging and Diagnostics > Event
Logs
|
|
Access logs
|
Application Server Control Console:
Web Cache Home page > Administrationtab
> 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 > Administrationtab
> Properties > Web Cache > Ports
OracleAS Web Cache Manager:
Ports > Ports
|
|
Administration
|
Application Server Control Console:
Web Cache Home page > Administrationtab
> Properties > Web Cache > Ports
OracleAS Web Cache Manager:
Ports > Operations Ports
|
|
Invalidation
|
Application Server Control Console:
Web Cache Home page > Administrationtab
> Properties > Web Cache > Ports
OracleAS Web Cache Manager:
Ports > Operations Ports
|
|
Statistics
|
Application Server Control Console:
Web Cache Home page > Administrationtab
> 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 > Administrationtab
> 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 > Administrationtab
> 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 > Administrationtab
> Properties > Application > Sites
OracleAS Web Cache Manager:
Origin Servers, Sites, and Load
Balancing > Site
Definitions
|
Site-to-server mappings
|
Oracle_HTTP_Server_host:Oracle_HTTP_Server_port
Oracle_HTTP_Server_host:Oracle_HTTP_Server_port
|
Application Server Control Console:
Web Cache Home page > Administrationtab
> Properties > Application > Sites
OracleAS Web Cache Manager:
Origin Servers, Sites, and Load
Balancing > Site-to-Server
Mappings
|
Error Pages
|
network_error.html in $ORACLE_HOME/webcache/files on UNIX andORACLE_HOME\webcache\files on Windows
busy_error.html in $ORACLE_HOME/webcache/files on UNIX andORACLE_HOME\webcache\files on Windows
esi_fragment_error.txt in$ORACLE_HOME/webcache/files on UNIX
and ORACLE_HOME\webcache\files on Windows
|
Application Server Control Console:
Web Cache Home page > Administrationtab
> 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 > Administrationtab
> 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 > Administrationtab
> 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 > Administrationtab
> 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 1: Start OracleAS Web Cache
- Task 2: Modify Security Settings
- Task 3: Configure Auto-Restart Settings
- Task 4: Configure Network Time Outs
- Task 5: Set Resource Limits
- Task 6: Configure OracleAS Web Cache with Listening
Ports for Client Requests
- Task 7: Provide Directives to Oracle HTTP Server
- Task 8: Configure OracleAS Web Cache with Operations
Ports
- Task 9: Configure Origin Server, Load Balancing, and
Failover Settings
- Task 10: Configure Web Site Settings
- Task 11: Specify Caching Rules
- Task 12: Restart OracleAS Web Cache
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:
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 allcluster
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:
·
"Classes of Users and Their Privileges" for
further information about the different administrative roles
·
Section 7.3.3,
"Portal Web Cache Settings" in Oracle Application Server Portal Configuration Guide for
information about additional settings required for OracleAS Portal
configurations
|
- 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 the webcached executable to
run as root
|
- 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.
e.
webcache_setuser.sh
setidentity <user_ID>
f.
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 the webcache_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 Restartoption 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:
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 the cache server process
is not running, the auto-restart mechanism immediately restarts 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.
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:
·
"Task 6: Modify ssl.conf for Keep-Alive
Connections" for further information about configuring
the Oracle HTTP Server to maintain keep-alive connections from OracleAS Web
Cache for Internet Explorer browsers
·
"Browser Displaying a Page Not Displayed
Error" for further information about the keep-alive
limitations with Internet Explorer browsers
|
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. TheOutgoing_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:
·
Operating system-specific documentation
for connection limitations
·
Oracle Application Server Performance Guide for TCP/IP performance
tuning tips
|
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:
- Adding a Listening Port
- Changing Site Configuration
- Configuring Other Oracle Application Server
Components with the Listening Port
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
|
- 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:
·
"Running webcached with Root Privilege" for
instructions on changing the webcached executable to
run as root
·
"Problem 4: Privileged Port Numbers" for
further information about privileged ports and generated event log errors
|
- 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:
·
"Secure Sockets Layer (SSL)" for
further information about HTTPS
·
Chapter 9 for complete instructions on
HTTPS configuration including creating wallets and specifying the wallet
location
|
- 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.
See Also:
"Creating Site Definitions" for
site configuration instructions
|
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 Listendirective. 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 of ServerName, you must also modify
the default site information for OracleAS Web Cache. See "Default Site Example".
|
See Also:
|
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_port
https://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:
- 9400 for administration
requests
- 9401 for invalidation requests
- 9402
for statistics monitoring requests
Note:
·
Requests to the administration port must
originate from a trusted host or a host on a trusted subnet. Trusted hosts
and subnets are defined in the Security page (Properties > Security).
See "Task 2: Modify Security Settings" for
further information.
·
By default, the administration, invalidation,
or statistics monitoring ports are configured for HTTP basic authentication.
The passwords for the administrator and the invalidator accounts can be
decoded when they are sniffed out of the HTTP traffic. To avoid breach of
security information for unprotected and insecure networks, modify the
protocol to HTTPS to ensure that the passwords for these requests are secure.
Perform the procedure that follows.
|
This section contains the following topics:
- Modifying Operations Ports
- 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.
- Go to
the ADMINISTRATION, INVALIDATION, or STATISTICS row.
- 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:
·
"Running webcached with Root Privilege" for
instructions on changing the webcached executable to run
as root
·
"Problem 4: Privileged Port Numbers" for
further information about the reported event log errors
|
- 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.
See Also:
Chapter 9 for complete instructions on
HTTPS configuration
|
- 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 cacheserver 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 createone 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 ofDISABLED, OracleAS Web
Cache serves a network error page to clients.
See Also:
|
- 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:
·
The threshold does not apply if OracleAS
Web Cache cannot connect to an origin server. In this case, OracleAS Web
Cache immediately considers the server down and does not use it for future
requests. If there are other origin servers, OracleAS Web Cache retries the
request to another origin server. If there no servers configured, OracleAS
Web Cache returns an error.
·
The failover to another origin server
does not apply if there is only one origin server left.
|
- 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.
See Also:
|
- 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:
- Default Site Example
- Virtual Host Site Examples
- ESI Provider Site Example
- Creating 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 the ServerName 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 serverhost-server:7778. The ESI content policy
is set to Exclude Fragments, which restricts OracleAS Web Cache
from fetching ESI content from host-server:7778for this 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.comto origin server host-server:7778. The ESI content policy is set
to Unrestricted.
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 andwww.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.
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.
See Also:
|
To create new site definitions from OracleAS Web Cache
Manager:
Note:
·
It may not be possible to specify a site
definition for an external ESI provider site. If an ESI request is made
to a provider that does not match any application Web server mapping, then
OracleAS Web Cache uses Domain Name System (DNS) to resolve the site name.
Note that this will not work if there is a firewall between the cache and the
ESI provider. In that case, you must provide a proxy server mapping that
directs the request to the appropriate proxy.
·
Undefined ESI provider sites disable the
following OracleAS Web Cache features:
— Performance assurance heuristics
— Origin server features, such as surge
protection, load balancing, failover, and session binding
·
It is not possible to configure only ESI
provider sites. In a configuration with ESI provider sites, at least
one virtual host sitedefinition must exist for
ESI template pages.
|
- 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, notwww.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.
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:
·
Excluding the Value of Embedded URL or POST Body
Parameters for an overview and an example scenario
·
Configuring OracleAS Web Cache to Exclude the Value of
Embedded URL or POST Body Parameters for instructions on
setting global parameters
|
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 ofwww.company.com and a URL path
prefix of /portal, requests are matched
for www.company.com, not www.company.com/portal.
See Also:
"Default Site Example" for
information about how the default site is used
|
- 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 iswww.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:
·
Map multiple site names to one or more
application Web server or proxy servers. For example, *.company.com can be used to
match sites site1.company.com and site2.company.com.
·
Route cache misses to undefined ESI
provider sites outside a firewall and accessible by a proxy server. For
example,* can
be used to map to proxy server proxy-host.
You can use the wildcard * in the Port
Number field to map the same site name with different port numbers
to the same origin servers. If the origin servers are proxy servers, ensure
they were configured to listen on the same port as the application Web server
being proxied, as described in "Task 9: Configure Origin Server, Load Balancing,
and Failover Settings".
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=portaland http://www.company.com/um/traffic_cop?mailid=inbox will never be
reached. Requests for these URLs will instead resolve tohttp://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 the src 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=protocol URL=URL
For example, if the template page is
configured with <esi:include
src="https://www.company.com/gifs/frag1.gif"/> and the Site-to-Server
Mapping specifies HTTP for the origin server, then http://www.company.com/gifs/frag1.gif is used and the
following message appears in the event log:
[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 thesrc specified in an <esi:include> tag and the alt attribute, onerror attribute, or the try |attempt |except block are either not
present or fail.
See Also:
|
- 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.
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 theDefault
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 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.
- 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-1provides 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.
- 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:
1.
In addition to the URL Parameter field,
specify a cookie name for the session in the Cookie Name field.
2.
Ensure that the origin server returns
a Set-Cookie response-header
with the value of the session every time a session is created.
Set-Cookie: cookie=value
Set value to the same
value as set in the URL Parameterfield.
OracleAS Web Cache uses the Set-Cookie response header,
even if ignored by browsers, to locate the session cookie value for session
binding.
See Also: http://www.rfc-editor.org/ for further
information about the Set-Cookie response header
|
- 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
See Also:
Chapter 7 for an overview of starting,
restarting, and stopping OracleAS Web Cache
|
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:
- OracleAS Web Cache Solely as a Software Load
Balanceror Reverse Proxy
- Operating System Load Balancing Support
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.
6.
...
7.
<CALYPSOINTERNALPARAMS>
8.
<HEURISTICS CATELMFACTOR="0.0"/>
9.
<CACHE/>
10. <SEARCHKEY/>
11. <INVALIDATION/>
12. <MEMORYMANAGER/>
13. <PPC/>
14. <MISCELLANEOUS/>
15. <OEMPERFTOOL/>
16. </CALYPSOINTERNALPARAMS>
17. ...
18.
- Add
the LOADBALANCE subelement
directly after the OEMPERFTOOL subelement as follows:
20. ...
21. <CALYPSOINTERNALPARAMS>
22. <HEURISTICS
CATELMFACTOR="0.0"/>
23. <CACHE/>
24. <SEARCHKEY/>
25. <INVALIDATION/>
26. <MEMORYMANAGER/>
27. <PPC/>
28. <MISCELLANEOUS/>
29. <OEMPERFTOOL/>
30. <LOADBALANCE ON="YES"/>
31. </CALYPSOINTERNALPARAMS>
32. ...
33.
- Save internal.xml.
- Restart
OracleAS Web Cache with the following command:
36. opmnctl restartproc
ias-component=WebCache
37.
- 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:
39. Web Cache running in
Load Balancer Mode with current configuration
40.
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.
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:
This section contains these topics:
- Ensuring That ClientIP Headers Are Valid
- Configuring HTTP Request Header Limits
- Running webcached with Root Privilege
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.
- 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
> Administrationtab > 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:
- Configuring Root Privilege for Privileged Ports and
More than 1,024 File Descriptors
- Configuring Root Privilege for the Current User
- Reverting Permissions Back to Installation State
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:
2.
webcache_setuser.sh
setroot user_ID
3.
where user_ID is the user that
performed installation.
See Also:
"Script for Setting File Permissions on UNIX" for
further information about the webcache_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 thesetidentity command of webcache_setuser.sh to provide
OracleAS Web Cache with root privilege:
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:
3.
webcache_setuser.sh
setidentity user_ID
4.
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 the webcache_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 thesetidentity 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:
2.
webcache_setuser.sh
revert user_ID
3.
where user_ID is the user that
performed installation.
See Also:
"Script for Setting File Permissions on UNIX" for
further information about the webcache_setuser.sh script
|
- Log out
of the computer, and re-login as the user that installed Oracle
Application Server.
- Start
OracleAS Web Cache.
No comments:
Post a Comment