Using a shared cache
Cache sharing allows each cache to share its contents with the other caches and avoid duplicate caching.
It is common for a point of presence on the web to have more traffic than a single server can handle. One solution is to add more servers. However, when multiple caching proxy servers are used, the contents of one cache often overlap with the contents of the other caches. In addition to unnecessary redundancy in storage, maximum bandwidth savings are not achieved because a cached file is refetched from the origin server when a request for it comes to a proxy server that does not have that file in its own cache. Although duplicate caching can be minimized by using a hierarchical chain of proxy servers, this scenario still results in more traffic through a server, and each additional link in the chain adds latency.
- Objects are not fetched multiple times.
- The larger, combined logical cache yields a higher hit rate.
- Remote Cache Access (RCA) is a feature of Caching Proxy that defines an array of member caches. A file is stored in exactly one of these caches that are based on internal logic.
- A Caching Proxy plug-in is provided to allow the proxy server to use the Internet Caching Protocol (ICP). You might use the ICP plug-in instead of RCA if you want to share data between Caching Proxy machines and non-Caching Proxy caches.
Remote cache access
- The participating proxy servers need to be close to one another and connected with high-bandwidth links (for example, FDDI, SP2 bus).
- Membership in the RCA array needs to be long-term so that the configuration is as stable as possible.
- Proxy servers need to have similar capabilities (for example, CPU, memory size, cache size).
- Network outages must be infrequent.
- There need to be fewer than 100 members in any array.
- All members of the array must use the same version of the Caching Proxy software.
Note: If the proxies in the RCA array use different Linux operating systems (for example, SUSE and Red Hat), ensure that your nobody user has the same UID on all its peers. Check the password and group file entries in the /etc/ directory on each computer and assign the same UID to nobody.
Remote cache access is not appropriate if any of these conditions are violated or if different organizations manage different servers that are members of the array.
Configuring remote cache access
To configure remote cache access, in the Configuration and Administration forms, select Cache Configuration –> Remote Cache Access. The fields in this form define a named array that shares one logical cache. Enter the required information for each member of the array.
Configuring the Internet Caching Protocol plug-in
The Internet Caching Protocol plug-in enables a Caching Proxy to query ICP-compliant caches in search of HTML pages and other cacheable resources. When the proxy server receives an HTTP request, it searches its own cache for the resource. If the resource is not found in the local cache and the ICP plug-in is enabled, the proxy server encapsulates the URL request in an ICP query packet and then delivers this packet to all identified ICP peer caches. If a peer cache responds that it has the resource, the proxy server retrieves the resource from that peer's cache. If two or more peers respond positively, the first response is processed. If no peers respond with hits, the original server continues to process the request according to its workflow. For example, the proxy server can start another plug-in, continue to the Remote Caching Access routine (if RCA is enabled), or retrieve the requested resource itself.
Configuring the ICP plug-in
- For Caching Proxy to function as an ICP server, use the ServerInit directive to call the icpServer module.
- For Caching Proxy to function as an ICP client, use the PreExit directive to call the icpClient module.
- For Caching Proxy to function as both an ICP client and ICP server, use both directives.
- Use the directives icpAddress, icpMaxThreads, icpPeer, icpPort, and icpTimeout to configure the settings that the plug-in uses.
Prototype directives (in the form of comments) are added to the API section of the ibmproxy.conf file. These API directives are in a purposeful order. When adding API directives to enable new features and plug-in modules, order the directives as shown in the prototype section of the configuration file. Alternatively, uncomment and edit, if necessary, API directives to include support for each wanted function or plug-in.
Both the ServerInit and the PreExit directives have two arguments: (1) the fully qualified path of the shared library and (2) the function call. These arguments are delimited by a colon (:). The first argument is system-specific and depends on where the plug-in components are installed. The second argument is hardcoded into the shared library and must be typed exactly as shown.
ServerInit path_of_shared_library:icpServer
Linux
and UNIX example: ServerInit /opt/ibm/edge/cp/internet/lib/plugins/icp/libicp_plugin.so:icpServer
Windows
example: ServerInit C:\Program Files\IBM\edge\cachingproxy\cp\Bin\plugins\icp\icpplugin.dll:icpServer
PreExit path_of_shared_library:icpClient
Linux
and UNIX example: PreExit /opt/ibm/edge/cp/internet/lib/plugins/icp/libicp_plugin.so:icpClient
Windows
example: PreExit C:\Program Files\IBM\edge\cachingproxy\cp\Bin\plugins\icp\icpplugin.dll:icpClient
- ICP_Address — Specify IP address for ICP queries
- ICP_MaxThreads — Specify maximum threads for ICP queries
- Occupier — Specify a member of an ICP cluster
- ICP_Port — Specify port number for ICP queries
- ICP_Timeout — Specify maximum wait time for ICP queries
- PreExit — Customize the PreExit step
- ServerInit — Customize the Server Initialization step