1 Introduction to OracleAS Web Cache

Virtual Host Sites

Virtual host sites are sites hosted by OracleAS Web Cache. In other words, clients can request cached content from these sites through OracleAS Web Cache. Figure 1-3 shows OracleAS Web Cache caching content for two sites, www.1st.company.com and www.2nd.company.com. An additional mapping of www.*.company.com uses *, enabling additional virtual sites that map to host4 and host5 to be added. In addition to caching content, OracleAS Web Cache can also assemble ESI fragments from these sites.

Figure 1-3 Multiple Virtual Host Sites

Description of "Figure 1-3 Multiple Virtual Host Sites"

ESI Provider Sites

ESI provider sites are those sites that OracleAS Web Cache contacts for ESI assembly only. Browsers are not allowed to request content from these sites.

Figure 1-4 shows an ESI provider site configuration. In this configuration, OracleAS Web Cache receives a request for a page with ESI markup tags. OracleAS Web Cache sends the request to the application Web server. The application Web server uses an application to create a template page and sends it back to OracleAS Web Cache for assembly. OracleAS Web Cache includes the ESI fragments for the template page either with a cached copy of the contents or by contacting the following for that fragment's contents:

• Provider site www.providersite1.com

• Another OracleAS Web Cache server, which is caching content for www.providersite2.com

  
  

  See Also: "About Edge Side Includes (ESI) for Partial Page Caching" for further information about ESI

  
  

Figure 1-4 Multiple ESI Provider Sites

Description of "Figure 1-4 Multiple ESI Provider Sites"

Site Definitions and Site-to-Server Mappings

In order for OracleAS Web Cache to recognize a virtual host site or an ESI provider site, administrators need to perform the following steps:

1. Create a site definition that includes all the names and listening port numbers of the site that clients specify.

   If two sites share the same host name, specify a URL path prefix to distinguish the sites.

2. Determine if OracleAS Web Cache communicates with application Web servers or proxy servers.

   OracleAS Web Cache uses application Web servers for internal sites and proxy servers for external sites outside a firewall.

3. Specify the host name and listening port number of the application Web server or proxy server.

4. To ensure requests are sent to the appropriate server, map the site to the application Web servers or proxy servers.

5. Order the mappings. For each request, the first matching mapping is used.

   • Because mappings that use the wildcard * encompass a broader scope, give these mappings a lower priority than other mappings.

   • Because requests are resolved to the first matching mapping, give mappings that contain the optional URL path prefix a higher priority than those mappings without an URL path prefix.

     For example, you should order the following mappings as follows:

     http://www.company.com/portal/page?_pageid=33,4232&_dad=portal
     

     http://www.company.com/um/traffic_cop?mailid=inbox
     http://www.company.com
     
     

     If you instead reorder the mappings as follows, the request for URLs http://www.company.com/portal/page?_pageid=33,4232&_dad=portal and http://www.company.com/um/traffic_cop?mailid=inbox will never be reached. Requests for these URLs will instead resolve to http://www.company.com because it is listed first:

     http://www.company.com
     http://www.company.com/portal/page?_pageid=33,4232&_dad=portal
     http://www.company.com/um/traffic_cop?mailid=inbox
     
     

6. Create caching rules that apply to the site and global rules that apply to all sites.

   The site-specific caching rules are given a higher priority than the global rules.

To further understand the mappings, reconsider Figure 1-3. Web sites www.1st.company.com:80 and www.2nd.company.com:80 can have site aliases of 1st.company.com:80 and 2nd.company.com:80, respectively. The site to application Web server mappings are as follows:

• www.1st.company.com maps to application Web servers host1 and host2

• www.2nd.company.com maps to application Web servers host2 and host3

• www.*.company.com maps to host4 and host5

How OracleAS Web Cache Locates Application Web Severs or Proxy Servers

When OracleAS Web Cache receives a client request for an object, it determines the destination site using one of the following elements:

• Host request-header field from the request

• Host portion of the requested URL

• src attribute of the ESI <esi:include> tag

OracleAS Web Cache then looks up the configured site settings and mappings to determine if the site is supported, and the origin servers and caching rules for the site. If there are no site settings and mappings for external ESI provider sites, OracleAS Web Cache uses Domain Name System (DNS) to resolve the site name.

If the request does not include host information, then OracleAS Web Cache sends the request to the default site. The default site definition includes the site host name and port information. After an Oracle Application Server installation, a default site definition that includes the host name and listening port of the Oracle HTTP Server is established. If you choose to configure another site as the default site that includes a URL path prefix, the prefix is excluded in matching requests to the site. For example, if you specify a default site of www.company.com and a URL path prefix of /portal, requests are matched for www.company.com, not www.company.com/portal.

Surge Protection

OracleAS Web Cache passes requests for non-cacheable, stale, or missing objects to origin servers. To prevent an overload of requests on the origin servers, OracleAS Web Cache has a surge protection feature that enables you to set a limit on the number of concurrent requests that the origin servers can handle. When the limit is reached, subsequent requests are queued. If the queue is full, then OracleAS Web Cache rejects the request and serves a site busy error page to the client that initiated the request.

Stateless Load Balancing

Most Web sites are served by multiple origin servers running on multiple computers that share the load of HTTP and HTTPS requests. All requests that OracleAS Web Cache cannot serve are passed to the origin servers. OracleAS Web Cache balances the load among origin servers by determining the percentage of the available capacity, the weighted available capacity of each origin server. OracleAS Web Cache sends a request to the origin server with the most weighted available capacity. The weighted available capacity is determined by the following formula:

