(no-digest -> no-query) incompatible with keep-alive?

Having run for just over two weeks after converting some peers from
"no-digest" to "no-query" (ie., using cache digests exclusively, no ICP), it's
clear that something's "not quite right" on the persistent connection side of
Squid when using CDs as opposed to ICP for peering (maybe it's just my
expectations/understanding - either way I could use an explanation or
confirmation/denial from other experiences).

For example:

  Sibling : peer-host-fqdn/tcp-portA/udp-portA
  Flags : no-digest
  Address[0] : peer-host-ip
  Status : Up
  AVG RTT : 6 msec
  LAST QUERY : 1 seconds ago
  LAST REPLY : 1 seconds ago
  PINGS SENT : 817487
  PINGS ACKED: 807980 99%
  FETCHES : 47001 6%
  IGNORED : 58084 7%
  Histogram of PINGS ACKED:
           ICP_HIT : 53236 7%
          ICP_MISS : 754744 93%
  keep-alive ratio: 96%

  Sibling : peer-host-fqdn/tcp-portB/udp-portB
  Flags : no-query
  Address[0] : peer-host-ip
  Status : Up
  AVG RTT : 0 msec
  LAST QUERY : 933488703 seconds ago
  LAST REPLY : 933488703 seconds ago
  PINGS SENT : 0
  PINGS ACKED: 0 0%
  FETCHES : 74410 0%
  IGNORED : 0 0%
  Histogram of PINGS ACKED:
  keep-alive ratio: 48%

Note, these are one-and-the-same host (two copies of Squid on different
ports), yet keep-alive ratio is so much lower on the CD-only peer compared to
the ICP-only peer. 754,744 is a lot of ICP queries to be wasted (ICP_MISS) so
I'd like to move that over to CDs too - but I'm unhappy at the (apparent) loss
of persistent connections (which, on the server end, has in the past reached
well beyond 3,000 queries on a single connection).

Is it a simple case of fewer HTTP connections (object in peer cache but not
visible in digest), or something more sinister?

Any ideas?

dave
Received on Sun Aug 01 1999 - 00:35:58 MDT