Re: calculate saving ratio of *link bandwidth*

> You're asking how to reconcile an IP/octet count such as SNMP counts on
> interfaces, or netflow/netramet/nnstat counts, against the applications
> only view?

  I'm trying to find how many link bandwidth saved via transparent proxy.

  By simple looking, I made MRTG for traffic served. The method is followings.

    1. I got the total transaction bytes and hit bytes in real-time by
       analysing squid log.
    2. I made MRTG graph, because I want to get similar result like router box.
    3. I investigate the traffic of output interface connected with
       transparent cache(s).
    
    (2) The result is: <-- real sample (5 minute sample)
          Total: 400 kbps
          Hit bytes: 180 kbps

    (3) The traffic is: 1400 kbps

  1400 kbps contains "request traffic to real web servers from cache", but
  I think that traffic is small.

  So *roughly* speaking the *IP/TCP/HTTP* overhead is *nearly* double or
  *triple* than *the result via squid log*.

  It is not 10%, but nearly <100 %.

  All back-ward "ACK"(it contains no data, only overhead) and all packet
  has 40+ bytes (IP head + TCP head). I'm not sure, but the requests of
  HTTP header were sent by lines.

  I'll get more detail statistics from NetFlow soon.

  --Thanks for your reply.

  --J

>
> Thats around 10% isn't it? similar in fact to the back-channel load of
> ACK and the initial request, if you are a fetch-pays customer on a network
> and serve outbound (uncharged) data in terms of what you pay.
>
> Why similar? because the majority of the back=data is pure ACK and other TCP
> overhead so its within an order of scale to the overheads on top of the served
> data.
>
> DNS adds a bit more. If you don't do DNS, you save traffic.
>
> This is an intersting area. We're running a mirror (the cousin to a cache)
> and we notice marked parallels in the curve-shapes between bothe methods
> of count, but clear differences too!
>
> Anyway, I'd suggest you do some monitoring like netflow/snmp/nnstat/netramet
> to get your handle on the overhead costs of TCP+FTP and TCP+HTTP and then
> use the hitrate, and measured object size to determine the overall packet
> savings.
>
> -George
>
Received on Fri Jun 12 1998 - 05:39:04 MDT