Re: The future of ICP_OP_HIT_OBJ

here some figures which may help to make a decision.
First a short description of our configuration:
Two parent caches which are used by 10 client proxies of 'our' universities.
The parent caches don't serve (or just some) direct clients.
The parent caches are nodes of the COM-MESH experiment of Terenas TF-CACHE
connecting siblings for objects from '.com'.

A parent cache:
===============================================================================
# UDP-Request State Request % kByte % msec kB/sec
----------------------------------- ------- ------ -------- ------ ---- -------
HIT 170465 18.00 206777 79.45 2.02 598.97
 UDP_HIT 117614 12.42 7533 2.89 2.04 31.27
 UDP_HIT_OBJ 52851 5.58 199243 76.56 1.97 1909.87
MISS 776561 82.00 53477 20.55 2.38 28.86
 UDP_MISS 772086 81.53 53175 20.43 2.38 28.89
 UDP_DENIED 4475 0.47 302 0.12 2.68 25.20
----------------------------------- ------- ------ -------- ------ ---- -------
Sum 947026 260255 2.32 118.40

# UDP-Requests Request kByte
----------------------------------- ------- ------ --------
Siblings 349670 120540
Clients (Child-proxy) 597356 139715
----------------------------------- ------- ------ --------
Sum 947026 260255

# TCP-Request State Request % kByte % sec kB/sec
----------------------------------- ------- ------ -------- ------ ---- -------
HIT 71142 26.48 629535 19.78 1.27 6.96
 TCP_HIT 38624 14.38 486260 15.28 0.77 16.15
 TCP_REFRESH_HIT 18949 7.05 132243 4.15 2.66 2.62
 TCP_IMS_HIT 13388 4.98 7792 0.24 0.20 2.78
 TCP_REF_FAIL_HIT 181 0.07 3239 0.10 39.3 0.45
MISS 192875 71.80 2255632 70.86 5.04 2.32
 TCP_MISS 140950 52.47 2039366 64.07 5.56 2.60
 TCP_CLIENT_REFRESH 38472 14.32 107595 3.38 3.13 0.89
 TCP_REFRESH_MISS 13444 5.00 108666 3.41 5.06 1.60
 TCP_IMS_MISS 9 0.00 3 0.00 3.51 0.12
ERROR 4620 1.72 298018 9.36 3672 0.02
----------------------------------- ------- ------ -------- ------ ---- -------
Sum 268637 3183186 67.4 0.18

# external Fetches (.com only)
Type Neighbor Request % Hit-% kByte % Hit-% sec kB/sec
------------------------- ------- ----- ----- -------- ----- ----- ---- -------
DIRECT 177333 91.94 2075338 92.01 5.40 2.16
SIBLING 15542 8.06 180293 7.99 0.95 12.18
    TCP 2722 1.41 130647 5.79 2.31 20.70
    UDP 12820 6.65 49645 2.20 0.66 5.84
------------------------- ------- ----- ----- -------- ----- ----- ---- -------
Sum 192875 2255632 5.04 2.32

        
A client proxy:
===============================================================================
# TCP-Request State Request % kByte % sec kB/sec
----------------------------------- ------- ------ -------- ------ ---- -------
HIT 955587 37.16 4892012 26.78 1.85 2.76
 TCP_HIT 661966 25.74 4501239 24.64 1.20 5.63
 TCP_IMS_HIT 257360 10.01 82423 0.45 0.70 0.46
 TCP_REFRESH_HIT 35734 1.39 306095 1.68 4.25 2.01
 TCP_REF_FAIL_HIT 527 0.02 2254 0.01 1209 0.00
MISS 1524576 59.28 12828773 70.22 5.17 1.62
 TCP_MISS 1217864 47.36 11555083 63.25 5.53 1.71
 TCP_CLIENT_REFRESH 158456 6.16 517581 2.83 3.94 0.83
 TCP_REFRESH_MISS 148256 5.76 756108 4.14 3.56 1.43
