code 206 - visible as '206' in varnishncsa and as '200' from VCL code

[Johnny Halfmoon]

> ]] Johnny Halfmoon
>
> Hi,
>
> | Well, to my understanding, the way I read out the delivery status is
> | already after vcl_deliver has run. The status collection routine is
> | called as follows for each backend:
> |
> | sub vcl_deliver {
> |     C{ STATS_UPDATE(www_somesitename_com) }C
> | }
> |
> | So at this point all delivery statusses (stati?) should be known to
> | Varnish. This setup has been running succesfully for several months
> | and it works for all codes except 206. Am I missing something here?
>
> Yes, the decision on whether to return 200 or 206 is done after
> vcl_deliver has run.
>
> | 'We' have a setup here where we have about 30 different sites, big and
> | small, all running of a cluster of 3 Varnish servers and log and graph
> | the returncodes and several other parameters of each site seperately.
> | Not having proper registration of the 206 codes does create a hole in
> | our logging, but it has not proven to be an issue yet, although we are
> | aiming to have this hole closed some time in the near future.
>
> Is there any particular reason why you're not using
> varnishlog/varnishncsa for this, rather than potentially slowing down
> the object delivery by doing it inline?

A good reason indeed: Having a bit of VCL code gather the per-site  
statistics (throughput, hit/miss count, delivery codes) and dumping a  
few lines of stats to syslog every 30 seconds causes much less load on  
the servers than having a script parse anywhere between 1.5 to  
3MB/second of logs per server.

The only not-so-nice bit of this setup is that the VCL code had to be  
made artificially thread-aware, and therefor a mutex is used to access  
the statistics structure, which happens once per access. At extremely  
high loads, with a large amount of workerthreads active, this might  
form a potential source of delay, although I doubt it will be very  
noticeable, as the amount of work done during the mutex-lock is  
extremely little.