Zope and Squid with ICP

Created by . Last modified on 2003/08/01.

Overview

This HowTo describes the use of ICP, useful when Zope is used behind Squid as described in this HowTo. This arrangement has Squid treating Zope (or multiple instances of Zope) as if they were peer caches. Specifically, using ICP. ICP allows Squid's load balancing, redundancy, and peer selection features to be exploited in a Zope/ZEO cluster.

Author: Toby Dickenson. [email protected].

But Why?

The obvious question is, why bother with this trickery? Since being part of a cache mesh is squid's commonest commercial configuration, it provides several nice features for managing that mesh. Most of these are derived from the ICP protocol, described in RFC 2186. This is a small lightweight protocol, and a simple implementation of it within Zope means Zope can exploit Squid's Cache Mesh features:

1. Squid knows that communicating with peers (possibly at nearby ISPs) is not 100% reliable, and uses ICP to detect dead or unreliable peers. We can (ab)use this feature to smoothly bring down a Zope server without interrupting service.
2. Squid can use ICP to choose the fastest peer. We can (ab)use that feature to provide load balancing. That is, to distribute load evenly across our zope servers.

3. A code in the ICP response allows peers to state that they are particularly efficient at handling that request; an ICP_HIT code, rather than ICP_MISS. When Squid is acting as a peer it will send a HIT if it already has that URL in cache. But what happens when zope is acting as a peer....

When does Zope say ICP_HIT?

This depends on your application, and will require some coding of a function to determine the response based on the URL. The function has to be fast, so there is no time to invoke Zope's full URL traversal machinery. Since this is really only an optimisation, it doesnt matter if this function occasionaly comes to the wrong conclusion for some unusal URLs.

Some examples applications are:

• Maybe some published methods are particularly processor-intensive, and one machine has a particularly fast processor. That one machine might say ICP_HIT based on a regex that detects URLs that look like they might call the processor-intensive method.
• If some pages in your application need encryption, and some but not all of your zope servers have a hardware encryption capability. On those machines you might say ICP_HIT based on a regex that detect URLs that look like they will need encryption.
• If some methods require a large persistent object that will take a long time to transfer from the ZEO server, you might say ICP_HIT if that object is already in the ZEO cache.
• If some methods require an object that will take a long time to unpickle, you might want to say ICP_HIT if that object is already in the ZODB cache.
• If some methods require a resource that it temporarily unavailable (maybe the disk is full) then you might say ICP_MISS_NOFETCH.

The first two of these examples are not the best use of ICP. ICP involves an overhead on every request, and those first two could be better solved using a static approach.

The second three are very good uses of ICP

But I dont want to do any coding!

You dont need to, if all you need is simple load balancing. See point 2 above and read this HowTo.

How well does it work?

Since November 2001 I have been using ICP to distribute requests across a 3 node ZEO network. I have several objects that take a long time to unpickle, and take up much memory when unpickled. Therefore I am using load-clustering code which returns ICP_HIT if the url refers to such an object which is already in memory. This is effective at ensuring that each object is normally only loaded into one of the three servers at any one time.

Latency does not seem to be a problem; Squid reports that mean ICP round-trip time is less than 1ms. The ZEO nodes are 1 network hop away from squid.

Where do I get ICP support?

This feature is included as standard in Zope 2.6.

For earlier versions it is available as a patch at http://www.zope.org/Members/htrd/icp/ and http://collector.zope.org/Zope/150 (The second of these is to avoid performance problems relating to persistent http connections)