ERROR 91565 3.56 547609 3.00 108. 0.06
----------------------------------- ------- ------ -------- ------ ---- -------
Sum 2571728 18268395 8.30 0.86

# external Fetches
Type Neighbor Request % Hit-% kByte % Hit-% sec kB/sec
------------------------- ------- ----- ----- -------- ----- ----- ---- -------
DIRECT 453051 29.72 3326477 25.93 4.63 1.58
PARENT 1071525 70.28 29.80 9502295 74.07 14.08 5.41 1.64
    TCP 902571 59.20 8965101 69.88 6.29 1.58
    UDP 168954 11.08 537194 4.19 0.70 4.53
------------------------- ------- ----- ----- -------- ----- ----- ---- -------
Sum 1524576 12828773 5.17 1.62

I try to make a short interpretation (any comments are welcome).

# UDP-Request State Request % kByte % msec kB/sec
----------------------------------- ------- ------ -------- ------ ---- -------
UDP_HIT_OBJ 52851 5.58 199243 76.56 1.97 1909.87
Is impressive - but it's the view of the server.
From the clients view it's not so spectacular anymore:
Type Neighbor Request % Hit-% kByte % Hit-% sec kB/sec
------------------------- ------- ----- ----- -------- ----- ----- ---- -------
PARENT 1071525 70.28 29.80 9502295 74.07 14.08 5.41 1.64
    TCP 902571 59.20 8965101 69.88 6.29 1.58
    UDP 168954 11.08 537194 4.19 0.70 4.53

SIBLING 15542 8.06 180293 7.99 0.95 12.18
    TCP 2722 1.41 130647 5.79 2.31 20.70
    UDP 12820 6.65 49645 2.20 0.66 5.84

My feeling is that HIT_OBJ is problematic for different reasons and
I'm glad to have soon the possiblity to use persistent HTTP connections
between proxies.
An other idea is to test a beta version of squid without HIT_OBJ but
with persistent connections in a real environment and to compare the
results with the configuration using HIT_OBJ without persistent connections.

Ernst

On Tue, 18 Nov 97 15:39:04 -0800 Duane Wessels wrote:
> I'd like to get an idea of to what extent people think the ICP HIT_OBJ
> feature is a good idea to continue supporting. Briefly, HIT_OBJ means
> that we include the actual object data inside an ICP HIT reply
> message. HIT_OBJ has caused problems with Squid-1.1 because ICP is
> treated differently than HTTP, namely ICP does not have certain request
> headers such as Cache-Control and Authorization. See
> http://squid.nlanr.net/Squid/FAQ/FAQ-10.html#ss10.12 for more details.
>
> There are a number of factors to consider in deciding if HIT_OBJ
> is a good thing. For example:
>
> - ICP is sent over UDP. UDP does NOT have flow-control
> and could cause congestion.
>
> - Fragmentation of UDP is considered harmful. If a single
> fragment is lost, the entire datagram is lost.
>
> - Many Web objects are small. According to yesterday's log for
> sv.cache, 50% of HTTP "200" replies are 3715 bytes or less.
> 25% are 1475 bytes or less. If we consider ALL replies,
> including "304 Not Modified", then 50% of replies are 2006
> bytes or less. Larger ICP message are probably more likely
> to suffer fragmentation and/or packet loss, but the actual
> chances will depend on path congestion between neighbor
> caches.
>
> - HTTP/1.1 should eliminate concerns over TCP slow start.
> Neighbor caches should utilize numerous, persistent
> connections.
>
> - An ICP HIT_OBJ message will take longer to generate, if the
> object data must be read from disk. A regular ICP HIT
> can be returned immediately.
>
> Given these points, should we keep HIT_OBJ around, or rather just let
> HTTP/1.1 handle it?
Received on Wed Nov 19 1997 - 01:43:29 MST