(Capacity - Load) / Capacity

where:

• Capacity is the maximum number of concurrent connections that the origin server can accept

• Load is the number of connections currently in use

If the weighted available capacity is equal for multiple origin servers, OracleAS Web Cache sends requests to the origin servers using round robin. With round robin, the first origin server in the list of configured servers receives the request, then the second origin server receives the second request. If the weighted available capacity is not equal, OracleAS Web Cache sends the request to the origin server with the most available capacity.

If the load of origin servers is equivalent, OracleAS Web Cache continues to use round robin, even when capacity is not equal for origin servers. Therefore, it is possible to see an even distribution of requests to origin server when the capacities are not configured to be the same.

To configure load balancing for a site, set the capacity of each origin server, and create one site-to-server mapping that maps all the applicable origin servers to the site.

Figure 1-7 shows two sites, www.company.com:80 and www.server.com:80. The site www.company.com:80 is supported by application Web servers company1-host and company2-host with capacities of 50 each. The site www.server.com:80 is supported by application Web servers server1-host, server2-host, and server3-host with capacities of 150, 50, and 50, respectively.

Figure 1-7 Load Balancing

Description of "Figure 1-7 Load Balancing"

Assuming all application Web servers have an initial load of 0, the requests to www.company.com:80 and www.server.com:80 will be distributed in the following manner:

• The requests to www.company.com:80 are distributed between the two origin servers using round robin.

  The requests to company1-host and company2-host will be distributed between the two origin servers so that they maintain an equal load. The first request is sent to company1-host. The second request is sent to company2-host if company1-host is still processing the first request. The third and subsequent requests are sent to the origin server that has the highest weighted available capacity.

  When the capacities are equal, OracleAS Web Cache uses round robin to distribute requests.

• The requests to www.server.com:80 are distributed between three origin servers using the weighted available capacity percentage.

  The first request to www.server.com:80 is sent to server1-host, because it is the first in the configured list. The second request is sent to server2-host, because server1-host is still processing the first request and has a weighted available capacity of 99.3 percent and server2-host has a weighted available capacity of 100 percent. The third request is sent to server3-host because server2-host is still processing a request and has a weighted available capacity of 98 percent and server3-host has a weighted available capacity of 100 percent. The fourth request is sent to server1-host because server2-host and server3-host are still processing requests and have weighted available capacities of 98 percent. The fifth request is sent to server1-host because its weighted available capacity is 98.6 percent, which is still greater than server2-host and server3-host, respectively.

  When the capacities and loads are not equal, OracleAS Web Cache uses the weighted available capacity to distribute requests. If requests were processed before new requests came in, then it is possible for all three origin servers to have loads of 0. In this case, OracleAS Web Cache uses round robin.

If you do not require caching support, you can configure OracleAS Web Cache solely as a software load balancer or reverse proxy. You configure OracleAS Web Cache settings for this mode, and replace the hardware load balancer with OracleAS Web Cache.

Backend Failover

After a specified number of continuous request failures, OracleAS Web Cache considers an origin server as failed. When an origin server fails, OracleAS 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, OracleAS Web Cache includes it in its weighted available capacity to load balance requests.

The failover feature is shown in Figure 1-8. An outage of server3-host, which had a capacity of 50, results in 75 percent of requests being distributed to server1-host and 25 percent request being distributed to server2-host.

Figure 1-8 Failover

Description of "Figure 1-8 Failover"

Session Binding (Stateful Load Balancing)

OracleAS Web Cache supports applications that use a session ID or session cookie to bind user sessions to a given origin server in order to maintain state for a period of time. To utilize the session binding feature, the origin server itself must maintain state, that is, it must be stateful. An application binds user sessions by including session data in the HTTP header or body it sends to a client in such a way that the client is forced to include it with its next request. This data is transferred between the origin server and the client through OracleAS Web Cache either with an embedded URL parameter or through a cookie, which is a text string that is sent to and stored on the client. OracleAS Web Cache does not process the value of the parameter or cookie; it simply passes the information back and forth between the origin server and the client.

Figure 1-9 shows how OracleAS Web Cache supports objects that use session binding.

Figure 1-9 Session Binding

Description of "Figure 1-9 Session Binding"

The steps for how session binding works for requests are as follows:

1. When a request first comes in, OracleAS Web Cache uses load balancing to determine to which origin server the request is forwarded. In this example, application Web server www.server2.com is selected.

2. If the requested object requires session binding, the origin server sends the session information back to the client through OracleAS Web Cache in the form of a cookie or an embedded URL parameter.

3. OracleAS Web Cache sends subsequent requests for the session to the origin server that established the session, bypassing load balancing. In this example, application Web server www.server2.com handles the subsequent requests.

To configure session binding:

1. Specify a session definition that specifies the name of session cookie or embedded URL parameter.

   You can also choose to use one of the default definitions, described in row Session Definitions of Table 8-1.

2. Specify session binding settings.

In a cache cluster, all cache cluster members must be able to determine which origin server established the session, although the request was routed originally through only one cache cluster member. To configure session binding in a cache cluster, you must enable the Session Binding cookie, which is specific to OracleAS Web Cache. OracleAS Web Cache generates the cookie, which tracks session information so that subsequent requests are bound to the origin server that established the session.