RE: Strategies for splitting load across varnish instances? Andavoiding single-point-of-failure?

-Message d'origine- > It's probably simplest to paraphrase the code: > > Calculate hash over full complement of backends. > Is the selected backend sick > Calculate hash over subset of healthy backends Let's get back to consistent hashing and it's use... Correc

RE: hitrate at 1.00 but backend still getting traffic

> -Message d'origine- > I believe that, by default, Varnish does not cache a *response* that > contains Set-Cookie:, not a request containing Cookie:, as you said, > right? Both are not cacheable. Here is what's in the default vlc_recv : 57 if (req.http.Authorization || req.http

RE: hitrate at 1.00 but backend still getting traffic

> But if there is still traffic going to the backend I dont understand why the > hitrate is 1.00 Hitrate = number of hits/number of *cacheable* requests The requests you see going to the backend are non-cacheable requests. By default, varnish does not cache if a request contains a cookie. You

Understanding nukes & the expiration thread

If I understand correctly how varnish works : - the expiration thread (exp_timer) only checks the root of the binheap (= the oldest object currently in cache) - a worker needing to free some space in the cache will nuke (EXP_NukeOne) the least recently used object (not taking into account lru_tim

[PATCH] More varnish statistics

Varnish has already many useful statistics, but it lacks a few to be perfect. Here is a patch to add : - n_lru_inserted : number of objets inserted in the LRU (coupled with n_lru_nuked, it can be a nice way of monitoring cache storage usage) - esi_included : number of ESI includes found It als

RE : renaming varnish concepts...

+1 for some house-cleaning. - Speaking of bans, is grace used for "banned" objets ? If i "ban" an object, the first request will regenerate it from the back-end. Will following requests be getting the stale version during regeneration ? - For the CLI, why not add a "compatible mode" (inactive b

RE: 2.1 plans

Great news ! What about more ESI features (ie : cookie support), backend revalidation with conditional GETs or streaming fetches (http://varnish.projects.linpro.no/wiki/PostTwoShoppingList) ? Jean-François > -Message d'origine- > De : varnish-misc-boun...@projects.linpro.no > [mailt

Sharing VCL code ?

We all have some nice VCL snippets. It would be nice to have some way of sharing VCL code (some kind of "Varnish exchange") ! Jean-François Bustarret WAT - Responsable technique http://www.wat.tv ___ varnish-misc mailing list varnish-misc@projects.

RE: The revenge of the return of 1.1.2

Wonderful news ! Thanks DES JFB > -Message d'origine- > De : [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] De la part > de Dag-Erling Smørgrav > Envoyé : mardi 18 décembre 2007 18:22 > À : varnish-misc@projects.linpro.no > Objet : The revenge of the return of 1.1.2 > > Believe it o

RE: [varnish] Defining varnish + proposals for the FAQ page

> -Message d'origine- > In message > <[EMAIL PROTECTED]>, > "BUSTARRET, Jean-francois" writes: > > >How do I configure varnish to act like a classical reverse proxy ? > >[new] > > > >Here is a sample VCL to do this : [...] >

[varnish] Defining varnish + proposals for the FAQ page

As promised, here is a proposal for a new definition of what varnish is for the FAQ (links in <>, changes in bold, comments in []). I did compile some mails exchanged the last days on varnish-dev, credit for this goes to many people. My mother tongue not being english, there might be quite a fe

RE: Support Cache-Control no-cache/private as per RFC2616 ?

> -Message d'origine- > De : Dag-Erling Smørgrav [mailto:[EMAIL PROTECTED] > Documentation is always welcome. The wiki needs a lot of > work, and both Poul-Henning and I have far too much to do > (both with Varnish and other projects) to be able to spend > much time on it. I'll send s

RE: Support Cache-Control no-cache/private as per RFC2616 ?

L > config) in the direction that will allow us to actually > produce that decision tree, should be much easier and clearer. > > El Mar 20 Nov 2007, Dag-Erling Smørgrav escribió: > > "BUSTARRET, Jean-francois" <[EMAIL PROTECTED]> writes: > > > Yet http://v

RE: Support Cache-Control no-cache/private as per RFC2616 ?

"no-cache" - I am not using Cache-control: private), but two strpos-like would do the job, with less overhead. Jean-François > -Message d'origine- > De : [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] De la part > de Poul-Henning Kamp > Envoyé : lundi 19

Support Cache-Control no-cache/private as per RFC2616 ?

"If the no-cache directive does not specify a field-name, then a cache MUST NOT use the response to satisfy a subsequent request without successful revalidation with the origin server. This allows an origin server to prevent caching even by caches that have been configured to return stale respon