10g (9.0.4)
Part Number B10401-01
 Home |
 Solution Area |
 Contents |
 Index |
| Oracle Application Server Web Cache Administrator's Guide 10g (9.0.4) Part Number B10401-01 |
|
This chapter describes the steps needed to initially configure OracleAS Web Cache to begin caching content.
This chapter contains these topics:
OracleAS Web Cache is installed with several default settings that you can either use or modify. Table 7-1 describes the main default configuration settings and where in the OracleAS Web Cache Manager interface you can change the values.
To set up OracleAS Web Cache, perform the following tasks:
To start OracleAS Web Cache and OracleAS Web Cache Manager to begin the initial configuration:
opmnctl startproc ias-component=WebCache
This command starts the OracleAS Web Cache cache server process and admin server process.
ias_admin or administrator user.
When OracleAS Web Cache is installed, it is set up with default 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:
Configuration and operational tasks can be performed with the ias_admin or administrator user. Before you begin configuration, change the default password to a secure password. The default password is the password entered during the installation of Oracle Application Server, or if you were not prompted to supply a password, administrator.
The Security page appears.
The Change Administration User Password dialog box appears.
"Classes of Users and Their Privileges" for further information about the administrator role
See Also:
The invalidation administrator has a user ID of invalidator, whose default password is the password entered during the installation of Oracle Application Server, or if you were not prompted to supply a password, invalidator.
The Change Invalidation User Password dialog box appears.
"Classes of Users and Their Privileges" for further information about the invalidator role
See Also:
By default, the computer on which you installed OracleAS Web Cache is the trusted host.
The Change Trusted Subnets dialog box appears.
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:
Example: 10.1.2.3
Example: 10.1.0.0/255.255.0.0 allows all the hosts in the 10.1 subnet access.
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.
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 |
To change the user ID and group ID for the OracleAS Web Cache processes on UNIX:
The Process Identity page appears.
The Change Process Identity dialog box appears.
webcache_setuser.sh script as follows to change file and directory ownership:
webcache_setuser.sh setidentity <user_ID>
where <user_ID> is the user you specified in the User ID field of the Process Identity page.
The setidentity command changes the ownership of the following files and directories to the new user ID:
$ORACLE_HOME/webcache
$ORACLE_HOME/webcache/internal.xml
$ORACLE_HOME/webcache/webcache.xml
$ORACLE_HOME/webcache/webcache.xml.bak
$ORACLE_HOME/webcache/.webcache_tmp.xml.tmp
$ORACLE_HOME/webcache/logs/event_log_files
$ORACLE_HOME/webcache/logs/access_log_files
"Script for Setting File Permissions on UNIX" for further information about the
See Also:
webcache_setuser.sh script
If you changed the administrator password or the trusted subnets in the Security page or any of the settings in the Process Identity page, then, after applying changes, restart both the cache server process and admin server process with the Oracle Process Manager and Notification (OPMN) Server utility command opmnctl restartproc ias-component=WebCache or the webcachectl utility command webcachectl restart (for standalone installations). You cannot use the Restart option in the Cache Operations page to restart the admin server process. Until the admin server process is restarted, you cannot submit invalidation requests from the Basic Content Invalidation or Advanced Content Invalidation pages.
|
See Also:
"Task 12: Apply Changes and Restart OracleAS Web Cache" for instruction 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.
To specify the settings for auto-restart:
The Auto-Restart page appears.
The Edit Auto-Restart dialog box is displayed.
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:
cache server to have failed. Only network errors, including timeout errors, are counted as failed requests.
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.
cache server.
You must use a URL that is cacheable that you can guarantee is stored in the cache. The default is "/".
cache server.
The default value is 15 seconds.
cache server.
The default value is 30 seconds.
After OracleAS Web Cache sends a response to a browser, the connection is left open for five seconds, which is typically enough time for the browser to process the response from OracleAS Web Cache. If the network between the browser 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 sends a network error page to the browser. If applications require a shorter timeout, adjust the timeout.
To modify the default network timeouts:
The Network Timeouts page appears.
The Edit Network Timeouts dialog box appears.
If the timeout is set to 0, the connection to the browser is not kept open. In addition, OracleAS Web Cache sends the following response-header field in the response:
Connection: Close
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 the less popular and less valid documents from the cache in favor of the more popular and more valid documents. In a cache cluster environment, OracleAS Web Cache removes on-demand documents before it removes owned documents.
To avoid swapping documents 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:
One way to do this is to look at existing Web server logs for one day to see which documents are popular. From the list of URLs in the log, decide which ones you want to cache. Retrieve the documents and get the size of each document.
The amount of memory that OracleAS Web Cache uses to store a document depends on whether the document is larger or smaller than 2 kilobytes (KB):
For this release, 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 documents smaller than 2 KB.
2KB is size of the buffer for the HTTP body for documents smaller than 2 KB.
8KB is the size of the buffer for the HTTP response header.
Y is number of documents that are 2 KB or larger.
[m/8] is the ceiling of m (the average size, in kilobytes, of documents 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 documents 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 documents with more ESI fragments require more metadata for each fragment, use the higher number (16) for documents with 10 or more fragments. For example, for a document 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 document. To support 1000 concurrent requests, you need roughly 192 MB of memory.
For example, assume that you want to cache 5000 documents that are smaller than 2 KB and 2000 documents that are 2 KB or larger and that the larger documents have an average size of 54 KB. The documents do not use ESI. You expect to process 500 documents concurrently. Use the formula to compute the maximum memory:
(5000 * (2KB + 8KB) ) + ( 2000 * (( [54/8] * 8KB ) + 8KB )) + (500 * 32KB)
Using the formula, you need:
This results in an estimate of 194,000 KB of memory needed.
The Edit Resource Limits dialog box appears.
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 documents are cached.
The Web Cache Statistics page provides information about the current memory use and the maximum memory use.
To access the Web Cache Statistics page, from the navigator frame, select Monitoring > Web Cache Statistics. Note the following metrics in the Cache Overview table:
If Current Allocated Memory is greater than Current Action Limit, OracleAS Web Cache begins garbage collection. That is, OracleAS Web Cache removes the less popular and less valid documents from the cache in favor of the more popular and more valid documents 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 documents in and out of the cache. Use the Properties > Resource Limits page 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 satisfied. 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:
ttcp, to determine how quickly your system processes a page.
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.
To set the maximum number of incoming connections, perform the following steps:
The Edit Resource Limits dialog box appears.
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 using the Resource Limits page (Properties > Resource Limits) of the OracleAS Web Cache Manager.
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 using the Clustering (Properties > Clustering) of the OracleAS Web Cache Manager.
Total_WS_Capacity is the sum of the capacity for all configured application Web servers. You set the capacity using the Origin Servers, Sites, and Load Balancing > Origin Servers page of OracleAS Web Cache Manager.
In a cache cluster environment, the capacity is divided among the cache cluster members, using the following formula:
Total_WS_Capacity = Sum_Web_Server_Capacity / n
In the formula, Sum_Web_Server_Capacity is the sum capacity of all configured application Web servers, and n is the number of cache cluster members. For example, assume you have two configured application Web Servers. Web_Server_A has a capacity of 200 and Web_Server_B has a capacity of 250. Also, assume you have a cluster with three caches. The Total_WS_Capacity is 150, as the following example calculates:
Total_WS_Capacity = (200 + 250) / 3
Outgoing_Cluster_Conn is the total of outgoing connections to peer caches in a cache cluster. The value is zero if you do not have a cache cluster. To compute this value, use the following formula:
Outgoing_Cluster_Conn = Sum_Cluster_Capacity / (n-1)
In the formula, Sum_Cluster_Capacity is the sum of the capacity of all other caches in a cluster, and n is the number of cache cluster members. For example, assume you have cluster with three caches. Cache_A has a capacity of 100, Cache_B has a capacity of 150, and Cache_C has a capacity of 200. The Outgoing_Cluster_Conn for Cache_A, is 175, as the following example calculates:
Outgoing_Cluster_Conn = (150 + 200) / (3-1)
To set the capacity of caches in a cluster, select Properties > Clustering from the navigator frame of OracleAS Web Cache Manager.
100 is the number of connections reserved for internal use by OracleAS Web Cache.
See Also:
On Windows operating systems, the number of file handles as well as socket handles is limited only by available kernel resources, more precisely, by the size of paged and non-paged pools. However, the number of active TCP/IP connections is restricted by the number of TCP ports the system can open.
The default maximum number of TCP ports is set to 5000 by the operating system. Of those, 1024 are reserved by the kernel. You can modify the maximum number of ports by editing the Windows registry. Windows operating systems allow up to 65536 ports.
To change the default, you must add a new value to the following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Add a new value, specifying the following:
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 using the Resource Limits page (Properties > Resource Limits) of the OracleAS Web Cache Manager. You set the cluster member capacity using the Clustering page (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 documents that are cached, even if the documents meet other caching rules. To specify the limit:
The Edit Maximum Cached Object Size dialog box appears.
Objects larger than the specified size will not be cached, even if they meet other caching rules. If you specify 0, no documents will be cached. However, this option is ignored if no content length header is present in the response.
By default, OracleAS Web Cache listens with the HTTP protocol on port 7777. If this port is in use, the installation procedure attempts to assign other port numbers from a range of possible port numbers.
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 browser requests on that port.
|
See Also:
Oracle Application Server 10g Administrator's Guide for information about updating the port numbers for other Oracle Application Server components |
To specify a listening port from which OracleAS Web Cache can receive browser requests:
The Listen Ports page appears.
The Edit/Add Listen Ports dialog box appears.
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:
|
See:
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.company.com ... UseCanonicalName On ....
If you decide to disable OracleAS Web Cache, the Oracle HTTP Server administrator must modify the value of the Port directive to the same value set for the Listen directive. For example:
## ## httpd.conf -- Apache HTTP server configuration file ## ... Port 7778 Listen 7778 ... ServerName http_server.company.com ... UseCanonicalName On ....
If OracleAS Web Cache is deployed on a separate computer from the Oracle HTTP Server, the Oracle HTTP Server administrator must modify the ServerName directive in httpd.conf for each site hosted by OracleAS Web Cache. This 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:
Port 7777 Listen 7778 ... ServerName www.1st.company.com ServerName www.2nd.company.com ... UseCanonicalName On ....
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.
In addition to receiving HTTP and HTTPS browser requests, OracleAS Web Cache also receives administration, invalidation, and statistics monitoring requests on specific HTTP or HTTPS listening ports:
http://web_cache_hostname:http_porthttps://web_cache_hostname:https_port
By default, OracleAS Web Cache uses the HTTP protocol to receive these requests. Default HTTP port numbers are as follows:
Oracle Application Server 10g Administrator's Guide for information about updating the port numbers for other Oracle Application Server components
See Also:
Notes:
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.
To change the default port number or protocol for administration, invalidation, or statistics monitoring requests:
The Operations Ports page appears.
The Edit Operations Port dialog box appears.
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:
|
See:
After making an Administration port property change, restart the admin server process before you use the OracleAS Web Cache Manager for additional configuration. Use the following OPMN utility command:
opmnctl restartproc ias-component=WebCache process-type=WebCacheAdmin
If you are running a standalone instance of OracleAS Web Cache, use the following webcachectl utility command:
webcachectl restartadm
You cannot use the Restart option in the Cache Operations page (Operations > Cache Operations) to restart the admin server process.
After making Invalidation or Statistics port property changes, restart the cache server process with the Restart option in the Cache Operations page. Until the cache server process is restarted after an Invalidation port change, you receive the following error when you submit invalidation requests from the Basic Content Invalidation or Advanced Content Invalidation pages (Operations > Basic Content Invalidation or Advanced Content Invalidation):
Internal error: can't connect to OracleAS Web Cache Invalidation Listening Port
Likewise, after a Statistics port change, the Cache Operations page does not display the current Uptime and Operation Needed information for the cache. In addition, the Monitoring pages (Web Cache Statistics, Health Monitor, Origin Server Statistics, and Popular Requests) report the following error.
Failure obtaining statistics from Web Cache cache server: error in connect.Please check that the cache server is up and running.
|
See Also:
"Task 12: Apply Changes and 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.
OracleAS Web Cache only forwards requests to a configured origin server if the server is mapped to a Web site in the Site-to-Server Mapping page (Origin Servers, Sites, and Load Balancing > Site-to-Server Mapping). If you are configuring load balancing for a site, then create one site-to-server mapping that maps all the applicable origin servers to the site.
|
See Also:
|
To configure OracleAS Web Cache with application Web server or proxy server information:
The Origin Servers page appears.
The Add Application Web Server or Proxy Server dialog box appears.
Oracle Corporation recommends selecting DISABLED if temporary maintenance of an origin server is needed.
OracleAS Web Cache tries to route a request matching a particular site to all origin servers mapped to that site. If all of the origin servers have a routing of DISABLED, OracleAS Web Cache serves a network error page to browsers.
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
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. The default is five failed request/response failures. If an origin server fails 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:
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.
Rather than using a static URL, Oracle Corporation 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 10 seconds.
"Task 5: Configure HTTPS Port and Wallet Location for the Origin Server" for information about configuring the wallet
See Also:
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:
A site definition consists of host name and port information about the site and 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.
Using OracleAS Web Cache Manager, you can either discover site and alias information from Oracle HTTP Server, or you can manually create definitions. Oracle Corporation recommends using the site discovery feature to initially create the necessary definitions. After discovery is complete, you can manually create additional site definitions.
To use the site discovery feature:
The Site Definitions page appears.
The Site Configuration Discovery dialog box appears. It displays the following information:
Your selections are applied to the Site Definitions page.
To create additional site definitions:
The Site Definitions page appears.
The Add Site dialog box appears.
www.company.com.
The port number should be the port used in browser requests.
/ " for the entire site.
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.
If you select Yes for a site, another site that previously had the Yes setting will change to No.
|
See Also:
"Default Site Settings" for information about how the default site is used |
For example, if the site domain name is company.com, a site alias of www.company.com will be used. If the site domain name is www.company.com, a site alias of company.com will be used.
The Add Alias for Site dialog box appears.
company.com.
The port number should be the port used in browser requests.
To map sites to origin servers, take the following steps:
The Site-to-Server Mapping page appears.
The Create Site-to-Server Mapping or Edit/Add Site-to-Server Mapping dialog box appears.
www.company.com or *.company.com, as well as the HTTP or HTTPS port number from which the site is listening for incoming requests.
You can use the wildcard
You can use the wildcard
This option does not enable you to create a site definition. You must create a site definition in the Site Definitions page.
Notes:
* in the Host Name field in the following ways:
*.company.com can be used to match sites site1.company.com and site2.company.com.
* can be used to map to proxy server proxy-host.
* in the Port Number field to map the same site name to different port numbers with 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".
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.
Note:
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.
* encompass a broader scope, give these rules a lower priority than other mappings.
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:
$ORACLE_HOME/webcache/files directory on UNIX and the ORACLE_HOME\webcache\files directory on Windows.
The default page setting is applied to Network Error, Site Busy Error, and ESI Default Fragment pages for defined sites:
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.
busy_error.html. This page is served when origin server capacity is reached.
esi_fragment_error.txt. This page is served when OracleAS Web Cache is unable to fetch the src specified in an <esi:include> tag and the alt attribute, onerror attribute, or the try |attempt |except block are either not present or fail.
For a production environment, Oracle Corporation advises that you modify the defaults or create entirely new error pages to be consistent with other error pages for the site. You can modify the settings for error pages in one of two ways:
The Error Pages page appears.
The Edit Error Pages dialog box appears.
If you are using the default network_error.html page, leave the field as is.
If you are using the default busy_error.html page, leave the field as is.
<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.
If you selected Default Pages in Step 3, 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 3, 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 |
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 the session information is contained within a session cookie or an embedded URL parameter, OracleAS Web Cache can keep track of sessions between Web browsers and origin servers. A session cookie or an embedded URL parameter enables OracleAS Web Cache to bind a particular user session to a specific origin server.
If you have configured a cache cluster, you must enable tracking of session bindings through the use of a cookie that tracks session information so that it can be read by all cluster members. OracleAS Web Cache includes a Set-Cookie response-header in the response so that subsequent requests from the client include the cookie. The cookie provides information so that any of the cluster members can resolve the binding regardless of which cache handled the initial request.
|
See Also:
|
By default, session binding is not enabled for any sites. If there is no session binding specified for a site, then the default session binding setting is applied, which uses the Default Session Binding rule. The Default Session Binding rule has a default value of Session Binding Disabled. You can enable session binding in one of two ways:
To enable session binding:
The Session Binding page appears.
The Edit Session Binding dialog box appears.
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.
The Session Definitions page appears.
The Edit/Add Session Definition dialog box appears.
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 browsers do not support cookies and you want to use an embedded URL parameter for the session, then perform the following for OracleAS Web Cache to perform session binding on the session:
OracleAS Web Cache uses the
See Also: http://www.rfc-editor.org/ for further information about the |
Oracle Corporation recommends setting the value to a higher value than the inactivity timeout set for the Web site.
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.
For those requests that do not include a Host request-header field, OracleAS Web Cache uses the default site settings to determine the appropriate site for the requests.
The default site established during installation uses the host name and listening port of the computer on which Oracle Application Server was installed. Figure 7-1 shows the default site definitions.
The default site-to-server mappings use the following rules:
* wildcard host name to map all other virtual site names to the Oracle HTTP Server. The ESI Content Policy Exclude Fragments setting restricts OracleAS Web Cache from fetching ESI content from any sites other than the sites specified in the first rule.
* wildcard host name to map all other virtual site names to the Oracle HTTP Server and a * wildcard port number to map the site name to multiple port numbers. The ESI Content Policy Exclude Fragments setting restricts OracleAS Web Cache from fetching ESI content from any sites other than the sites specified in the first two rules.
Figure 7-2 shows the default site-to-server mappings.
A virtual host site named www.company.com without ESI content could have the following site definition and site-to-server mapping shown in Figure 7-3.
The site definition specifies www.company.com, port 80 as the site and company.com, port 80 as the site alias. The site-to-server rule maps requests to www.company.com to application Web server host-server, port 7778. The ESI Content Policy Exclude Fragments setting restricts OracleAS Web Cache from fetching ESI content from host-server, port 7778 for www.company.com:80.
Figure 7-4 shows the site definitions and site-to-server mappings for virtual host sites www.1st.company.com and www.2nd.company.com that support ESI.
The site definition specifies www.1st.company.com, port 80 and www.2nd.company.com, port 80 as the sites, and 1st.company.com, port 80 and 2nd.company.com, port 80 as the site aliases. The site-to-server rules map sites matching www.*.company.com to application Web server host-server, port 7778. The ESI Content Policy Unrestricted setting enables OracleAS Web Cache to serve site content, as well as assemble ESI include fragments.
ESI provider sites named www.providersite1.com and www.providersite2.com could have the site definition and site-to-server mapping shown in Figure 7-5.
The site definition specifies www.providersite1.com, port 80 and www.providersite2.com, port 80 as the sites, and providersite1.com, port 80 and providersite2.com, port 80 as the site aliases. The site-to-server rules maps www.providersite1.com to proxy server proxy-host, port 80. The ESI Content Policy Fragments Only setting restricts OracleAS Web Cache from using this mapping for any content that is not ESI. There is no mapping 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. In addition, other ESI provider sites that do not have site definitions will also be resolved through DNS.
Specify the URLs containing the documents you want OracleAS Web Cache to cache.
After OracleAS Web Cache is configured, apply changes and restart OracleAS Web Cache.
To apply changes, in the OracleAS Web Cache Manager main window, click Apply Changes.
To restart OracleAS Web Cache, use one of the following:
cache server process.
opmnctl utility or webcachectl utility (for standalone installations) on the computer on which OracleAS Web Cache software is installed and configured. These utilities let you restart the cache or admin server process, or both.
You must restart both the cache server and admin server processes if you modified one of the following configuration settings:
administrator account in the Security page (Properties > Security)
|
See Also:
|
|
 Copyright © 2002, 2003 Oracle Corporation. All Rights Reserved. |
|