Release 2 (9.0.2)
Part Number A95404-02
 Home |
 Solution Area |
 Contents |
 Index |
| Oracle9iAS Web Cache Administration and Deployment Guide Release 2 (9.0.2) Part Number A95404-02 |
|
This chapter describes the steps to initially configure Oracle9iAS Web Cache to begin caching content. It also provides instructions for configuring multiple origin servers and a cache cluster.
This chapter contains these topics:
To set up Oracle9iAS Web Cache, perform the following tasks:
To start Oracle9iAS Web Cache Manager to begin initial configuration:
webcachectl start
When Oracle9iAS Web Cache is installed, it is set up with default passwords for administration and invalidation requests. In addition, the computer on which you installed Oracle9iAS Web Cache is the default trusted host.
To change the security settings:
Configuration and operational tasks can be performed with the Oracle9iAS Web Cache administrator user. The administrator user has a default password of administrator set up during installation. Before you begin configuration, change the default password to a secure password.
The Security page appears.
The Change Administration User Password dialog box appears.
administrator in the Old Password field and a new password between four and 20 characters long in the New Password and Confirm New Password fields.
The invalidation administrator has a user ID of invalidator, whose default password of invalidator is set up during installation.
The Change Invalidation User Password dialog box appears.
invalidator in the Old Password field, and a new password between four and 20 characters long in the New Password and Confirm New Password fields.
By default, the computer on which you installed Oracle9iAS Web Cache is the trusted host.
The Change Trusted Subnets dialog box appears.
All subnets
Select to allow requests from all computers in all the subnets in the network.
This machine only
Select to allow requests from only this computer.
Enter list of IPs
Select to allow requests from all IP addresses you enter in a comma-separated 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 Oracle9iAS Web Cache executables. This user can execute webcachectl commands. Users that belong to the same group ID of the user that performed installation can also execute webcachectl commands.
To change the user ID and group ID for the Oracle9iAS Web Cache executables on UNIX:
The Process Identity page appears.
The Change Process Identity dialog box appears.
chown command:
If you changed any of the security settings, you must restart the admin server process from the
Note:
webcachectl utility rather than with the Restart option in the Operations page (Administration > Operations). See "Task 12: Apply Changes and Restart Oracle9iAS Web Cache".
By default, Oracle9iAS Web Cache listens with the HTTP protocol on port 7777 and HTTPS on port 4443. If these ports are in use, then the installation procedure attempts to assign other port numbers from a range of possible port numbers.
It may be necessary to add an additional listening port if you want to assign Oracle9iAS Web Cache a port that an origin server was previously listening on.
To specify a listening port from which Oracle9iAS Web Cache can receive browser requests:
The Listening Ports page appears.
The Edit Listening Ports page dialog box appears.
Ensure that this port number is not already in use.
This wallet is used for browser requests for sites hosted by Oracle9iAS Web Cache.
By default, wallets are stored in the following locations:
Oracle Corporation recommends entering the location, even if the default is being used.
As long as each site is configured with a separate wallet, the Oracle9iAS Web Cache listening port can share the same wallet as specified in the Origin Server Wallet page (Cache-Specific Configuration > Origin Server Wallet).
See Also:
At installation time, Oracle HTTP Server sets the httpd.conf file with the following directives that impact Oracle9iAS Web Cache:
Port=web_cache_port specifies the Oracle9iAS Web Cache listening ports, enabling dynamically created URLs to be redirected to Oracle9iAS Web Cache
Listen=Oracle_HTTP_Server_port specifies the HTTP and HTTPS ports 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 Oracle9iAS Web Cache, then the Oracle HTTP Server administrator must modify the value of the Port directive to the same value set for the Listen directive. For example:
## ## httpd.conf -- Apache HTTP server configuration file ## ... Port 7778 Listen 7778 ... ServerName http_server.company.com ... UseCanonicalName On ....
If Oracle9iAS Web Cache is deployed on a separate computer from the Oracle HTTP Server, then the Oracle HTTP Server administrator must modify the ServerName directive in httpd.conf for each site hosted by Oracle9iAS Web Cache. This will enable Oracle HTTP Server to redirect URLs to Oracle9iAS Web Cache. The following example shows httpd.conf modified to direct requests for www.1st.company.com and www.2nd.company.com to Oracle9iAS Web Cache, which 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, Oracle9iAS 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, Oracle9iAS Web Cache uses the HTTP protocol to receive these requests. Default HTTP port numbers are as 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.
This wallet is used for administration, invalidation, and statistics monitoring HTTPS requests to Oracle9iAS Web Cache.
By default, wallets are stored in the following locations:
Oracle Corporation recommends entering the location, even if the default is being used.
As long as each site is configured with a separate wallet, these ports can share the same wallet as specified in the Listening Ports page (Cache-Specific Configuration > Listening Ports) and the Origin Server Wallet page (Cache-Specific Configuration > Origin Server Wallets).
See Also:
Notes:
admin server process from webcachectl utility rather than with the Restart option in the Operations page (Administration > Operations). See "Task 12: Apply Changes and Restart Oracle9iAS Web Cache".
The auto-restart process checks that the cache server process is running and automatically restarts the cache server process if it is not running.
If you enable auto-restart, then the auto-restart process polls the Oracle9iAS Web 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, then the auto-restart process restarts the cache server process.
By default, auto-restart is not enabled.
To specify the settings for auto-restart:
The Auto-Restart page appears.
The Edit Auto-Restart dialog box is displayed.
auto-restart process considers the cache server to have failed. Only network errors, including timeout errors, are counted as failed requests.
For each failed request, Oracle9iAS Web Cache increments the failure counter. When a request is successfully processed by the cache server, Oracle9iAS Web Cache resets the failure counter.
When the failover threshold is met, the auto-restart process starts the cache server.
auto-restart process will use to poll the cache server.
Use a URL that you can guarantee is stored in the cache. The default is "/".
auto-restart process to poll the cache server.
The default value is 15 seconds.
auto-restart process will wait for a response from the cache server.
The default value is 30 seconds.
After Oracle9iAS 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 Oracle9iAS Web Cache. If the network between the browser and Oracle9iAS Web Cache is slow, consider increasing the time-out. Likewise, there is a 3600 second network time-out between Oracle9iAS Web Cache and the origin server. If the origin server is unable to generate a response within that time, Oracle9iAS Web Cache sends a network apology page to the browser. If applications require a shorter time-out, then adjust the time-out.
To modify the default network time-outs:
The Network Timeouts page appears.
The Edit Network Timeouts dialog box appears.
If the time-out is set to 0, then the connection to the browser is not kept open. In addition, Oracle9iAS Web Cache sends the following response-header field in the response:
Connection: Close
To set resource limits for Oracle9iAS Web Cache, configure the following attributes:
When the maximum cache memory limit is reached, Oracle9iAS Web Cache performs garbage collection. During garbage collection, Oracle9iAS 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, Oracle9iAS 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 Oracle9iAS Web Cache should be set to at least 256 MB. By default, the maximum cache size is set to 50 MB, which is sufficient only for initial post-installation testing.
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.
For release 9.0.2, the amount of memory that Oracle9iAS Web Cache uses to store a document depends on whether the document is larger or smaller than 4 KB:
For release 9.0.2, use the following formula to determine an estimate of the maximum memory needed:
( X * ( 4KB + 4KB ) ) + ( Y * (( [m/32] * 32KB ) + 4KB )) + basemem
In the formula:
X is the number of documents smaller than 4 KB.
4KB is size of the buffer for the HTTP body for documents smaller than 4 KB.
4KB is the size of the buffer for the HTTP response header.
Y is number of documents that are 4 KB or larger.
[m/32] is the ceiling of m (the average size, in kilobytes, of documents 4 KB or larger) divided by 32. A ceiling is the closest integer that is greater than or equal to the number.
32KB is size of the buffer for the HTTP body for documents that are 4 KB or larger.
4KB is the size of the buffer for the HTTP response header.
basemem is the base amount of memory needed by Oracle9iAS 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 6 KB to 25 KB of memory. For example, to support 1000 concurrent requests, you need between 6 MB and 25 MB of memory.
For ESI requests, each concurrent request needs approximately the following amount of memory:
60KB + (number of ESI fragments * [6KB to 25KB])
For example, for a document with 10 ESI fragments, use the following calculation:
60KB + (10 * [6KB to 25KB]) = 120KB to 330KB
That is, you need between 120 KB and 330 KB of memory for one 10-fragment document. To support 1000 concurrent requests, you need approximately between 120 MB to 330 MB of memory.
For example, assume that you want to cache 5000 documents that are smaller than 4 KB and 2000 documents that are 4 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 * (4KB + 4KB) ) + ( 2000 * (( [54/32] * 32KB ) + 4KB )) + (500 *[6KB to 25KB])
Using the formula, you need:
This results in an estimate of 179,000 KB to 188,500 KB of memory needed.
To specify the maximum cache size, perform the following steps:
Remember that the cache is empty when Oracle9iAS 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 pane, select Administration > Monitoring > Web Cache Statistics. Note the following metrics in the Cache Overview table:
If Current Allocated Memory is greater than Current Action Limit, Oracle9iAS Web Cache begins garbage collection. That is, Oracle9iAS 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 Cache-Specific Configuration > Resource Limits page to increase the maximum cache size.
In addition to the cache size, it is also important to specify a reasonable number for the maximum connection limit for the Oracle9iAS 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 Oracle9iAS 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. Oracle9iAS 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 arbitrary high value, because Oracle9iAS 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. Oracle9iAS Web Cache tries to reserve the maximum number of file descriptors (Max_File_Desc) when it starts. As long as webcachectl can run as root, you can change this number to a higher one. For example, on Sun Solaris, you can increase the maximum number of file descriptors by setting the rlim_fd_max parameter. If the webcachectl is not able to run as root, Oracle9iAS Web Cache server logs an error message and fails to start.
|
See Also:
|
For release 9.0.2, Oracle9iAS 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 Oracle9iAS Web Cache. You set the maximum number of incoming connections using the Cache-Specific Configuration > Resource Limits page of the Oracle9iAS 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 Administration > Cluster Configuration page of the Oracle9iAS Web Cache Manager.
Total_WS_Capacity is the sum of the capacity for all configured application Web servers. You set the capacity using the General Configuration > Application Web Servers page of Oracle9iAS 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 Administration > Cluster Configuration from the navigator pane of Oracle9iAS Web Cache Manager.
100 is the number of connections reserved for internal use by Oracle9iAS 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 65534 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 (Cache-Specific > Resource Limits) of the Oracle9iAS Web Cache Manager. You set the cluster member capacity using the Cluster Configuration page (Administration > Cluster Configuration).
On Windows operating systems, Oracle9iAS 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.
Configure Oracle9iAS Web Cache with the application Web servers or proxy servers for which it sends cache misses. Typically, Oracle9iAS Web Cache uses application Web servers for internal sites and proxy servers for external sites protected by a firewall.
By default, the listening port and host name of the Oracle HTTP Server are configured. When Oracle9iAS Web Cache is installed, Oracle HTTP Server has a default listening HTTP port of 7778 and an HTTPS port of 4444.
Oracle9iAS Web Cache will only forward requests to a configured application Web server or proxy server if the server is mapped to a Web site in the Site to Server Mapping page (General Configuration > Site to Server Mapping).
To configure Oracle9iAS Web Cache with application Web server or proxy server information:
The Application Web Servers or Proxy Servers page appears.
The Create Application Web Server or Create Proxy Server dialog box appears.
The maximum number of concurrent connections that a server can handle is determined by load testing the application Web server or proxy server until it runs out of CPU, responds slowly, or until a backend database reaches full capacity.
In a cache cluster, Oracle9iAS Web Cache ensures that the total number of connections from all cluster members to the application Web server or proxy 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
|
See Also:
"Load Balancing" for information on how capacity is used in multiple application or proxy server configurations |
The default is five requests.
If a server fails any time after Oracle9iAS Web Cache has started to send a request, then Oracle9iAS 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 messages
Once the threshold is met, Oracle9iAS Web Cache considers the server down and uses other servers for future requests. When a server is down, Oracle9iAS Web Cache starts polling it. It does this by sending requests to the URL specified in the Ping URL field. When Oracle9iAS Web Cache is able to successfully get a response from the server without any network errors and the HTTP response code is not less than 100, or equal to 500, 502, 503, 504, then Oracle9iAS 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.
This wallet manages Oracle9iAS Web Cache authentication data such as keys, certificates, and trusted certificates needed by the Secure Sockets Layer (SSL). By default, wallets are stored in the following locations:
Oracle Corporation recommends entering the location, even if the default is being used.
To specify the wallet location:
The Origin Server Wallet page appears.
The Edit Origin Server Wallet dialog box appears.
"Configuring Oracle9iAS Web Cache for HTTPS Requests" for complete instructions on HTTPS configuration
See Also:
For Oracle9iAS Web Cache to act as a virtual server for one or more Web sites, configure Oracle9iAS Web Cache with information about the Web site.
To configure settings for a Web site:
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.
If you select Yes for a site, another site that previously had the Yes setting will change to No.
Many sites are represented by one or more aliases. Oracle9iAS 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, Oracle9iAS 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, then Oracle9iAS Web Cache sends the request to the default site.
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.
If additional or other site aliases are used by site, continue to Step 2. Otherwise, skip to Step 3.
The Add Alias for Site dialog box appears.
company.com.
The port number should be the port used in browser requests.
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.
For example, one mapping entry that uses Exclude ESI does not mean that Oracle9iAS Web Cache is not allowed to assemble ESI content from other origin servers.
The Edit/Add Site to Server Mapping dialog box closes.
* encompass a broader scope, give these rules a lower priority than other mappings.
<esi:include> errors:
ORACLE_HOME/webcache/docs on UNIX and ORACLE_HOME\webcache\docs on Windows create apology pages.
By default, Oracle9iAS Web Cache uses network_error.html for network errors and busy_error.html for site busy errors. For a production environment, Oracle Corporation advises that you modify the defaults or create entirely new apology pages. There is no default for ESI <esi:include> errors. If you plan to use ESI <esi:include> tags for partial page caching, then you must create an apology page. Create or modify existing apology pages in $ORACLE_HOME/webcache/docs on UNIX and ORACLE_HOME\webcache\docs on Windows.
The Apology Pages page appears.
The Edit Apology 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>.
If you are not using <esi:include> tags for partial page caching or you want to use ESI language elements for exceptions, do not enter a value.
The Edit Apology Pages dialog box closes.
|
See Also:
"Exceptions and Errors" to understand how exceptions and error are handled for |
For those requests that do not include a Host request-header field, Oracle9iAS Web Cache uses the default site settings to determine the appropriate site for the requests. Figure 6-1 shows the default site definition and site-to-server mappings.
The default site established during installation uses the host name and listening port of the computer on which the Oracle9i Application Web Server was installed. 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 and a * wildcard port number to map the site name to multiple port numbers. The Exclude ESI setting restricts Oracle9iAS Web Cache from fetching ESI content from any sites other than the sites specified in the first two rules.
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 6-2.
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 Exclude ESI setting restricts Oracle9iAS Web Cache from fetching ESI content from host-server, port 7778 for www.company.com:80.
Figure 6-3 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 Exclude NONE setting enables Oracle9iAS 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 following site definition and site-to-server mapping shown in Figure 6-4.
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 Exclude NON_ESI setting restricts Oracle9iAS Web Cache from using this mapping for any content which 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 Oracle9iAS Web Cache to cache.
After Oracle9iAS Web Cache is configured, apply changes and restart Oracle9iAS Web Cache.
To apply changes, in the Oracle9iAS Web Cache Manager main window, choose Apply Changes.
To restart Oracle9iAS Web Cache, use either Oracle9iAS Web Cache Manager or the webcachectl utility on the computer on which Oracle9iAS Web Cache software is installed and configured.
| Use Oracle9iAS Web Cache Manager... | Use the webcachectl Utility... |
|---|---|
|
|
When you restart Oracle9iAS Web Cache, all objects are cleared from the cache. In addition, all statistics are cleared.
You can configure Oracle9iAS Web Cache to receive HTTPS browser requests and send HTTPS requests to the origin server. HTTPS uses the Secure Sockets Layer (SSL) to encrypt and decrypt user page requests as well as the pages that are returned by the origin server.
To configure HTTPS support, perform these tasks:
Wallets are needed to support the following HTTPS requests:
Each site requires at least one wallet. One wallet can be shared among all the Oracle9iAS Web Cache listening ports, or a separate wallet can be created for each Oracle9iAS Web Cache listening port.
To create a wallet, use Oracle Wallet Manager. Create the wallet as the following user:
OracleHOME_NAMEWebCache service on Windows operating systems
When the webcachectl or OracleHOME_NAMEWebCache service starts the cache server process, Oracle9iAS Web Cache opens the wallet as the webcachectl or the OracleHOME_NAMEWebCache service owner.
By default, wallets are stored in the following locations:
Oracle9iAS Web Cache attempts to open wallets at startup on Windows. On Windows, wallets are protected so that only the user that created them can open and use them. By default, Oracle9iAS Web Cache services are associated with the local system account, which does not have permission to open wallets.
To enable Oracle9iAS Web Cache to open wallets at startup:
On Windows NT, additionally grant the wallet administrator the right to run Oracle9iAS Web Cache as a service:
The User Manager window appears.
The User Rights Policy dialog box appears.
If Users does not exist, create it:
The User Manager window reappears.
To configure HTTPS protocol support between browsers and Oracle9iAS Web Cache:
The ports for these requests can share the same wallet as established for the Oracle9iAS Web Cache listening port in Step 1.
To configure HTTPS protocol support between Oracle9iAS Web Cache and origin servers:
The ports for these requests can share the same wallet as established for the Oracle9iAS Web Cache listening ports.
|
See Also:
|
You can restrict a URL or set of URLs for a site to permit only HTTPS requests.
To allow only HTTPS traffic for a URL or a set of URLs:
If all traffic must be restricted to HTTPS, enter "/" for the entire site.
This section describes additional configuration options available for deployments with two or more origin servers.
This section contains these topics:
For those requests that Oracle9iAS Web Cache cannot serve, you can distribute the requests over a set of origin servers with the Oracle9iAS Web Cache load balancing feature. To configure load balancing, you configure the capacity for each origin server.
When load balancing is configured and an origin server is no longer available, Oracle9iAS Web Cache automatically performs backend failover of the origin servers. Oracle9iAS Web Cache knows if an origin server is down when a failover threshold has been met.
An origin server can become unavailable if it is taken down for reconfiguration or there is a network or hardware failure. In these scenarios, Oracle9iAS Web Cache automatically distributes the load over the remaining origin servers and polls the failed origin server for its current up or down status until it is back online. Existing requests to the failed origin server result in errors. However, new requests are directed to the other origin servers. When the failed server returns to operation, Oracle9iAS Web Cache includes it in the load distribution.
|
See Also:
|
You can configure Oracle9iAS Web Cache to support origin server session binding, whereby a user session 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.
As long as the session information is contained within a session cookie or an embedded URL parameter, Oracle9iAS Web Cache can keep track of sessions between Web browsers and origin servers. A session cookie or an embedded URL parameter enables Oracle9iAS Web Cache to bind a particular user session to a specific origin server.
|
See Also:
"Session Binding" for an overview of origin server binding |
To configure Oracle9iAS Web Cache to support binding a user session to origin servers that are stateful:
The Session Binding page appears.
The Change/Add Session Binding dialog box appears.
If the sessions listed do not contain the definition you require, then choose Cancel to exit the Change/Add Session Binding dialog box. Continue to Step 5.
The Session/Personalized Attribute Definitions page appears.
The Create Session/Personalized Attribute Definitions page 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: Oracle9iAS 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 Oracle9iAS Web Cache to perform session binding on the session:
Oracle9iAS Web Cache uses the
See Also: |
Oracle Corporation recommends setting the value to a higher value than the inactivity timeout set for the Web site.
This section describes additional configuration options available for cache hierarchy deployments.
This section contains these topics:
"Cache Hierarchies" for an overview of cache hierarchies
See Also:
In a distributed cache hierarchy, the central cache stores content from application Web servers, and the remote cache stores content from the central cache. In a distributed cache hierarchy, the central caches acts as origin servers to the remote cache
To configure a distributed cache hierarchy, perform the tasks in "Setting Up Oracle9iAS Web Cache" for each cache. When performing the tasks, take special care to perform the following:
When content from the central cache becomes invalid, an invalidation message is sent to its cache. In addition, the central cache propagates the invalidation message to the remote caches.
Table 6-1 shows the example settings for the deployment depicted in "Deploying a Distributed Cache Hierarchy".
In an ESI cache hierarchy, a provider cache stores content from an ESI provider site, and a subscriber cache stores content from the origin servers for a local site and contacts provider caches for ESI fragments. In an ESI cache hierarchy, the provider caches acts as origin servers to the subscriber cache.
To configure an ESI cache hierarchy, perform the tasks in "Setting Up Oracle9iAS Web Cache" for each cache. When performing the tasks, take special care to perform the following:
When content from the provider cache becomes invalid, an invalidation message is sent to its cache. In addition, the provider cache propagates the invalidation message to the subscriber cache.
Table 6-2 shows the example settings for the deployment depicted in "Multiple Internal ESI Provider Sites".
To increase the availability and scalability of your Web site, you can configure multiple instances of Oracle9iAS Web Cache to run as members of a cache cluster.
To configure a cache cluster, you specify the general cluster information in the Cluster Configuration page of the Oracle9iAS Web Cache Manager and add two or more Oracle9iAS Web Cache instances to the cache cluster.
A cache cluster uses one configuration that is propagated from the current cache (the cache to which your browser is connected) to all cluster members. The configuration contains settings that are the same for all cluster members as well as cache-specific settings for each cluster member.
The following settings pertain to all members of a cluster:
The following settings are specific to the each member of the cluster:
Because a cache cluster contains two or more instances of Oracle9iAS Web Cache, you must have two or more instances of Oracle9iAS Web Cache installed on one or more nodes before you configure a cache cluster. The instances must be the same version of Oracle9iAS Web Cache.
To configure a cache cluster, perform these tasks:
Chapter 3, "Cache Clustering" for an overview of cache clusters
See Also:
To configure the settings for a cache cluster:
The Cluster Configuration page appears. The General Cluster Information section displays the default clusterwide values for failover and invalidation propagation. The Cluster Members table displays the current cache (the cache to which you are connected) as the only cluster member. Oracle9iAS Web Cache ignores the cluster information if there is only one cluster member.
The Change General Cluster Information dialog box appears.
Oracle9iAS Web Cache considers a request to another cache cluster member to have failed if:
500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable, or 504 Gateway Timeout messages
For each failed request, Oracle9iAS Web Cache increments the failure counter for that cluster member. This counter is kept separately by each cluster member. When a request is successfully processed by a cluster member, Oracle9iAS Web Cache resets the failure counter.
When the failover threshold is met, Oracle9iAS Web Cache considers the cache cluster member to have failed. Oracle9iAS Web Cache recalculates the relative capacity of the remaining cache cluster members. It then reassigns ownership of cache content.
When a cache cluster member is down, Oracle9iAS Web Cache starts polling the cache cluster member. It does this by sending requests to the URL specified in the Ping URL field. When Oracle9iAS Web Cache receives a success response from the cache cluster member, it considers that cache cluster member to be up again. It recalculates the relative capacity of the cache cluster members and it reassigns ownership of cache content.
Use a URL that you can guarantee is stored in each cache. The default is "/".
The Edit Cluster Member dialog box appears.
This field is used in two different ways:
The connections are used to receive requests for owned content from other cache cluster members. The number of connections are divided among the other cluster members. For example, in a three-cache cluster, if the capacity of Cache_A is 50, Cache_B can open 25 connections to Cache_A and Cache_C can open 25 connections to Cache_A.
More connections are used when another cache cluster member contains little or no data in its cache, such as when it is initially started, when it recovers from a failure, or after invalidation. During this time, the cluster member sends many of the requests to its peers, the owners of the content. In most cases, these requests are satisfied more quickly than requests to the origin server. Having a higher number of connections increases performance during this time and shortens the time it takes to fully load the cache. After a cache is fully loaded, fewer of the connections are used. There is no overhead for unused connections.
The capacity of a cache cluster member is weighted against the total capacity of all active cache cluster members. When you set the capacity, Oracle9iAS Web Cache assigns a percentage of the ownership array to the cluster member, indicating how much of the cached content will be owned by the cluster member. The percentage is calculated using the following formula:
cluster_member_capacity / total_capacity_of_all_active_cluster_members
For example, if cache cluster member Cache_A has a capacity of 100 and cache cluster member Cache_B has a capacity of 300, for a total capacity of 400, Cache_A is assigned 25 percent of the ownership array and Cache_B is assigned 75 percent of the ownership array. That means that Cache_A owns 25 percent of the cached content.
Note that in calculating the relative capacity, Oracle9iAS Web Cache considers the capacity of active cluster members; it does not consider the capacity of cluster members that it has determined to have failed.
In most cases, a capacity of 100 is a reasonable number to use as a starting point.
You now have one cache, the current cache, in the cluster. However, the cluster information is ignored until you have more than one Oracle9iAS Web Cache instance in the cluster.
Before you can add a cache to the cluster, the following conditions must be met:
To add another cache to the cluster:
The Cluster Configuration page appears.
The Add Cache to Cluster dialog box appears.
The administration port is the listening port for administrative requests.
Step 13 in "Task 1: Configure the Cache Cluster Settings" for more information about capacity
See Also:
The cache is now part of the cluster and is listed in the Cluster Member table.
Oracle9iAS Web Cache adds the cache-specific information from the new cache cluster members to the cluster configuration.
You can add more Oracle9iAS Web Cache instances to the cluster at any time by choosing Add. You can modify the settings for a cache cluster member by choosing Edit Selected. You can delete a cache cluster member, other than the current cache, by choosing Delete Selected.
When you modify the cluster and choose Apply Changes, Oracle9iAS Web Cache adds the cache-specific information from the new cache cluster members to the configuration. For those changes to take affect in all cluster members, you must propagate the configuration and restart the cache server process of the cluster members.
To propagate the configuration to new cluster members:
The Operations page appears. The Operation Needed column indicates the caches to which the configuration should be propagated.
(Alternatively, you can propagate the configuration to one cluster member at a time. Choose Selected cache in the Operate On field, and then choose Propagate.)
When the operation completes, the Operation Needed column in the Operations page indicates the cluster members that need to be restarted.
When the operation completes, the Operation Needed column in the Operations page indicates that no operations are needed. The cache cluster is ready to use.
|
 Copyright © 2002 Oracle Corporation. All Rights Reserved. |
|