Problem with varnish and caching

[Manuel Amador (Rudd-O)]

See my last e-mail to find out the hack I had to implement in order for
Varnish to sort of work on my site.

I moved from Squid to Varnish and got stumped by your default policy.
Squid accelerated static objects by default, cookies or no cookies.
Varnish doesn't.  Period.

It took me 15 minutes to install Squid, learn how to set it up as an
accelerator, and set it up.  It took me over two hours just to answer
the question "why isn't Varnish accelerating my site?", and over 15
minutes to configure it to act sensibly.  Doesn't look too well for your
product now, does it?

Now I'm going to state what up until now I've only been implying: your
default policy is braindead and stupid.  For 99% of your potential user
base (who tend to use these annoying little things called cookies),
Varnish by default won't accelerate squat -- it will, however, introduce
additional overhead.  The other 1% serving all-static content with no
cookies most probably doesn't need an accelerator anyway.

Let me say it again: the default policy is braindead and stupid.  It is
braindead and stupid because no large site (you know, the type of site
which actually needs acceleration) will run without a cookie-based
visitor tracking system, and as a consequence, Varnish won't accelerate
anything.

I suggest you alter your default VCL policy to roughly match Squid's:

- Cache everything cacheable with an adaptive TTL based on the
Last-Modified header.  Or 120s.  I don't care, but I'd prefer an
adaptive TTL -- old objects have low probability of being modified.
- Do not use a client's Cookie headers as a sign that an object should
be re-fetched from the backend.  Web applications that need to issue
fresh objects already implement either varying URLs or
Cache-Control/Pragma headers to instruct caches not to cache content.
- Anytime a client sends Cache-Control: no-cache headers, re-fetch the
content from the backend.
- Obey the backend's Cache-Control and Pragma no-cache headers.  Also
obey the Expires header.

You see, Squid at least *accelerates something* out-of-the-box.  In the
meantime, try not to advertise Varnish as an accelerator, when it
effectively isn't without heavy user intervention.

I'm tired of arguing with you guys over something that should have been
*obvious* for expert engineers who, in fact, have written a solid and
revolutionary piece of software.  It seems you're overlooking the
details, and regrettably in this case the devil *is* in the details.

Thanks for your time.

On dom, 2007-07-01 at 09:05 +0000, Poul-Henning Kamp wrote:
> Dear Manuel,
> 
> The Varnish *DEFAULT* VCL code implements what we have decided is a
> sensible default policy, which will Do The Right Thing for most people,
> at least to get them going with Varnish.
> 
> Your complaints all seem to center on the fact that the default
> VCL code doesn't work for you.
> 
> You seem to have overlooked the fact that you are not forced to
> run with the default VCL code.
> 
> Varnish is on track to offer the most comprehensive and flexible
> configuration mechanism yet to be seen on any web server or cache.
> 
> Now, instead of whining about the default, tailor Varnish to your
> situation.
> 
> Thankyou!
> 
> Poul-Henning
> 
	Manuel Amador (Rudd-O) <rudd-o at rudd-o.com>
	The R Zone - http://rudd-o.com/
	GPG key ID 0xC8D28B92 at http://wwwkeys.pgp.net/

Now playing, courtesy of Amarok: UB40 - Reggae music
Don't Worry, Be Happy.
		-- Meher Baba
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-misc/attachments/20070701/970a9ab6/attachment-0001.pgp>