Conditional caching question

[Poul-Henning Kamp]

In message <FF7F8DE2-3EB5-408D-A918-90222591F9E1 at automattic.com>, Barry Abraham
son writes:
>On Jun 2, 2008, at 8:41 AM, Poul-Henning Kamp wrote:

>We do this on WordPress.com to avoid filling our caches with  
>infrequently requested data.  The way we handle it is when an object  
>reaches a certain req/sec threshold, we send a header from the backend  
>and then have varnish configured to only insert objects into the cache  
>which contain this custom header.  Based on phk's reply, I guess we  
>are using varnish in a somewhat backwards manner as well, since we  
>assume pass as the detault, insert as the exception.

Not at all, the "backwards" aspect was if Varnish was supposed to
be able to figure out when to start caching an object.

Having the backend tell Varnish what to cache and how long is
exactly how Varnish was designed to work.

>This used to work in 1.0.3.  I have started to look into upgrading to  
>trunk, and it doesn't seem to work so well anymore.  It looks like the  
>first time the URL is requested, if it is passed because it hasn't  
>reached that threshold and the header hasn't been set, all subsequent  
>requests are automatically "pass" ed.  These show up as "Cache hits  
>for pass" in varnishstat.  Any way around this?

When you do _not_ detect the magic header, set the TTL lower, that
controls how long time the "this should be passed" cache object
lives.

If that doesn't work, it's a bug.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.