From the Session Binding Mechanism list, select a binding mechanism for the

Configuring High Availability Solutions 3-13 Web Cache. In addition, the respective passwords for the Oracle Web Cache administrator, and the invalidator user, invalidator, must be the same across the cluster members. If they are different, you must connect to the caches admin server and modify the administration password, as described in Section 5.2 .

3.6.2 Understanding Failover Threshold and Capacity Settings

To ease with configuration, take the time to understand the following key configuration settings for a cache cluster and its members: ■ Section 3.6.2.1, Failover Threshold for the Cache Cluster ■ Section 3.6.2.2, Capacity for Cache Cluster Members

3.6.2.1 Failover Threshold for the Cache Cluster

You set the failover threshold when you configure cache cluster properties. This setting reflects the number of allowed consecutive request failures before Oracle Web Cache considers another cache cluster member to have failed. In other words, Oracle Web Cache consecutively retries a failed member for certain number of times, before considering the cache-member as down. The number of times Oracle Web Cache is allowed to retry is termed as failover threshold. Oracle Web Cache considers a request to another cache cluster member to have failed if: ■ There are any network errors ■ The HTTP response status code is 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable, or 504 Gateway Timeout, or less than 100. For each failed request, Oracle 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, Oracle Web Cache resets the failure counter. When the failover threshold is met, Oracle Web Cache considers the cache cluster member to have failed. Oracle 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, Oracle Web Cache starts polling the cache cluster member. It does this by sending requests to the ping URL you specify. When Oracle 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.

3.6.2.2 Capacity for Cache Cluster Members

When you configure a cache cluster member, you specify capacity for that member. Oracle Web Cache uses capacity in two different ways: ■ As the absolute capacity for the number of concurrent incoming connections to this cache cluster member from all other cache cluster members. 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. 3-14 Oracle Fusion Middleware Administrators Guide for Oracle Web Cache 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 served 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. ■ As the relative capacity of the cache cluster member. The capacity of a cache cluster member is weighted against the total capacity of all active cache cluster members. When you set the capacity, Oracle Web Cache assigns a percentage of the ownership array to the cluster member, indicating how much of the cached content is to 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, Oracle 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. Set the initial capacity for each cache cluster member to 10 percent of the Maximum Incoming Connections setting. After you have a better idea of an applications capacity needs and hit rates, fine tune the capacity. If these two assumptions apply to your cache cluster, then apply the following formula to determine the capacity for each cluster member: 1. Incoming traffic is distributed equally to all the cache cluster members. 2. Ownership of content is distributed equally among all the cache cluster members. In the following formula, pick the highest value between the default value or the max_ incoming_connections formula: maxdefault_value, max_incoming_connections cacheable_misses100 number_ of_caches - 1 number_of_caches In the formula: ■ default_value is: – 100 for production environments – 30 for test environments – 0 for invalidation-only clusters When the capacity increases, the number of file descriptors needed by Oracle Web Cache also increases. See Section 3.6.7 for further information about invalidation-only clusters. ■ max_incoming_connections is the Maximum Incoming Connections setting from the Resource Limits page of Fusion Middleware Control.