From kradziszewski at gmail.com  Sat Sep  1 19:17:29 2007
From: kradziszewski at gmail.com (Kamil Radziszewski)
Date: Sat, 1 Sep 2007 21:17:29 +0200
Subject: Varnish on Solaris
Message-ID: <231965b00709011217u44c90c14t225d3ebdaa8a458@mail.gmail.com>

Can I run Varnish on Solaris 10 ?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20070901/a0a74062/attachment.html>

From optilude at gmx.net  Sat Sep  1 21:48:42 2007
From: optilude at gmx.net (Martin Aspeli)
Date: Sat, 01 Sep 2007 22:48:42 +0100
Subject: Varnish on Solaris
In-Reply-To: <231965b00709011217u44c90c14t225d3ebdaa8a458@mail.gmail.com>
References: <231965b00709011217u44c90c14t225d3ebdaa8a458@mail.gmail.com>
Message-ID: <fbcmof$b9a$2@sea.gmane.org>

Kamil Radziszewski wrote:
> Can I run Varnish on Solaris 10 ?

Have you tried?

Download, compile, install ... if it works, the answer is probably 
"yes". ;-)

Martin

-- 
Acquisition is a jealous mistress



From chulmin2 at hotmail.com  Sat Sep  1 23:58:54 2007
From: chulmin2 at hotmail.com (Monty Ree)
Date: Sat, 01 Sep 2007 23:58:54 +0000
Subject: why purge makes child process restart?
In-Reply-To: <3738.1188543607@critter.freebsd.dk>
Message-ID: <BLU116-F54FAED96DBC408BD5A51E85CF0@phx.gbl>

Thanks for your help..

Can you give us temporary vcl or urgent patch which drop the GET, HEAD or 
purge request which is not including Host header?


Thanks again..


>From: "Poul-Henning Kamp" <phk at phk.freebsd.dk>
>To: "Monty Ree" <chulmin2 at hotmail.com>
>CC: des at linpro.no, varnish-misc at projects.linpro.no
>Subject: Re: why purge makes child process restart? 
>Date: Fri, 31 Aug 2007 07:00:07 +0000
>
>You're right, I'll fix.
>
>--
>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.

_________________________________________________________________
?? ?? ?? ??? ?????? MSN ???? ?????. 
http://fortune.msn.co.kr/ 



From phk at phk.freebsd.dk  Sun Sep  2 07:38:02 2007
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Sun, 02 Sep 2007 07:38:02 +0000
Subject: why purge makes child process restart? 
In-Reply-To: Your message of "Sat, 01 Sep 2007 23:58:54 GMT."
	<BLU116-F54FAED96DBC408BD5A51E85CF0@phx.gbl> 
Message-ID: <4848.1188718682@critter.freebsd.dk>

In message <BLU116-F54FAED96DBC408BD5A51E85CF0 at phx.gbl>, "Monty Ree" writes:
>Thanks for your help..
>
>Can you give us temporary vcl or urgent patch which drop the GET, HEAD or 
>purge request which is not including Host header?

This is what you need:

	http://varnish.projects.linpro.no/changeset/1930

-- 
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.


From kradziszewski at gmail.com  Sun Sep  2 19:03:12 2007
From: kradziszewski at gmail.com (Kamil Radziszewski)
Date: Sun, 02 Sep 2007 21:03:12 +0200
Subject: Varnish on Solaris 10
Message-ID: <46DB08F0.6000001@gmail.com>

Yes, I tried but the make progess failed. I'm asking becasue i don't 
know if this is MY mistake or Solaris is simply not supporting by varnish.


From chulmin2 at hotmail.com  Mon Sep  3 02:16:25 2007
From: chulmin2 at hotmail.com (Monty Ree)
Date: Mon, 03 Sep 2007 02:16:25 +0000
Subject: why purge makes child process restart?
In-Reply-To: <4848.1188718682@critter.freebsd.dk>
Message-ID: <BLU116-F474643476486D344A68E585C90@phx.gbl>

So thanks and so sorry for bothering you.
But my varnish is 1.1.1 not trunk, and I don't know how to fix at 1.1.1.
version 1.1.1 has no file related cache_backend_simple.c 

Please give me a solution for the version 1.1.


Thanks for your help again.


>From: "Poul-Henning Kamp" <phk at phk.freebsd.dk>
>To: "Monty Ree" <chulmin2 at hotmail.com>
>CC: des at linpro.no, varnish-misc at projects.linpro.no
>Subject: Re: why purge makes child process restart? 
>Date: Sun, 02 Sep 2007 07:38:02 +0000
>
>In message <BLU116-F54FAED96DBC408BD5A51E85CF0 at phx.gbl>, "Monty Ree" 
writes:
> >Thanks for your help..
> >
> >Can you give us temporary vcl or urgent patch which drop the GET, HEAD 
or
> >purge request which is not including Host header?
>
>This is what you need:
>
>	http://varnish.projects.linpro.no/changeset/1930
>
>--
>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.

_________________________________________________________________
??? ???? ?? 1G ?? ??! 
http://im.msn.co.kr/new/function/function_02_11.asp 



From james at nyi.net  Mon Sep  3 06:27:39 2007
From: james at nyi.net (james)
Date: Mon, 03 Sep 2007 02:27:39 -0400
Subject: why purge makes child process restart?
In-Reply-To: <BLU116-F474643476486D344A68E585C90@phx.gbl>
References: <BLU116-F474643476486D344A68E585C90@phx.gbl>
Message-ID: <46DBA95B.3010602@nyi.net>

Monty Ree wrote:
> So thanks and so sorry for bothering you.
> But my varnish is 1.1.1 not trunk, and I don't know how to fix at 1.1.1.
> version 1.1.1 has no file related cache_backend_simple.c 
>
> Please give me a solution for the version 1.1.
>   

I imagine that you're best bet would be to run varnish from trunk
(http://varnish.projects.linpro.no/wiki/Installation).

-- james




From des at linpro.no  Mon Sep  3 08:58:12 2007
From: des at linpro.no (=?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?=)
Date: Mon, 03 Sep 2007 10:58:12 +0200
Subject: why purge makes child process restart?
In-Reply-To: <BLU116-F54FAED96DBC408BD5A51E85CF0@phx.gbl> (Monty Ree's message
	of "Sat, 01 Sep 2007 23:58:54 +0000")
References: <BLU116-F54FAED96DBC408BD5A51E85CF0@phx.gbl>
Message-ID: <ujr642sunvf.fsf@false.linpro.no>

"Monty Ree" <chulmin2 at hotmail.com> writes:
> Can you give us temporary vcl or urgent patch which drop the GET, HEAD
> or purge request which is not including Host header?

vcl_recv() {
    if (!req.http.host) {
        error 400 "No Host: header";
    }
}

DES
-- 
Dag-Erling Sm?rgrav
Senior Software Developer
Linpro AS - www.linpro.no


From red5 at klaus.dk  Sun Sep  2 13:35:13 2007
From: red5 at klaus.dk (Klaus)
Date: Sun, 02 Sep 2007 15:35:13 +0200
Subject: Caching pages with cookies - feature request
Message-ID: <46DABC11.9090608@klaus.dk>

Hello List,


Could it be possible to cache pages per cookie values?

Example.

http://www.host.dk/page1?var=value1   (cookie: selection=1,2,3,4)

A object with url http://www.host.dk/page1?var=value1 with that cookie 
would be cached .
Then, when the next time another user with same cookie, he gets the 
cached version.

Also if a unique user session is set in a cookie. Then the user will not 
get another users cached page, but only his own.
For example, if its a user who likes to hit reload button many times. 
Pages with usersession would usually be cached for a few minutes.


Then you can use the vcl to make exceptions to what urls that shoult not 
be cached.  ex. when reload a mailbox page.

/Klaus





From phk at phk.freebsd.dk  Mon Sep  3 09:04:17 2007
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Mon, 03 Sep 2007 09:04:17 +0000
Subject: Caching pages with cookies - feature request 
In-Reply-To: Your message of "Sun, 02 Sep 2007 15:35:13 +0200."
	<46DABC11.9090608@klaus.dk> 
Message-ID: <77980.1188810257@critter.freebsd.dk>

In message <46DABC11.9090608 at klaus.dk>, Klaus writes:
>Hello List,
>
>
>Could it be possible to cache pages per cookie values?
>
>Example.
>
>http://www.host.dk/page1?var=value1   (cookie: selection=1,2,3,4)

Yes, just add the cookie header to the hash string in vcl_hash():

	sub vcl_hash {
		set req.hash += req.http.cookie;
	}


Poul-Henning

-- 
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.


From des at linpro.no  Mon Sep  3 09:04:32 2007
From: des at linpro.no (=?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?=)
Date: Mon, 03 Sep 2007 11:04:32 +0200
Subject: why purge makes child process restart?
In-Reply-To: <46DBA95B.3010602@nyi.net> (james@nyi.net's message of "Mon, 03
	Sep 2007 02:27:39 -0400")
References: <BLU116-F474643476486D344A68E585C90@phx.gbl>
	<46DBA95B.3010602@nyi.net>
Message-ID: <ujrsl5wt90f.fsf@false.linpro.no>

james <james at nyi.net> writes:
> I imagine that you're best bet would be to run varnish from trunk
> (http://varnish.projects.linpro.no/wiki/Installation).

That might not be a good idea, considering the pace of development on
trunk.

DES
-- 
Dag-Erling Sm?rgrav
Senior Software Developer
Linpro AS - www.linpro.no


From des at linpro.no  Mon Sep  3 09:04:53 2007
From: des at linpro.no (=?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?=)
Date: Mon, 03 Sep 2007 11:04:53 +0200
Subject: Varnish on Solaris
In-Reply-To: <231965b00709011217u44c90c14t225d3ebdaa8a458@mail.gmail.com>
	(Kamil Radziszewski's message of "Sat, 1 Sep 2007 21:17:29 +0200")
References: <231965b00709011217u44c90c14t225d3ebdaa8a458@mail.gmail.com>
Message-ID: <ujrodgkt8zu.fsf@false.linpro.no>

"Kamil Radziszewski" <kradziszewski at gmail.com> writes:
> Can I run Varnish on Solaris 10 ?

Currently, no.

DES
-- 
Dag-Erling Sm?rgrav
Senior Software Developer
Linpro AS - www.linpro.no


From des at linpro.no  Mon Sep  3 09:05:37 2007
From: des at linpro.no (=?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?=)
Date: Mon, 03 Sep 2007 11:05:37 +0200
Subject: Caching pages with cookies - feature request
In-Reply-To: <46DABC11.9090608@klaus.dk> (red5@klaus.dk's message of "Sun, 02
	Sep 2007 15:35:13 +0200")
References: <46DABC11.9090608@klaus.dk>
Message-ID: <ujrk5r8t8ym.fsf@false.linpro.no>

Klaus <red5 at klaus.dk> writes:
> Could it be possible to cache pages per cookie values?

Yes, simply add the cookie header to the hash string.

DES
-- 
Dag-Erling Sm?rgrav
Senior Software Developer
Linpro AS - www.linpro.no


From janis.putrams at delfi.lv  Tue Sep  4 09:59:33 2007
From: janis.putrams at delfi.lv (Janis Putrams)
Date: Tue, 4 Sep 2007 12:59:33 +0300
Subject: why purge makes child process restart?
In-Reply-To: <4848.1188718682@critter.freebsd.dk>
References: <4848.1188718682@critter.freebsd.dk>
Message-ID: <200709041259.33361.janis.putrams@delfi.lv>

Hi!

Thanks for the bugreport and for the fix. No child restarts after the vcl fix 
so far.

Checked out revision 1934 from the trunk but sending request with no Host 
still crashes the slave process.
Adding
 if (!req.http.host) {
? ? ? ? error 400 "No Host: header";
? ? }

works though.

Maybe that's because I chose backend based on the Host header:
sub vcl_recv {
        if (req.http.host == "www.sdfsdf.lv") {
                set req.backend = wwwa;
        } elsif (req.http.host == "sdfhsdfh.lv") {
                set req.backend = wwwb;
        } elsif (req.http.host == "www.asdfsd.lv") {
...
        } else {
                error 404 "Unknown virtual host";
        }

janis

On Sunday 02 September 2007 10:38, Poul-Henning Kamp wrote:
> In message <BLU116-F54FAED96DBC408BD5A51E85CF0 at phx.gbl>, "Monty Ree" writes:
> >Thanks for your help..
> >
> >Can you give us temporary vcl or urgent patch which drop the GET, HEAD or
> >purge request which is not including Host header?
>
> This is what you need:
>
> 	http://varnish.projects.linpro.no/changeset/1930


From janis.putrams at delfi.lv  Tue Sep  4 11:04:21 2007
From: janis.putrams at delfi.lv (Janis Putrams)
Date: Tue, 4 Sep 2007 14:04:21 +0300
Subject: Assert error in SES_Delete()
Message-ID: <200709041404.22235.janis.putrams@delfi.lv>

Hi!
Running today's trunk. Got this:

Child said (2, 29744): <<Child starts
managed to mmap 536870912 bytes of 536870912
Ready
CLI ready
>>
Child said (2, 29744): <<Assert error in SES_Delete(), cache_session.c line 
344:
  Condition(!isnan(sp->t_end)) not true.
  errno = 0 (Success)
>>
Cache child died pid=29744 status=0x6
Clean child
Child cleaned

Hope it helps.
janis


From varnish-misc at wheelhouse.org  Wed Sep  5 00:56:46 2007
From: varnish-misc at wheelhouse.org (Jeff)
Date: Tue, 04 Sep 2007 17:56:46 -0700
Subject: Varnish
Message-ID: <46DDFECE.3080004@wheelhouse.org>


Hi,

We would like to try Varnish with an eye towards putting it in our 
production environment; we've pushed Squid about as far as it can go 
performance-wise, and we'd have better luck waiting for Godot than 
proper HTTP 1.1 support.

We currently use squid to reverse-proxy for a large number of (mostly) 
small sites.  I've been working with Varnish 1.1.1 and it's passed my 
basic "does it work?" tests, but I've come up with a list of how-to 
questions that are between us and a full-scale trial deployment.

1) The "Guru Meditation" error messages, while very Amiga-nostalgic, 
aren't customer suitable, but appear to be hard-coded in 
cache_synthetic.c.  If we want nice, pretty error messages, are we 
basically on our own, or is there an imminent plan for this?

2) Since we have an extremely large hostname->backend map, we need to 
choose the right one efficiently and dynamically on a per connection 
basis; we cannot statically configure every possibility into a VCL file. 
  How can we tie some sort of external lookup (pretty much any sort will 
do) into VCL?

3) The log files look like they are great for debugging obscure 
complicated problems, but for day-to-day usage, we need something 
similar to the squid_access format (timestamp, client IP, URL, status 
code, fetch/cache status, bytes).  How would we approach this?

4) We would like to limit the number of simultaneous open connections 
from a single client IP to 10-16 or so to thwart certain types of 
malicious crawlers that open them by the dozens, and kick back a 403 
error to extra ones.  Is this possible with Varnish?

5) We need to If-Modified-Since: revalidate back to the origin server on 
every request, even if 99% of the time it gets a 304 response, in order 
to get log files on the back end that awstats can parse.  However, we 
want to preserve Expires: and max-age values to pass along to the 
client, so something as heavy-handed as setting the max TTL to 0 
probably would not work.  I think this can be done in VCL, I just can't 
seem to wrap my head around it.  What would be the best way for us to 
handle that?

I've been looking at the documentation and source, and will continue to 
do so, but if anyone can point me in the right direction on any of these 
issues, it would be very much appreciated.  Varnish is incredibly cool, 
and it's designed right; I would love to see it working on our network.

Thanks for any advice!

Jeff



From phk at phk.freebsd.dk  Wed Sep  5 07:35:40 2007
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Wed, 05 Sep 2007 07:35:40 +0000
Subject: Varnish 
In-Reply-To: Your message of "Tue, 04 Sep 2007 17:56:46 MST."
	<46DDFECE.3080004@wheelhouse.org> 
Message-ID: <10735.1188977740@critter.freebsd.dk>

In message <46DDFECE.3080004 at wheelhouse.org>, Jeff writes:

>1) The "Guru Meditation" error messages, while very Amiga-nostalgic, 
>aren't customer suitable, but appear to be hard-coded in 
>cache_synthetic.c.  If we want nice, pretty error messages, are we 
>basically on our own, or is there an imminent plan for this?

I belive its on our list somewhere.

>2) Since we have an extremely large hostname->backend map, we need to 
>choose the right one efficiently and dynamically on a per connection 
>basis; we cannot statically configure every possibility into a VCL file. 
>  How can we tie some sort of external lookup (pretty much any sort will 
>do) into VCL?

First of all, VCL is very efficient, so even very large maps in VCL
code will do well.

VCL also has an "include" facility, so you could machinegenerate
that part of your VCL program from your database.

Anyhow, what exactly is "extremely large" in this context ?

>3) The log files look like they are great for debugging obscure 
>complicated problems, but for day-to-day usage, we need something 
>similar to the squid_access format (timestamp, client IP, URL, status 
>code, fetch/cache status, bytes).  How would we approach this?

Did you miss the NCSA format writer ?

>4) We would like to limit the number of simultaneous open connections 
>from a single client IP to 10-16 or so to thwart certain types of 
>malicious crawlers that open them by the dozens, and kick back a 403 
>error to extra ones.  Is this possible with Varnish?

We have what it takes to implement this, what's missing is the VCL
access to the data.

>5) We need to If-Modified-Since: revalidate back to the origin server on 
>every request, even if 99% of the time it gets a 304 response, in order 
>to get log files on the back end that awstats can parse.  However, we 
>want to preserve Expires: and max-age values to pass along to the 
>client, so something as heavy-handed as setting the max TTL to 0 
>probably would not work.  I think this can be done in VCL, I just can't 
>seem to wrap my head around it.  What would be the best way for us to 
>handle that?

This one is tricky.

Our design assumption was that you would want to keep your backend
as much out of the loop as possible and use the varnish logfiles
for your traffic analysis.

Therefore, varnish will either request the object body unconditionally
or not bother the backend at all.

We have some room in the code where we could make this stuff more
flexible, but right now it is not on the todo list.

-- 
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.


From anders at fupp.net  Wed Sep  5 08:21:45 2007
From: anders at fupp.net (Anders Nordby)
Date: Wed, 5 Sep 2007 10:21:45 +0200
Subject: Assert error in SES_Delete()
In-Reply-To: <200709041404.22235.janis.putrams@delfi.lv>
References: <200709041404.22235.janis.putrams@delfi.lv>
Message-ID: <20070905082145.GA76300@fupp.net>

Hi,

I have a similar issue, which I reported in ticket 132:
http://varnish.projects.linpro.no/ticket/132

Could you add information about your problem there?

On Tue, Sep 04, 2007 at 02:04:21PM +0300, Janis Putrams wrote:
> Running today's trunk. Got this:
> 
> Child said (2, 29744): <<Child starts
> managed to mmap 536870912 bytes of 536870912
> Ready
> CLI ready
> >>
> Child said (2, 29744): <<Assert error in SES_Delete(), cache_session.c line 
> 344:
>   Condition(!isnan(sp->t_end)) not true.
>   errno = 0 (Success)
> >>
> Cache child died pid=29744 status=0x6
> Clean child
> Child cleaned
> 
> Hope it helps.
> janis
> _______________________________________________
> varnish-misc mailing list
> varnish-misc at projects.linpro.no
> http://projects.linpro.no/mailman/listinfo/varnish-misc


-- 
Anders.


From des at linpro.no  Wed Sep  5 08:22:23 2007
From: des at linpro.no (=?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?=)
Date: Wed, 05 Sep 2007 10:22:23 +0200
Subject: Varnish
In-Reply-To: <10735.1188977740@critter.freebsd.dk> (Poul-Henning Kamp's
	message of "Wed, 05 Sep 2007 07:35:40 +0000")
References: <10735.1188977740@critter.freebsd.dk>
Message-ID: <ujrabs1serk.fsf@false.linpro.no>

"Poul-Henning Kamp" <phk at phk.freebsd.dk> writes:
> In message <46DDFECE.3080004 at wheelhouse.org>, Jeff writes:
> > 5) We need to If-Modified-Since: revalidate back to the origin
> > server on every request, even if 99% of the time it gets a 304
> > response, in order to get log files on the back end that awstats
> > can parse.
> This one is tricky.

Not at all, they should simply use varnishncsa to generate the logs
they need.

DES
-- 
Dag-Erling Sm?rgrav
Senior Software Developer
Linpro AS - www.linpro.no


From janis.putrams at delfi.lv  Wed Sep  5 08:30:07 2007
From: janis.putrams at delfi.lv (Janis Putrams)
Date: Wed, 5 Sep 2007 11:30:07 +0300
Subject: Assert error in exp_hangman()
Message-ID: <200709051130.07410.janis.putrams@delfi.lv>

Hi!

Don't get me wrong. I am very satisfied with the software and the way it works. I just hope that this can help to make the software even better.

One more for yesturday's trunk :

Child said (2, 1476): <<Assert error in exp_hangman(), cache_expire.c line 113:
  Condition((o)->magic == 0x32851d42) not true.
  errno = 0 (Success)
>>
Cache child died pid=1476 status=0x6
Clean child
Child cleaned
start child pid 12020

If this is not the right way to report, let me know and I can create a ticket as well.
tnx,
janis


From anders at fupp.net  Wed Sep  5 08:37:10 2007
From: anders at fupp.net (Anders Nordby)
Date: Wed, 5 Sep 2007 10:37:10 +0200
Subject: Assert error in exp_hangman()
In-Reply-To: <200709051130.07410.janis.putrams@delfi.lv>
References: <200709051130.07410.janis.putrams@delfi.lv>
Message-ID: <20070905083710.GA76503@fupp.net>

Hi!

Please make tickets for bugs you find, click on New Ticket on the homepage.

Try to describe your environment and what you are doing with Varnish
well. Also include your VCL.

On Wed, Sep 05, 2007 at 11:30:07AM +0300, Janis Putrams wrote:
> Don't get me wrong. I am very satisfied with the software and the way it works. I just hope that this can help to make the software even better.
> 
> One more for yesturday's trunk :
> 
> Child said (2, 1476): <<Assert error in exp_hangman(), cache_expire.c line 113:
>   Condition((o)->magic == 0x32851d42) not true.
>   errno = 0 (Success)
> >>
> Cache child died pid=1476 status=0x6
> Clean child
> Child cleaned
> start child pid 12020
> 
> If this is not the right way to report, let me know and I can create a ticket as well.
> tnx,
> janis
> _______________________________________________
> varnish-misc mailing list
> varnish-misc at projects.linpro.no
> http://projects.linpro.no/mailman/listinfo/varnish-misc


-- 
Anders.


From varnish-misc at wheelhouse.org  Wed Sep  5 08:48:42 2007
From: varnish-misc at wheelhouse.org (Jeff)
Date: Wed, 05 Sep 2007 01:48:42 -0700
Subject: Varnish
In-Reply-To: <10735.1188977740@critter.freebsd.dk>
References: <10735.1188977740@critter.freebsd.dk>
Message-ID: <46DE6D6A.90009@wheelhouse.org>

Poul-Henning Kamp wrote:
>> If we want nice, pretty error messages, are we 
>> >basically on our own, or is there an imminent plan for this?
> 
> I belive its on our list somewhere.

Would it be possible to have an "error server" and then hack up some VCL 
to "pass through" various errors to that server?  I.e, if the cache is 
about to through back a 502 Bad Gateway, have some VCL that sets the 
backend to pass from:

http://errors.example.com/err502?h=www.example.org&ip=10.11.12.13

(Where errors.example.com is the "error server," www.example.org is the 
site the person has trying to reach, and 10.11.12.13 is the client IP?)

> First of all, VCL is very efficient, so even very large maps in VCL
> code will do well.
> 
> VCL also has an "include" facility, so you could machinegenerate
> that part of your VCL program from your database.

The list of names is not static; dozens of names are added or removed 
throughout a given day, and the overhead of generating/loading a massive 
static configuration file on every change would probably be prohibitive.

> Anyhow, what exactly is "extremely large" in this context ?

Between 10^4 and 10^5 active hostname->backend map entries.

Calling out to an external routine for the map lookup sounds inefficient 
but with the necessary hashing and the ability to do nonintrusive 
dynamic updates, it's an overall win.

Since Varnish already generating and loading dynamic objects, would it 
be possible to add support for dynamically extending VCL at runtime?

For example, we could add do something like:

  req.backend.host = my_map_lookup(http.header.host)

And then provide a C function that implements my_map_lookup() to do what 
we need?  (Including provide an "error host" for invalid host values.)

That would be pretty cool, and the ability to write arbitrary extension 
functions in C would most likely lend itself to all sorts of other 
creative uses.

Unfortunately I highly doubt I'm qualified to do that.  When it comes to 
extending scripting languages, I either reach for Swig or I give up. :)

> Did you miss the NCSA format writer ?

Apparently I missed it completely.  The "combined" format does toss some 
highly useful info when used with caches, particularly whether an object 
was served from cache or origin, but I presume the varnishncsa util 
could fairly readily serve as the template for us to whip up a similar 
util that outputs in the format we need.  Thanks for the pointer.

(Squid gets a lot of things wrong, but fair's fair, they get a lot of 
things right and their log format is one of the latter.)

>> 5) We need to If-Modified-Since: revalidate back to the origin server on 
>> every request, [...]
> 
> Our design assumption was that you would want to keep your backend
> as much out of the loop as possible and use the varnish logfiles
> for your traffic analysis.

I have no doubt that works very well when frontending one site. 
However, it does not scale well in our environment.

Even so, parsing one aggregate stream of Varnish log data into N 
individual streams (one for each backend) would probably be doable.

Parsing M streams from a load-balanced cluster of Varnish servers into N 
time-collated streams in something approaching real time, however, 
sounds like a hard problem. :-)

But if you can think of a viable way to do that, it would no doubt be 
much faster than (and therefore superior to) the If-Modified-Since: 
approach.

Thanks for the response!  Sorry if my questions seem naive; I don't 
really understand VCL yet, so I'm making the classic assumption that 
everything I don't understand is easy. :-)

Jeff



From phk at phk.freebsd.dk  Wed Sep  5 09:34:29 2007
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Wed, 05 Sep 2007 09:34:29 +0000
Subject: Varnish 
In-Reply-To: Your message of "Wed, 05 Sep 2007 01:48:42 MST."
	<46DE6D6A.90009@wheelhouse.org> 
Message-ID: <11477.1188984869@critter.freebsd.dk>

In message <46DE6D6A.90009 at wheelhouse.org>, Jeff writes:
>Poul-Henning Kamp wrote:

>>> If we want nice, pretty error messages, are we 
>>> >basically on our own, or is there an imminent plan for this?
>> 
>> I belive its on our list somewhere.
>
>Would it be possible to have an "error server" and then hack up some VCL 
>to "pass through" various errors to that server?  I.e, if the cache is 
>about to through back a 502 Bad Gateway, have some VCL that sets the 
>backend to pass from:

I'm not sure we know exactly how we want to handle it.

One option is to let people rewrite in vcl_error() and restart the
transaction with the (presumably) new url.

>> First of all, VCL is very efficient, so even very large maps in VCL
>> code will do well.
>> 
>> VCL also has an "include" facility, so you could machinegenerate
>> that part of your VCL program from your database.
>
>The list of names is not static; dozens of names are added or removed 
>throughout a given day, and the overhead of generating/loading a massive 
>static configuration file on every change would probably be prohibitive.

Ok, in that case, putting some relevant in-line C code in your VCL
file is probably your best bet.

This is intentionally not well documented, but cases like this is
what it is intended for.

The syntax is:

	C{
	whatever you want
	}C

and it gets copied through exactly at that place.

Use the varnishd "-C" option to see the result before compilation
and good luck :-)


>That would be pretty cool, and the ability to write arbitrary extension 
>functions in C would most likely lend itself to all sorts of other 
>creative uses.

See above :-)

>>> 5) We need to If-Modified-Since: revalidate back to the origin server on 
>>> every request, [...]
>> 

>Parsing M streams from a load-balanced cluster of Varnish servers into N 
>time-collated streams in something approaching real time, however, 
>sounds like a hard problem. :-)

Yes, that is probably true, although not impossible.

-- 
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.


From bozouhair at gmail.com  Wed Sep  5 09:39:22 2007
From: bozouhair at gmail.com (Zouhair BOUNOUALA)
Date: Wed, 5 Sep 2007 09:39:22 +0000
Subject: Varnish + Tomcat
Message-ID: <979f82860709050239s1a0dc8b5yb70f70f1d22c0ec1@mail.gmail.com>

Hi,

1 Is it possible to implement Varnish as HTTP accelator for Tomcat?

2 How to tune and secure Varnish?


Thanks in advance.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20070905/c0854ac0/attachment.html>

From varnish-misc at wheelhouse.org  Wed Sep  5 20:33:18 2007
From: varnish-misc at wheelhouse.org (Jeff)
Date: Wed, 05 Sep 2007 13:33:18 -0700
Subject: Varnish
In-Reply-To: <11477.1188984869@critter.freebsd.dk>
References: <11477.1188984869@critter.freebsd.dk>
Message-ID: <46DF128E.9040002@wheelhouse.org>

Poul-Henning Kamp wrote:
> I'm not sure we know exactly how we want to handle it.
> 
> One option is to let people rewrite in vcl_error() and restart the
> transaction with the (presumably) new url.

Would that be difficult?  In such a case, I gather the guru would hang 
around to meditate on double-faults, thus avoiding loops?

> putting some relevant in-line C code in your VCL
> file is probably your best bet.
> 
> This is intentionally not well documented, but cases like this is
> what it is intended for.
> 
> The syntax is:
> 
> 	C{
> 	whatever you want
> 	}C

I will take a look at this, but since it is intentionally not well 
documented, I am likely to have follow-up questions. :-)

>> Parsing M streams from a load-balanced cluster of Varnish servers into N 
>> time-collated streams in something approaching real time, however, 
>> sounds like a hard problem. :-)
> 
> Yes, that is probably true, although not impossible.

Now, put multiple clusters in multiple cities (in multiple time zones) 
and you will begin to understand why I think IMS: and letting each 
individual backend do its own logging is such a good idea. :-)

Thanks,
Jeff



From optilude at gmx.net  Wed Sep  5 20:48:04 2007
From: optilude at gmx.net (Martin Aspeli)
Date: Wed, 05 Sep 2007 21:48:04 +0100
Subject: Varnish appears to hang/requests time out
In-Reply-To: <ujrejhmsj63.fsf@false.linpro.no>
References: <faqf1s$ji5$1@sea.gmane.org> <ujrejhmsj63.fsf@false.linpro.no>
Message-ID: <fbn4ma$k0s$1@sea.gmane.org>

Dag-Erling Sm?rgrav wrote:
> Martin Aspeli <optilude at gmx.net> writes:
>> I'm having some trouble with Varnish 1.1.1 tarball and 1.1 branch in
>> svn (r1922), and trunk as of today.  [...]
> 
> ENOLOGS

Okay - here is an attempt at fishing out some log entries. Basically, 
I'm seeing intermittent dropped requests that eventually time out: It 
can be the page itself, or JS, CSS or image resources being fetched 
separately.

The logs are with Varnish 1.1, but I the same behaviour (if a bit less 
frequently) them with 1.0 as well.

The VCL:

# This is a basic VCL configuration file for varnish.  See the vcl(7)
# man page for details on VCL syntax and semantics.
#
# Default backend definition.  Set this to point to your content server.

backend default {
     set backend.host = "127.0.0.1";
     set backend.port = "8000";
}

acl purge {
     "localhost";
}

sub vcl_recv {

     if (req.request == "PURGE") {
         if (!client.ip ~ purge) {
                 error 405 "Not allowed.";
         }
         lookup;
     }

     if (req.request != "GET" && req.request != "HEAD") {
         pipe;
     }

     if (req.http.Expect) {
         pipe;
     }

     if (req.http.If-None-Match) {
         pass;
     }

     /* Always cache images and binaries */
     if (req.url ~ 
"\.(jpg|jpeg|gif|png|tiff|tif|svg|swf|ico|vsd|doc|ppt|pps|xls|pdf|mp3|mp4|m4a|ogg|mov|avi|wmv|sxw|zip|gz|bz2|tgz|tar|rar|odc|odb|odf|odg|odi|odp|ods|odt|sxc|sxd|sxi|sxw|dmg|torrent|deb|msi|iso|rpm)$") 
{
         lookup;
     }

     /* Always cache CSS and javascript */
     if (req.url ~ "\.(css|js)$") {
         lookup;
     }

     /* Do not cache other authorised content */
     if (req.http.Authenticate || req.http.Authorization) {
         pass;
     }

     /* We only care about the "__ac.*" cookies, used for authentication */
     if (req.http.Cookie && (req.http.Cookie ~ 
"__ac(_(name|password|persistent))?=" || req.http.Cookie ~ "_ZopeId")) {
         pass;
     }

     lookup;
}

/* Deal with purge requests */
sub vcl_hit {
     if (req.request == "PURGE") {
             set obj.ttl = 0s;
             error 200 "Purged";
     }
     deliver;
}

sub vcl_miss {
     if (req.http.If-Modified-Since) {
         pass;
     }
     if (req.request == "PURGE") {
             error 404 "Not in cache";
     }
     fetch;
}

sub vcl_fetch {
     if (!obj.valid) {
         error;
     }
     if (!obj.cacheable) {
         pass;
     }
     if (obj.http.Set-Cookie) {
         pass;
     }
     if (req.url ~ "(rss_|search_rss)") {
         set obj.ttl = 1800s;
     }
     insert;
}

Some logs (partially annotated as far as I managed to pick out actual 
requests and results):

New request
-----------

     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189010676
    22 SessionOpen  c 127.0.0.1 35852
    22 ReqStart     c 127.0.0.1 35852 1892976556
    22 RxRequest    c GET
    22 RxURL        c //plone-book
    22 RxProtocol   c HTTP/1.1
    22 RxHeader     c Host: localhost:8082
    22 RxHeader     c User-Agent: Mozilla/5.0 (Windows; U; Windows NT
5.1; en-GB; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6
    22 RxHeader     c Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
    22 RxHeader     c Accept-Language: en-gb,en;q=0.5
    22 RxHeader     c Accept-Encoding: gzip,deflate
    22 RxHeader     c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
    22 RxHeader     c Referer: http://example.net/articles
    22 RxHeader     c Max-Forwards: 10
    22 RxHeader     c X-Forwarded-For: 8.223.33.128
    22 RxHeader     c X-Forwarded-Host: example.net
    22 RxHeader     c X-Forwarded-Server: example.net
    22 VCL_call     c recv
    22 VCL_return   c lookup
    22 VCL_call     c hash
    22 VCL_return   c hash
    22 VCL_call     c miss
    22 VCL_return   c fetch
    30 BackendXID   b 1892976556
    22 Backend      c 30 default
    30 TxRequest    b GET
    30 TxURL        b
/VirtualHostBase/http/example.net:80/blog/VirtualHostRoot//plone-book
    30 TxProtocol   b HTTP/1.1
    30 TxHeader     b Host: localhost:8082
    30 TxHeader     b User-Agent: Mozilla/5.0 (Windows; U; Windows NT
5.1; en-GB; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6
    30 TxHeader     b Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
    30 TxHeader     b Accept-Language: en-gb,en;q=0.5
    30 TxHeader     b Accept-Encoding: gzip,deflate
    30 TxHeader     b Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
    30 TxHeader     b Referer: http://example.net/articles
    30 TxHeader     b Max-Forwards: 10
    30 TxHeader     b X-Forwarded-For: 8.223.33.128
    30 TxHeader     b X-Forwarded-Host: example.net
    30 TxHeader     b X-Forwarded-Server: example.net
    30 TxHeader     b X-Varnish: 1892976556
    30 TxHeader     b X-Forwarded-for: 127.0.0.1
    30 RxProtocol   b HTTP/1.1
    30 RxStatus     b 200
    30 RxResponse   b OK
    30 RxHeader     b Server: Zope/(Zope 2.10.4-final, python 2.4.4,
linux2) ZServer/1.1 Plone/3.0
    30 RxHeader     b Date: Wed, 05 Sep 2007 16:44:38 GMT
    30 RxHeader     b Content-Length: 4784
    30 RxHeader     b Content-Language: en
    30 RxHeader     b Content-Encoding: gzip
    30 RxHeader     b Expires: Sun, 07 Sep 1997 16:44:37 GMT
    30 RxHeader     b Vary: Accept-Encoding, Accept-Language,
    30 RxHeader     b 	Accept-Encoding
    30 RxHeader     b ETag: ||Optilude Theme|en-gb;en;q=0.5|1|662||||330280
    30 RxHeader     b X-Caching-Rule-Id: plone-content-types
    30 RxHeader     b Cache-Control: max-age=0, s-maxage=0, private,
must-revalidate
    30 RxHeader     b Content-Type: text/html;charset=utf-8
    30 RxHeader     b X-Header-Set-Id: cache-in-memory
    22 ObjProtocol  c HTTP/1.1
    22 ObjStatus    c 200
    22 ObjResponse  c OK
    22 ObjHeader    c Server: Zope/(Zope 2.10.4-final, python 2.4.4,
linux2) ZServer/1.1 Plone/3.0
    22 ObjHeader    c Date: Wed, 05 Sep 2007 16:44:38 GMT
    22 ObjHeader    c Content-Language: en
    22 ObjHeader    c Content-Encoding: gzip
    22 ObjHeader    c Expires: Sun, 07 Sep 1997 16:44:37 GMT
    22 ObjHeader    c Vary: Accept-Encoding, Accept-Language,
    22 ObjHeader    c 	Accept-Encoding
    22 ObjHeader    c ETag: ||Optilude Theme|en-gb;en;q=0.5|1|662||||330280
    22 ObjHeader    c X-Caching-Rule-Id: plone-content-types
    22 ObjHeader    c Cache-Control: max-age=0, s-maxage=0, private,
must-revalidate
    22 ObjHeader    c Content-Type: text/html;charset=utf-8
    22 ObjHeader    c X-Header-Set-Id: cache-in-memory
    30 BackendReuse b default
    22 TTL          c 1892976556 RFC 0 1189010678 1189010678 873650677 0 0
    22 VCL_call     c fetch
    22 VCL_return   c insert
    22 Length       c 4784
    22 VCL_call     c deliver
    22 VCL_return   c deliver
    22 TxProtocol   c HTTP/1.1
    22 TxStatus     c 200
    22 TxResponse   c OK
    22 TxHeader     c Server: Zope/(Zope 2.10.4-final, python 2.4.4,
linux2) ZServer/1.1 Plone/3.0
    22 TxHeader     c Date: Wed, 05 Sep 2007 16:44:38 GMT
    22 TxHeader     c Content-Language: en
    22 TxHeader     c Content-Encoding: gzip
    22 TxHeader     c Expires: Sun, 07 Sep 1997 16:44:37 GMT
    22 TxHeader     c Vary: Accept-Encoding, Accept-Language,
    22 TxHeader     c 	Accept-Encoding
    22 TxHeader     c ETag: ||Optilude Theme|en-gb;en;q=0.5|1|662||||330280
    22 TxHeader     c X-Caching-Rule-Id: plone-content-types
    22 TxHeader     c Cache-Control: max-age=0, s-maxage=0, private,
must-revalidate
    22 TxHeader     c Content-Type: text/html;charset=utf-8
    22 TxHeader     c X-Header-Set-Id: cache-in-memory
    22 TxHeader     c Content-Length: 4784
    22 TxHeader     c X-Varnish: 1892976556
    22 TxHeader     c Age: 0
    22 TxHeader     c Via: 1.1 varnish
    22 TxHeader     c Connection: keep-alive
    22 ReqEnd       c 1892976556 1189010677.848659039
1189010678.847302914 0.000082970 0.998533010 0.000110865
     0 StatAddr       127.0.0.1 0 411 39 91 0 0 25 29049 280224
     0 ExpKill        1892976556 0
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189010679
    22 HttpError    c Received nothing
    22 SessionClose c no request
    22 StatSess     c 127.0.0.1 35852 1 1 1 0 0 1 606 4784
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189010682

That request was OK.
Trying a new one:
-----------------



     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189010685
    22 SessionOpen  c 127.0.0.1 35881
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189010688
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189010691
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189010694
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189010697
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189010700
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189010703
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189010706
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189010709
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189010712
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189010715
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189010718
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189010721
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189010724
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189010727
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189010730
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189010733
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189010736
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189010739
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189010742
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189010745
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189010748
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189010751
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189010754
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189010757
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189010760
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189010763
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189010766
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189010769
     0 ExpKill        1892976547 0
     0 ExpKill        1892976548 0
     0 WorkThread     0x552591a0 end
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189010772
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189010775
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189010778
     0 ExpKill        1892976553 0
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189010781
     0 ExpKill        1892976554 0
     0 ExpKill        1892976555 0
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189010784
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189010787

Received Proxy Error from Apache.
Trying a new request:
---------------------------------


     0 WorkThread     0x552591a0 start
    24 SessionOpen  c 127.0.0.1 37149
    24 ReqStart     c 127.0.0.1 37149 1892976558
    24 RxRequest    c GET
    24 RxURL        c //robots.txt
    24 RxProtocol   c HTTP/1.1
    24 RxHeader     c Host: localhost:8082
    24 RxHeader     c User-Agent: msnbot-media/1.0
(+http://search.msn.com/msnbot.htm)
    24 RxHeader     c Accept: */*
    24 RxHeader     c From: msnbot(at)microsoft.com
    24 RxHeader     c Max-Forwards: 10
    24 RxHeader     c X-Forwarded-For: 8.223.33.128
    24 RxHeader     c X-Forwarded-Host: example.net
    24 RxHeader     c X-Forwarded-Server: example.net
    24 VCL_call     c recv
    24 VCL_return   c lookup
    24 VCL_call     c hash
    24 VCL_return   c hash
    24 VCL_call     c miss
    24 VCL_return   c fetch
    26 BackendXID   b 1892976558
    24 Backend      c 26 default
    26 TxRequest    b GET
    26 TxURL        b
/VirtualHostBase/http/example.net:80/blog/VirtualHostRoot//robots.txt
    26 TxProtocol   b HTTP/1.1
    26 TxHeader     b Host: localhost:8082
    26 TxHeader     b User-Agent: msnbot-media/1.0
(+http://search.msn.com/msnbot.htm)
    26 TxHeader     b Accept: */*
    26 TxHeader     b From: msnbot(at)microsoft.com
    26 TxHeader     b Max-Forwards: 10
    26 TxHeader     b X-Forwarded-For: 8.223.33.128
    26 TxHeader     b X-Forwarded-Host: example.net
    26 TxHeader     b X-Forwarded-Server: example.net
    26 TxHeader     b X-Varnish: 1892976558
    26 TxHeader     b X-Forwarded-for: 127.0.0.1
    26 RxProtocol   b HTTP/1.1
    26 RxStatus     b 200
    26 RxResponse   b OK
    26 RxHeader     b Server: Zope/(Zope 2.10.4-final, python 2.4.4,
linux2) ZServer/1.1 Plone/3.0
    26 RxHeader     b Date: Wed, 05 Sep 2007 16:50:39 GMT
    26 RxHeader     b Last-Modified: Fri, 09 Feb 2007 12:40:57 GMT
    26 RxHeader     b Content-Length: 549
    26 RxHeader     b Content-Type: text/plain; charset=iso-8859-15
    24 ObjProtocol  c HTTP/1.1
    24 ObjStatus    c 200
    24 ObjResponse  c OK
    24 ObjHeader    c Server: Zope/(Zope 2.10.4-final, python 2.4.4,
linux2) ZServer/1.1 Plone/3.0
    24 ObjHeader    c Date: Wed, 05 Sep 2007 16:50:39 GMT
    24 ObjHeader    c Last-Modified: Fri, 09 Feb 2007 12:40:57 GMT
    24 ObjHeader    c Content-Type: text/plain; charset=iso-8859-15
    26 BackendReuse b default
    24 TTL          c 1892976558 RFC 120 1189011039 1189011039 0 0 0
    24 VCL_call     c fetch
    24 VCL_return   c insert
    24 Length       c 549
    24 VCL_call     c deliver
    24 VCL_return   c deliver
    24 TxProtocol   c HTTP/1.1
    24 TxStatus     c 200
    24 TxResponse   c OK
    24 TxHeader     c Server: Zope/(Zope 2.10.4-final, python 2.4.4,
linux2) ZServer/1.1 Plone/3.0
    24 TxHeader     c Date: Wed, 05 Sep 2007 16:50:39 GMT
    24 TxHeader     c Last-Modified: Fri, 09 Feb 2007 12:40:57 GMT
    24 TxHeader     c Content-Type: text/plain; charset=iso-8859-15
    24 TxHeader     c Content-Length: 549
    24 TxHeader     c X-Varnish: 1892976558
    24 TxHeader     c Age: 0
    24 TxHeader     c Via: 1.1 varnish
    24 TxHeader     c Connection: keep-alive
    24 ReqEnd       c 1892976558 1189011039.758268118
1189011039.804734945 0.000107050 0.046402931 0.000063896
     0 StatAddr       127.0.0.1 0 772 40 92 0 0 26 29370 280773
    24 HttpError    c Received nothing
    24 SessionClose c no request
    24 StatSess     c 127.0.0.1 37149 0 1 1 0 0 1 321 549
    24 SessionOpen  c 127.0.0.1 37150
    24 ReqStart     c 127.0.0.1 37150 1892976559
    24 RxRequest    c GET
    24 RxURL        c //Members/hg/play/41-gambling-335.htm
    24 RxProtocol   c HTTP/1.1
    24 RxHeader     c Host: localhost:8082
    24 RxHeader     c User-Agent: msnbot-media/1.0
(+http://search.msn.com/msnbot.htm)
    24 RxHeader     c Accept: text/html, text/plain, text/text,
text/javascript, text/x-javascript, text/js, text/x-js, text/jscript,
text/ecmascript, text/xml, xml/xml, image/*, audio/*, video/*,
application/*
    24 RxHeader     c Accept-Encoding: identity;q=1.0
    24 RxHeader     c From: msnbot(at)microsoft.com
    24 RxHeader     c Max-Forwards: 10
    24 RxHeader     c X-Forwarded-For: 8.223.33.128
    24 RxHeader     c X-Forwarded-Host: example.net
    24 RxHeader     c X-Forwarded-Server: example.net
    24 VCL_call     c recv
    24 VCL_return   c lookup
    24 VCL_call     c hash
    24 VCL_return   c hash
    24 VCL_call     c miss
    24 VCL_return   c fetch
    26 BackendXID   b 1892976559
    24 Backend      c 26 default
    26 TxRequest    b GET
    26 TxURL        b
/VirtualHostBase/http/example.net:80/blog/VirtualHostRoot//Members/hg/play/41-gambling-335.htm
    26 TxProtocol   b HTTP/1.1
    26 TxHeader     b Host: localhost:8082
    26 TxHeader     b User-Agent: msnbot-media/1.0
(+http://search.msn.com/msnbot.htm)
    26 TxHeader     b Accept: text/html, text/plain, text/text,
text/javascript, text/x-javascript, text/js, text/x-js, text/jscript,
text/ecmascript, text/xml, xml/xml, image/*, audio/*, video/*,
application/*
    26 TxHeader     b Accept-Encoding: identity;q=1.0
    26 TxHeader     b From: msnbot(at)microsoft.com
    26 TxHeader     b Max-Forwards: 10
    26 TxHeader     b X-Forwarded-For: 8.223.33.128
    26 TxHeader     b X-Forwarded-Host: example.net
    26 TxHeader     b X-Forwarded-Server: example.net
    26 TxHeader     b X-Varnish: 1892976559
    26 TxHeader     b X-Forwarded-for: 127.0.0.1
    26 RxProtocol   b HTTP/1.1
    26 RxStatus     b 404
    26 RxResponse   b Not Found
    26 RxHeader     b Server: Zope/(Zope 2.10.4-final, python 2.4.4,
linux2) ZServer/1.1 Plone/3.0
    26 RxHeader     b Date: Wed, 05 Sep 2007 16:50:40 GMT
    26 RxHeader     b Bobo-Exception-Line: 672
    26 RxHeader     b Content-Length: 12306
    26 RxHeader     b Bobo-Exception-Value: See the server error log for 
details
    26 RxHeader     b Content-Language: en
    26 RxHeader     b Bobo-Exception-File: HTTPResponse.py
    26 RxHeader     b Bobo-Exception-Type: NotFound
    26 RxHeader     b Expires: Sat, 1 Jan 2000 00:00:00 GMT
    26 RxHeader     b X-Ksscommands: <?xml version="1.0"?> <root
xmlns:kukit="http://www.kukit.org/commands/1.0"> <kukit:commands>
	<kukit:command name="error"> 		<kukit:param
name="type">system</kukit:param> 		<kukit:param
name="message">NotFound:   &amp;lt;h2&amp;gt;Site Err
    26 RxHeader     b Content-Type: text/html;charset=utf-8
    24 ObjProtocol  c HTTP/1.1
    24 ObjStatus    c 404
    24 ObjResponse  c Not Found
    24 ObjHeader    c Server: Zope/(Zope 2.10.4-final, python 2.4.4,
linux2) ZServer/1.1 Plone/3.0
    24 ObjHeader    c Date: Wed, 05 Sep 2007 16:50:40 GMT
    24 ObjHeader    c Bobo-Exception-Line: 672
    24 ObjHeader    c Bobo-Exception-Value: See the server error log for 
details
    24 ObjHeader    c Content-Language: en
    24 ObjHeader    c Bobo-Exception-File: HTTPResponse.py
    24 ObjHeader    c Bobo-Exception-Type: NotFound
    24 ObjHeader    c Expires: Sat, 1 Jan 2000 00:00:00 GMT
    24 ObjHeader    c X-Ksscommands: <?xml version="1.0"?> <root
xmlns:kukit="http://www.kukit.org/commands/1.0"> <kukit:commands>
	<kukit:command name="error"> 		<kukit:param
name="type">system</kukit:param> 		<kukit:param
name="message">NotFound:   &amp;lt;h2&amp;gt;Site Err
    24 ObjHeader    c Content-Type: text/html;charset=utf-8
    26 BackendReuse b default
    24 TTL          c 1892976559 RFC 120 1189011040 1189011040 946684800 0 0
    24 VCL_call     c fetch
    24 VCL_return   c insert
    24 Length       c 12306
    24 VCL_call     c deliver
    24 VCL_return   c deliver
    24 TxProtocol   c HTTP/1.1
    24 TxStatus     c 404
    24 TxResponse   c Not Found
    24 TxHeader     c Server: Zope/(Zope 2.10.4-final, python 2.4.4,
linux2) ZServer/1.1 Plone/3.0
    24 TxHeader     c Date: Wed, 05 Sep 2007 16:50:40 GMT
    24 TxHeader     c Bobo-Exception-Line: 672
    24 TxHeader     c Bobo-Exception-Value: See the server error log for 
details
    24 TxHeader     c Content-Language: en
    24 TxHeader     c Bobo-Exception-File: HTTPResponse.py
    24 TxHeader     c Bobo-Exception-Type: NotFound
    24 TxHeader     c Expires: Sat, 1 Jan 2000 00:00:00 GMT
    24 TxHeader     c X-Ksscommands: <?xml version="1.0"?> <root
xmlns:kukit="http://www.kukit.org/commands/1.0"> <kukit:commands>
	<kukit:command name="error"> 		<kukit:param
name="type">system</kukit:param> 		<kukit:param
name="message">NotFound:   &amp;lt;h2&amp;gt;Site Err
    24 TxHeader     c Content-Type: text/html;charset=utf-8
    24 TxHeader     c Content-Length: 12306
    24 TxHeader     c X-Varnish: 1892976559
    24 TxHeader     c Age: 0
    24 TxHeader     c Via: 1.1 varnish
    24 TxHeader     c Connection: keep-alive
    24 ReqEnd       c 1892976559 1189011040.021153927
1189011040.916707993 0.000094891 0.895455122 0.000098944
     0 StatAddr       127.0.0.1 0 773 41 93 0 0 27 31297 293079
    24 HttpError    c Received nothing
    24 SessionClose c no request
    24 StatSess     c 127.0.0.1 37150 1 1 1 0 0 1 1927 12306
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189011042
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189011045
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189011048
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189011051
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189011054
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189011057
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189011060
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189011063
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189011066
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189011069
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189011072
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189011075
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189011078
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189011081
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189011084
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189011087
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189011090
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189011093
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189011096
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189011099
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189011102
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189011105
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189011108
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189011111
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189011114
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189011117
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189011120
    24 SessionOpen  c 127.0.0.1 37510
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189011123
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189011126
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189011129
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189011132
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189011135
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189011138
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189011141
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189011144
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189011147
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189011150
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189011153
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189011156
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189011159
     0 ExpKill        1892976558 0
     0 ExpKill        1892976559 0
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189011162
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189011165
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189011168
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189011171
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189011174
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189011177
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189011180
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189011183
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189011186
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189011189
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189011192
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189011195
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189011198
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189011201
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189011204
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189011207
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189011210
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189011213
     0 WorkThread     0x5625b1a0 start
    31 SessionOpen  c 127.0.0.1 37950
    31 ReqStart     c 127.0.0.1 37950 1892976561
    31 RxRequest    c GET
    31 RxURL        c //articles/the-rumours-are-true-a-book-about-plone-3
    31 RxProtocol   c HTTP/1.1
    31 RxHeader     c Host: localhost:8082
    31 RxHeader     c User-Agent: Mozilla/5.0 (X11; U; Linux i686;
en-US; rv:1.8.0.13) Gecko/20070824 Thunderbird/1.5.0.13
    31 RxHeader     c Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
    31 RxHeader     c Accept-Language: fr,fr-fr;q=0.8,en-us;q=0.5,en;q=0.3
    31 RxHeader     c Accept-Encoding: gzip,deflate
    31 RxHeader     c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
    31 RxHeader     c Max-Forwards: 10
    31 RxHeader     c X-Forwarded-For: 8.223.33.128
    31 RxHeader     c X-Forwarded-Host: example.net
    31 RxHeader     c X-Forwarded-Server: example.net
    31 VCL_call     c recv
    31 VCL_return   c lookup
    31 VCL_call     c hash
    31 VCL_return   c hash
    31 VCL_call     c miss
    31 VCL_return   c fetch
    34 BackendOpen  b default 127.0.0.1 37951 127.0.0.1 8080
    34 BackendXID   b 1892976561
    31 Backend      c 34 default
    34 TxRequest    b GET
    34 TxURL        b
/VirtualHostBase/http/example.net:80/blog/VirtualHostRoot//articles/the-rumours-are-true-a-book-about-plone-3
    34 TxProtocol   b HTTP/1.1
    34 TxHeader     b Host: localhost:8082
    34 TxHeader     b User-Agent: Mozilla/5.0 (X11; U; Linux i686;
en-US; rv:1.8.0.13) Gecko/20070824 Thunderbird/1.5.0.13
    34 TxHeader     b Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
    34 TxHeader     b Accept-Language: fr,fr-fr;q=0.8,en-us;q=0.5,en;q=0.3
    34 TxHeader     b Accept-Encoding: gzip,deflate
    34 TxHeader     b Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
    34 TxHeader     b Max-Forwards: 10
    34 TxHeader     b X-Forwarded-For: 8.223.33.128
    34 TxHeader     b X-Forwarded-Host: example.net
    34 TxHeader     b X-Forwarded-Server: example.net
    34 TxHeader     b X-Varnish: 1892976561
    34 TxHeader     b X-Forwarded-for: 127.0.0.1
    34 RxProtocol   b HTTP/1.1
    34 RxStatus     b 200
    34 RxResponse   b OK
    34 RxHeader     b Server: Zope/(Zope 2.10.4-final, python 2.4.4,
linux2) ZServer/1.1 Plone/3.0
    34 RxHeader     b Date: Wed, 05 Sep 2007 16:53:35 GMT
    34 RxHeader     b X-Pagecache: MISS
    34 RxHeader     b Content-Length: 8085
    34 RxHeader     b Content-Language: en
    34 RxHeader     b Content-Encoding: gzip
    34 RxHeader     b Expires: Sun, 07 Sep 1997 16:53:34 GMT
    34 RxHeader     b Vary: Accept-Encoding, Accept-Language,
    34 RxHeader     b 	Accept-Encoding
    34 RxHeader     b ETag: ||Optilude
Theme|fr;fr-fr;q=0.8;en-us;q=0.5;en;q=0.3|1|662||||330280
    34 RxHeader     b X-Caching-Rule-Id: plone-content-types
    34 RxHeader     b Cache-Control: max-age=0, s-maxage=0, private,
must-revalidate
    34 RxHeader     b Content-Type: text/html;charset=utf-8
    34 RxHeader     b X-Header-Set-Id: cache-in-memory
    31 ObjProtocol  c HTTP/1.1
    31 ObjStatus    c 200
    31 ObjResponse  c OK
    31 ObjHeader    c Server: Zope/(Zope 2.10.4-final, python 2.4.4,
linux2) ZServer/1.1 Plone/3.0
    31 ObjHeader    c Date: Wed, 05 Sep 2007 16:53:35 GMT
    31 ObjHeader    c X-Pagecache: MISS
    31 ObjHeader    c Content-Language: en
    31 ObjHeader    c Content-Encoding: gzip
    31 ObjHeader    c Expires: Sun, 07 Sep 1997 16:53:34 GMT
    31 ObjHeader    c Vary: Accept-Encoding, Accept-Language,
    31 ObjHeader    c 	Accept-Encoding
    31 ObjHeader    c ETag: ||Optilude
Theme|fr;fr-fr;q=0.8;en-us;q=0.5;en;q=0.3|1|662||||330280
    31 ObjHeader    c X-Caching-Rule-Id: plone-content-types
    31 ObjHeader    c Cache-Control: max-age=0, s-maxage=0, private,
must-revalidate
    31 ObjHeader    c Content-Type: text/html;charset=utf-8
    31 ObjHeader    c X-Header-Set-Id: cache-in-memory
    34 BackendReuse b default
    31 TTL          c 1892976561 RFC 0 1189011215 1189011215 873651214 0 0
    31 VCL_call     c fetch
    31 VCL_return   c insert
    31 Length       c 8085
    31 VCL_call     c deliver
    31 VCL_return   c deliver
    31 TxProtocol   c HTTP/1.1
    31 TxStatus     c 200
    31 TxResponse   c OK
    31 TxHeader     c Server: Zope/(Zope 2.10.4-final, python 2.4.4,
linux2) ZServer/1.1 Plone/3.0
    31 TxHeader     c Date: Wed, 05 Sep 2007 16:53:35 GMT
    31 TxHeader     c X-Pagecache: MISS
    31 TxHeader     c Content-Language: en
    31 TxHeader     c Content-Encoding: gzip
    31 TxHeader     c Expires: Sun, 07 Sep 1997 16:53:34 GMT
    31 TxHeader     c Vary: Accept-Encoding, Accept-Language,
    31 TxHeader     c 	Accept-Encoding
    31 TxHeader     c ETag: ||Optilude
Theme|fr;fr-fr;q=0.8;en-us;q=0.5;en;q=0.3|1|662||||330280
    31 TxHeader     c X-Caching-Rule-Id: plone-content-types
    31 TxHeader     c Cache-Control: max-age=0, s-maxage=0, private,
must-revalidate
    31 TxHeader     c Content-Type: text/html;charset=utf-8
    31 TxHeader     c X-Header-Set-Id: cache-in-memory
    31 TxHeader     c Content-Length: 8085
    31 TxHeader     c X-Varnish: 1892976561
    31 TxHeader     c Age: 0
    31 TxHeader     c Via: 1.1 varnish
    31 TxHeader     c Connection: keep-alive
    31 ReqEnd       c 1892976561 1189011214.560914040
1189011215.423327923 0.000175953 0.862323999 0.000089884
     0 StatAddr       127.0.0.1 0 948 42 94 0 0 28 31943 301164
    35 SessionOpen  c 127.0.0.1 37963
    35 ReqStart     c 127.0.0.1 37963 1892976562
    35 RxRequest    c GET
    35 RxURL        c //portal_css/Optilude%20Theme/base-cachekey1160.css
    35 RxProtocol   c HTTP/1.1
    35 RxHeader     c Host: localhost:8082
    35 RxHeader     c User-Agent: Mozilla/5.0 (X11; U; Linux i686;
en-US; rv:1.8.0.13) Gecko/20070824 Thunderbird/1.5.0.13
    35 RxHeader     c Accept: text/css,*/*;q=0.1
    35 RxHeader     c Accept-Language: fr,fr-fr;q=0.8,en-us;q=0.5,en;q=0.3
    35 RxHeader     c Accept-Encoding: gzip,deflate
    35 RxHeader     c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
    35 RxHeader     c Referer:
http://example.net/articles/the-rumours-are-true-a-book-about-plone-3
    35 RxHeader     c Max-Forwards: 10
    35 RxHeader     c X-Forwarded-For: 8.223.33.128
    35 RxHeader     c X-Forwarded-Host: example.net
    35 RxHeader     c X-Forwarded-Server: example.net
    35 VCL_call     c recv
    35 VCL_return   c lookup
    35 VCL_call     c hash
    35 VCL_return   c hash
    35 Hit          c 1892976465
    35 VCL_call     c hit
    35 VCL_return   c deliver
    35 Length       c 3386
    35 VCL_call     c deliver
    35 VCL_return   c deliver
    35 TxProtocol   c HTTP/1.1
    35 TxStatus     c 200
    35 TxResponse   c OK
    35 TxHeader     c Server: Zope/(Zope 2.10.4-final, python 2.4.4,
linux2) ZServer/1.1 Plone/3.0
    35 TxHeader     c Date: Wed, 05 Sep 2007 16:38:54 GMT
    35 TxHeader     c X-Cache-Headers-Set-By: CachingPolicyManager:
/blog/caching_policy_manager
    35 TxHeader     c Expires: Thu, 04 Sep 2008 16:38:54 GMT
    35 TxHeader     c Last-Modified: Wed, 05 Sep 2007 16:38:54 GMT
    35 TxHeader     c X-Caching-Rule-Id: resource-registries
    35 TxHeader     c Cache-Control: max-age=31536000, 
s-maxage=31536000, public
    35 TxHeader     c Content-Type: text/css;charset=utf-8
    35 TxHeader     c X-Header-Set-Id: cache-in-browser-forever
    35 TxHeader     c Content-Length: 3386
    35 TxHeader     c X-Varnish: 1892976562 1892976465
    35 TxHeader     c Age: 882
    35 TxHeader     c Via: 1.1 varnish
    35 TxHeader     c Connection: keep-alive
    35 ReqEnd       c 1892976562 1189011215.596278906
1189011215.596473932 0.000048876 0.000085115 0.000109911
     0 StatAddr       127.0.0.1 0 948 43 95 0 0 28 32528 304550
    31 HttpError    c Received nothing
    31 SessionClose c no request
    31 StatSess     c 127.0.0.1 37950 1 1 1 0 0 1 646 8085
    35 HttpError    c Received nothing
    35 SessionClose c no request
    35 StatSess     c 127.0.0.1 37963 0 1 1 0 0 0 585 3386
    31 SessionOpen  c 127.0.0.1 37967
    31 ReqStart     c 127.0.0.1 37967 1892976563
    31 RxRequest    c GET
    31 RxURL        c //portal_css/Optilude%20Theme/nuplone-cachekey0680.css
    31 RxProtocol   c HTTP/1.1
    31 RxHeader     c Host: localhost:8082
    31 RxHeader     c User-Agent: Mozilla/5.0 (X11; U; Linux i686;
en-US; rv:1.8.0.13) Gecko/20070824 Thunderbird/1.5.0.13
    31 RxHeader     c Accept: text/css,*/*;q=0.1
    31 RxHeader     c Accept-Language: fr,fr-fr;q=0.8,en-us;q=0.5,en;q=0.3
    31 RxHeader     c Accept-Encoding: gzip,deflate
    31 RxHeader     c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
    31 RxHeader     c Referer:
http://example.net/articles/the-rumours-are-true-a-book-about-plone-3
    31 RxHeader     c Max-Forwards: 10
    31 RxHeader     c X-Forwarded-For: 8.223.33.128
    31 RxHeader     c X-Forwarded-Host: example.net
    31 RxHeader     c X-Forwarded-Server: example.net
    31 VCL_call     c recv
    31 VCL_return   c lookup
    31 VCL_call     c hash
    31 VCL_return   c hash
    31 Hit          c 1892976472
    31 VCL_call     c hit
    31 VCL_return   c deliver
    31 Length       c 22550
    31 VCL_call     c deliver
    31 VCL_return   c deliver
    31 TxProtocol   c HTTP/1.1
    31 TxStatus     c 200
    31 TxResponse   c OK
    31 TxHeader     c Server: Zope/(Zope 2.10.4-final, python 2.4.4,
linux2) ZServer/1.1 Plone/3.0
    31 TxHeader     c Date: Wed, 05 Sep 2007 16:38:54 GMT
    31 TxHeader     c X-Cache-Headers-Set-By: CachingPolicyManager:
/blog/caching_policy_manager
    31 TxHeader     c Expires: Thu, 04 Sep 2008 16:38:54 GMT
    31 TxHeader     c Last-Modified: Wed, 05 Sep 2007 16:38:54 GMT
    31 TxHeader     c X-Caching-Rule-Id: resource-registries
    31 TxHeader     c Cache-Control: max-age=31536000, 
s-maxage=31536000, public
    31 TxHeader     c Content-Type: text/css;charset=utf-8
    31 TxHeader     c X-Header-Set-Id: cache-in-browser-forever
    31 TxHeader     c Content-Length: 22550
    31 TxHeader     c X-Varnish: 1892976563 1892976472
    31 TxHeader     c Age: 881
    31 TxHeader     c Via: 1.1 varnish
    31 TxHeader     c Connection: keep-alive
    31 ReqEnd       c 1892976563 1189011215.753976107
1189011215.754245043 0.000068188 0.000093937 0.000174999
     0 StatAddr       127.0.0.1 0 948 44 96 0 0 28 33114 327100
    31 HttpError    c Received nothing
    31 SessionClose c no request
    31 StatSess     c 127.0.0.1 37967 0 1 1 0 0 0 586 22550
    31 SessionOpen  c 127.0.0.1 37977
     0 WorkThread     0x56a5c1a0 start
    35 SessionOpen  c 127.0.0.1 37978
     0 ExpKill        1892976561 0
    31 ReqStart     c 127.0.0.1 37977 1892976564
    31 RxRequest    c GET
    31 RxURL        c //portal_css/Optilude%20Theme/body.gif
    31 RxProtocol   c HTTP/1.1
    31 RxHeader     c Host: localhost:8082
    31 RxHeader     c User-Agent: Mozilla/5.0 (X11; U; Linux i686;
en-US; rv:1.8.0.13) Gecko/20070824 Thunderbird/1.5.0.13
    31 RxHeader     c Accept: image/png,*/*;q=0.5
    31 RxHeader     c Accept-Language: fr,fr-fr;q=0.8,en-us;q=0.5,en;q=0.3
    31 RxHeader     c Accept-Encoding: gzip,deflate
    31 RxHeader     c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
    31 RxHeader     c Referer:
http://example.net/portal_css/Optilude%20Theme/nuplone-cachekey0680.css
    31 RxHeader     c Max-Forwards: 10
    31 RxHeader     c X-Forwarded-For: 8.223.33.128
    31 RxHeader     c X-Forwarded-Host: example.net
    31 RxHeader     c X-Forwarded-Server: example.net
    31 VCL_call     c recv
    31 VCL_return   c lookup
    31 VCL_call     c hash
    31 VCL_return   c hash
    31 VCL_call     c miss
    31 VCL_return   c fetch
    34 BackendXID   b 1892976564
    31 Backend      c 34 default
    34 TxRequest    b GET
    34 TxURL        b
/VirtualHostBase/http/example.net:80/blog/VirtualHostRoot//portal_css/Optilude%20Theme/body.gif
    34 TxProtocol   b HTTP/1.1
    34 TxHeader     b Host: localhost:8082
    34 TxHeader     b User-Agent: Mozilla/5.0 (X11; U; Linux i686;
en-US; rv:1.8.0.13) Gecko/20070824 Thunderbird/1.5.0.13
    34 TxHeader     b Accept: image/png,*/*;q=0.5
    34 TxHeader     b Accept-Language: fr,fr-fr;q=0.8,en-us;q=0.5,en;q=0.3
    34 TxHeader     b Accept-Encoding: gzip,deflate
    34 TxHeader     b Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
    34 TxHeader     b Referer:
http://example.net/portal_css/Optilude%20Theme/nuplone-cachekey0680.css
    34 TxHeader     b Max-Forwards: 10
    34 TxHeader     b X-Forwarded-For: 8.223.33.128
    34 TxHeader     b X-Forwarded-Host: example.net
    34 TxHeader     b X-Forwarded-Server: example.net
    34 TxHeader     b X-Varnish: 1892976564
    34 TxHeader     b X-Forwarded-for: 127.0.0.1
    34 RxProtocol   b HTTP/1.1
    34 RxStatus     b 200
    34 RxResponse   b OK
    34 RxHeader     b Server: Zope/(Zope 2.10.4-final, python 2.4.4,
linux2) ZServer/1.1 Plone/3.0
    34 RxHeader     b Date: Wed, 05 Sep 2007 16:53:36 GMT
    34 RxHeader     b Last-Modified: Mon, 27 Aug 2007 20:09:52 GMT
    34 RxHeader     b Content-Length: 61
    34 RxHeader     b Content-Type: image/gif
    31 ObjProtocol  c HTTP/1.1
    31 ObjStatus    c 200
    31 ObjResponse  c OK
    31 ObjHeader    c Server: Zope/(Zope 2.10.4-final, python 2.4.4,
linux2) ZServer/1.1 Plone/3.0
    31 ObjHeader    c Date: Wed, 05 Sep 2007 16:53:36 GMT
    31 ObjHeader    c Last-Modified: Mon, 27 Aug 2007 20:09:52 GMT
    31 ObjHeader    c Content-Type: image/gif
    34 BackendReuse b default
    31 TTL          c 1892976564 RFC 120 1189011216 1189011216 0 0 0
    31 VCL_call     c fetch
    31 VCL_return   c insert
    31 Length       c 61
    31 VCL_call     c deliver
    31 VCL_return   c deliver
    31 TxProtocol   c HTTP/1.1
    31 TxStatus     c 200
    31 TxResponse   c OK
    31 TxHeader     c Server: Zope/(Zope 2.10.4-final, python 2.4.4,
linux2) ZServer/1.1 Plone/3.0
    31 TxHeader     c Date: Wed, 05 Sep 2007 16:53:36 GMT
    31 TxHeader     c Last-Modified: Mon, 27 Aug 2007 20:09:52 GMT
    31 TxHeader     c Content-Type: image/gif
    31 TxHeader     c Content-Length: 61
    31 TxHeader     c X-Varnish: 1892976564
    31 TxHeader     c Age: 0
    31 TxHeader     c Via: 1.1 varnish
    31 TxHeader     c Connection: keep-alive
    31 ReqEnd       c 1892976564 1189011216.214435101
1189011216.320699930 0.000060081 0.106203794 0.000061035
     0 StatAddr       127.0.0.1 0 949 45 97 0 0 29 33412 327161
    35 ReqStart     c 127.0.0.1 37978 1892976565
    35 RxRequest    c GET
    35 RxURL        c //logo.gif
    35 RxProtocol   c HTTP/1.1
    35 RxHeader     c Host: localhost:8082
    35 RxHeader     c User-Agent: Mozilla/5.0 (X11; U; Linux i686;
en-US; rv:1.8.0.13) Gecko/20070824 Thunderbird/1.5.0.13
    35 RxHeader     c Accept: image/png,*/*;q=0.5
    35 RxHeader     c Accept-Language: fr,fr-fr;q=0.8,en-us;q=0.5,en;q=0.3
    35 RxHeader     c Accept-Encoding: gzip,deflate
    35 RxHeader     c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
    35 RxHeader     c Referer:
http://example.net/articles/the-rumours-are-true-a-book-about-plone-3
    35 RxHeader     c Max-Forwards: 10
    35 RxHeader     c X-Forwarded-For: 8.223.33.128
    35 RxHeader     c X-Forwarded-Host: example.net
    35 RxHeader     c X-Forwarded-Server: example.net
    35 VCL_call     c recv
    35 VCL_return   c lookup
    35 VCL_call     c hash
    35 VCL_return   c hash
    35 VCL_call     c miss
    35 VCL_return   c fetch
    38 BackendOpen  b default 127.0.0.1 37979 127.0.0.1 8080
    38 BackendXID   b 1892976565
    35 Backend      c 38 default
    38 TxRequest    b GET
    38 TxURL        b
/VirtualHostBase/http/example.net:80/blog/VirtualHostRoot//logo.gif
    38 TxProtocol   b HTTP/1.1
    38 TxHeader     b Host: localhost:8082
    38 TxHeader     b User-Agent: Mozilla/5.0 (X11; U; Linux i686;
en-US; rv:1.8.0.13) Gecko/20070824 Thunderbird/1.5.0.13
    38 TxHeader     b Accept: image/png,*/*;q=0.5
    38 TxHeader     b Accept-Language: fr,fr-fr;q=0.8,en-us;q=0.5,en;q=0.3
    38 TxHeader     b Accept-Encoding: gzip,deflate
    38 TxHeader     b Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
    38 TxHeader     b Referer:
http://example.net/articles/the-rumours-are-true-a-book-about-plone-3
    38 TxHeader     b Max-Forwards: 10
    38 TxHeader     b X-Forwarded-For: 8.223.33.128
    38 TxHeader     b X-Forwarded-Host: example.net
    38 TxHeader     b X-Forwarded-Server: example.net
    38 TxHeader     b X-Varnish: 1892976565
    38 TxHeader     b X-Forwarded-for: 127.0.0.1
    38 RxProtocol   b HTTP/1.1
    38 RxStatus     b 200
    38 RxResponse   b OK
    38 RxHeader     b Server: Zope/(Zope 2.10.4-final, python 2.4.4,
linux2) ZServer/1.1 Plone/3.0
    38 RxHeader     b Date: Wed, 05 Sep 2007 16:53:36 GMT
    38 RxHeader     b Last-Modified: Mon, 27 Aug 2007 20:09:52 GMT
    38 RxHeader     b Content-Length: 631
    38 RxHeader     b Content-Type: image/gif
    35 ObjProtocol  c HTTP/1.1
    35 ObjStatus    c 200
    35 ObjResponse  c OK
    35 ObjHeader    c Server: Zope/(Zope 2.10.4-final, python 2.4.4,
linux2) ZServer/1.1 Plone/3.0
    35 ObjHeader    c Date: Wed, 05 Sep 2007 16:53:36 GMT
    35 ObjHeader    c Last-Modified: Mon, 27 Aug 2007 20:09:52 GMT
    35 ObjHeader    c Content-Type: image/gif
    38 BackendReuse b default
    35 TTL          c 1892976565 RFC 120 1189011216 1189011216 0 0 0
    35 VCL_call     c fetch
    35 VCL_return   c insert
    35 Length       c 631
    35 VCL_call     c deliver
    35 VCL_return   c deliver
    35 TxProtocol   c HTTP/1.1
    35 TxStatus     c 200
    35 TxResponse   c OK
    35 TxHeader     c Server: Zope/(Zope 2.10.4-final, python 2.4.4,
linux2) ZServer/1.1 Plone/3.0
    35 TxHeader     c Date: Wed, 05 Sep 2007 16:53:36 GMT
    35 TxHeader     c Last-Modified: Mon, 27 Aug 2007 20:09:52 GMT
    35 TxHeader     c Content-Type: image/gif
    35 TxHeader     c Content-Length: 631
    35 TxHeader     c X-Varnish: 1892976565
    35 TxHeader     c Age: 0
    35 TxHeader     c Via: 1.1 varnish
    35 TxHeader     c Connection: keep-alive
    35 ReqEnd       c 1892976565 1189011216.232373953
1189011216.323524952 0.000535011 0.088789940 0.002361059
     0 StatAddr       127.0.0.1 0 949 46 98 0 0 30 33711 327792
    35 HttpError    c Received nothing
    35 SessionClose c no request
    35 StatSess     c 127.0.0.1 37978 0 1 1 0 0 1 299 631
    31 HttpError    c Received nothing
    31 SessionClose c no request
    31 StatSess     c 127.0.0.1 37977 0 1 1 0 0 1 298 61
    31 SessionOpen  c 127.0.0.1 37984
    31 ReqStart     c 127.0.0.1 37984 1892976566
    31 RxRequest    c GET
    31 RxURL        c //newsitem_icon.gif
    31 RxProtocol   c HTTP/1.1
    31 RxHeader     c Host: localhost:8082
    31 RxHeader     c User-Agent: Mozilla/5.0 (X11; U; Linux i686;
en-US; rv:1.8.0.13) Gecko/20070824 Thunderbird/1.5.0.13
    31 RxHeader     c Accept: image/png,*/*;q=0.5
    31 RxHeader     c Accept-Language: fr,fr-fr;q=0.8,en-us;q=0.5,en;q=0.3
    31 RxHeader     c Accept-Encoding: gzip,deflate
    31 RxHeader     c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
    31 RxHeader     c Referer:
http://example.net/articles/the-rumours-are-true-a-book-about-plone-3
    31 RxHeader     c Max-Forwards: 10
    31 RxHeader     c X-Forwarded-For: 8.223.33.128
    31 RxHeader     c X-Forwarded-Host: example.net
    31 RxHeader     c X-Forwarded-Server: example.net
    31 VCL_call     c recv
    31 VCL_return   c lookup
    31 VCL_call     c hash
    31 VCL_return   c hash
    31 Hit          c 1892976475
    31 VCL_call     c hit
    31 VCL_return   c deliver
    31 Length       c 952
    31 VCL_call     c deliver
    31 VCL_return   c deliver
    31 TxProtocol   c HTTP/1.1
    31 TxStatus     c 200
    31 TxResponse   c OK
    31 TxHeader     c Server: Zope/(Zope 2.10.4-final, python 2.4.4,
linux2) ZServer/1.1 Plone/3.0
    31 TxHeader     c Date: Wed, 05 Sep 2007 16:38:55 GMT
    31 TxHeader     c X-Cache-Headers-Set-By: CachingPolicyManager:
/blog/caching_policy_manager
    31 TxHeader     c Expires: Thu, 06 Sep 2007 16:38:55 GMT
    31 TxHeader     c Last-Modified: Sat, 11 Feb 2006 09:46:24 GMT
    31 TxHeader     c X-Caching-Rule-Id: httpcache
    31 TxHeader     c Cache-Control: max-age=86400, s-maxage=86400,
public, must-revalidate, proxy-revalidate
    31 TxHeader     c Content-Type: image/gif
    31 TxHeader     c X-Header-Set-Id: cache-in-browser-24-hours
    31 TxHeader     c Content-Length: 952
    31 TxHeader     c X-Varnish: 1892976566 1892976475
    31 TxHeader     c Age: 881
    31 TxHeader     c Via: 1.1 varnish
    31 TxHeader     c Connection: keep-alive
    31 ReqEnd       c 1892976566 1189011216.511989117
1189011216.512168884 0.000095129 0.000074863 0.000104904
     0 StatAddr       127.0.0.1 0 949 47 99 0 0 30 34302 328744
    35 SessionOpen  c 127.0.0.1 37985
    35 ReqStart     c 127.0.0.1 37985 1892976567
    35 RxRequest    c GET
    35 RxURL        c //image_icon.gif
    35 RxProtocol   c HTTP/1.1
    35 RxHeader     c Host: localhost:8082
    35 RxHeader     c User-Agent: Mozilla/5.0 (X11; U; Linux i686;
en-US; rv:1.8.0.13) Gecko/20070824 Thunderbird/1.5.0.13
    35 RxHeader     c Accept: image/png,*/*;q=0.5
    35 RxHeader     c Accept-Language: fr,fr-fr;q=0.8,en-us;q=0.5,en;q=0.3
    35 RxHeader     c Accept-Encoding: gzip,deflate
    35 RxHeader     c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
    35 RxHeader     c Referer:
http://example.net/articles/the-rumours-are-true-a-book-about-plone-3
    35 RxHeader     c Max-Forwards: 10
    35 RxHeader     c X-Forwarded-For: 8.223.33.128
    35 RxHeader     c X-Forwarded-Host: example.net
    35 RxHeader     c X-Forwarded-Server: example.net
    35 VCL_call     c recv
    35 VCL_return   c lookup
    35 VCL_call     c hash
    35 VCL_return   c hash
    35 Hit          c 1892976476
    35 VCL_call     c hit
    35 VCL_return   c deliver
    35 Length       c 931
    35 VCL_call     c deliver
    35 VCL_return   c deliver
    35 TxProtocol   c HTTP/1.1
    35 TxStatus     c 200
    35 TxResponse   c OK
    35 TxHeader     c Server: Zope/(Zope 2.10.4-final, python 2.4.4,
linux2) ZServer/1.1 Plone/3.0
    35 TxHeader     c Date: Wed, 05 Sep 2007 16:38:55 GMT
    35 TxHeader     c X-Cache-Headers-Set-By: CachingPolicyManager:
/blog/caching_policy_manager
    35 TxHeader     c Expires: Thu, 06 Sep 2007 16:38:55 GMT
    35 TxHeader     c Last-Modified: Sat, 11 Feb 2006 09:46:24 GMT
    35 TxHeader     c X-Caching-Rule-Id: httpcache
    35 TxHeader     c Cache-Control: max-age=86400, s-maxage=86400,
public, must-revalidate, proxy-revalidate
    35 TxHeader     c Content-Type: image/gif
    35 TxHeader     c X-Header-Set-Id: cache-in-browser-24-hours
    35 TxHeader     c Content-Length: 931
    35 TxHeader     c X-Varnish: 1892976567 1892976476
    35 TxHeader     c Age: 881
    35 TxHeader     c Via: 1.1 varnish
    35 TxHeader     c Connection: keep-alive
    35 ReqEnd       c 1892976567 1189011216.522527933
1189011216.522680044 0.000089884 0.000070095 0.000082016
     0 StatAddr       127.0.0.1 0 949 48 100 0 0 30 34893 329675
    31 HttpError    c Received nothing
    31 SessionClose c no request
    31 StatSess     c 127.0.0.1 37984 0 1 1 0 0 0 591 952
    35 HttpError    c Received nothing
    35 SessionClose c no request
    35 StatSess     c 127.0.0.1 37985 0 1 1 0 0 0 591 931
    31 SessionOpen  c 127.0.0.1 37987
    31 ReqStart     c 127.0.0.1 37987 1892976568
    31 RxRequest    c GET
    31 RxURL        c //arrowLeft.gif
    31 RxProtocol   c HTTP/1.1
    31 RxHeader     c Host: localhost:8082
    31 RxHeader     c User-Agent: Mozilla/5.0 (X11; U; Linux i686;
en-US; rv:1.8.0.13) Gecko/20070824 Thunderbird/1.5.0.13
    31 RxHeader     c Accept: image/png,*/*;q=0.5
    31 RxHeader     c Accept-Language: fr,fr-fr;q=0.8,en-us;q=0.5,en;q=0.3
    31 RxHeader     c Accept-Encoding: gzip,deflate
    31 RxHeader     c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
    31 RxHeader     c Referer:
http://example.net/articles/the-rumours-are-true-a-book-about-plone-3
    31 RxHeader     c Max-Forwards: 10
    31 RxHeader     c X-Forwarded-For: 8.223.33.128
    31 RxHeader     c X-Forwarded-Host: example.net
    31 RxHeader     c X-Forwarded-Server: example.net
    31 VCL_call     c recv
    31 VCL_return   c lookup
    31 VCL_call     c hash
    31 VCL_return   c hash
    31 Hit          c 1892976519
    31 VCL_call     c hit
    31 VCL_return   c deliver
    31 Length       c 99
    31 VCL_call     c deliver
    31 VCL_return   c deliver
    31 TxProtocol   c HTTP/1.1
    31 TxStatus     c 200
    31 TxResponse   c OK
    31 TxHeader     c Server: Zope/(Zope 2.10.4-final, python 2.4.4,
linux2) ZServer/1.1 Plone/3.0
    31 TxHeader     c Date: Wed, 05 Sep 2007 16:39:01 GMT
    31 TxHeader     c X-Cache-Headers-Set-By: CachingPolicyManager:
/blog/caching_policy_manager
    31 TxHeader     c Expires: Thu, 06 Sep 2007 16:39:01 GMT
    31 TxHeader     c Last-Modified: Sat, 11 Feb 2006 09:46:24 GMT
    31 TxHeader     c X-Caching-Rule-Id: httpcache
    31 TxHeader     c Cache-Control: max-age=86400, s-maxage=86400,
public, must-revalidate, proxy-revalidate
    31 TxHeader     c Content-Type: image/gif
    31 TxHeader     c X-Header-Set-Id: cache-in-browser-24-hours
    31 TxHeader     c Content-Length: 99
    31 TxHeader     c X-Varnish: 1892976568 1892976519
    31 TxHeader     c Age: 875
    31 TxHeader     c Via: 1.1 varnish
    31 TxHeader     c Connection: keep-alive
    31 ReqEnd       c 1892976568 1189011216.688266039
1189011216.688390970 0.000116110 0.000061989 0.000062943
     0 StatAddr       127.0.0.1 0 949 49 101 0 0 30 35483 329774
    35 SessionOpen  c 127.0.0.1 37988
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189011216
    31 HttpError    c Received nothing
    31 SessionClose c no request
    31 StatSess     c 127.0.0.1 37987 0 1 1 0 0 0 590 99
    35 ReqStart     c 127.0.0.1 37988 1892976569
    35 RxRequest    c GET
    35 RxURL        c //arrowRight.gif
    35 RxProtocol   c HTTP/1.1
    35 RxHeader     c Host: localhost:8082
    35 RxHeader     c User-Agent: Mozilla/5.0 (X11; U; Linux i686;
en-US; rv:1.8.0.13) Gecko/20070824 Thunderbird/1.5.0.13
    35 RxHeader     c Accept: image/png,*/*;q=0.5
    35 RxHeader     c Accept-Language: fr,fr-fr;q=0.8,en-us;q=0.5,en;q=0.3
    35 RxHeader     c Accept-Encoding: gzip,deflate
    35 RxHeader     c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
    35 RxHeader     c Referer:
http://example.net/articles/the-rumours-are-true-a-book-about-plone-3
    35 RxHeader     c Max-Forwards: 10
    35 RxHeader     c X-Forwarded-For: 8.223.33.128
    35 RxHeader     c X-Forwarded-Host: example.net
    35 RxHeader     c X-Forwarded-Server: example.net
    35 VCL_call     c recv
    35 VCL_return   c lookup
    35 VCL_call     c hash
    35 VCL_return   c hash
    35 VCL_call     c miss
    35 VCL_return   c fetch
    38 BackendXID   b 1892976569
    35 Backend      c 38 default
    38 TxRequest    b GET
    38 TxURL        b
/VirtualHostBase/http/example.net:80/blog/VirtualHostRoot//arrowRight.gif
    38 TxProtocol   b HTTP/1.1
    38 TxHeader     b Host: localhost:8082
    38 TxHeader     b User-Agent: Mozilla/5.0 (X11; U; Linux i686;
en-US; rv:1.8.0.13) Gecko/20070824 Thunderbird/1.5.0.13
    38 TxHeader     b Accept: image/png,*/*;q=0.5
    38 TxHeader     b Accept-Language: fr,fr-fr;q=0.8,en-us;q=0.5,en;q=0.3
    38 TxHeader     b Accept-Encoding: gzip,deflate
    38 TxHeader     b Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
    38 TxHeader     b Referer:
http://example.net/articles/the-rumours-are-true-a-book-about-plone-3
    38 TxHeader     b Max-Forwards: 10
    38 TxHeader     b X-Forwarded-For: 8.223.33.128
    38 TxHeader     b X-Forwarded-Host: example.net
    38 TxHeader     b X-Forwarded-Server: example.net
    38 TxHeader     b X-Varnish: 1892976569
    38 TxHeader     b X-Forwarded-for: 127.0.0.1
    38 RxProtocol   b HTTP/1.1
    38 RxStatus     b 200
    38 RxResponse   b OK
    38 RxHeader     b Server: Zope/(Zope 2.10.4-final, python 2.4.4,
linux2) ZServer/1.1 Plone/3.0
    38 RxHeader     b Date: Wed, 05 Sep 2007 16:53:36 GMT
    38 RxHeader     b Content-Length: 99
    38 RxHeader     b X-Cache-Headers-Set-By: CachingPolicyManager:
/blog/caching_policy_manager
    38 RxHeader     b Expires: Thu, 06 Sep 2007 16:53:36 GMT
    38 RxHeader     b Last-Modified: Sat, 11 Feb 2006 09:46:24 GMT
    38 RxHeader     b X-Caching-Rule-Id: httpcache
    38 RxHeader     b Cache-Control: max-age=86400, s-maxage=86400,
public, must-revalidate, proxy-revalidate
    38 RxHeader     b Content-Type: image/gif
    38 RxHeader     b X-Header-Set-Id: cache-in-browser-24-hours
    35 ObjProtocol  c HTTP/1.1
    35 ObjStatus    c 200
    35 ObjResponse  c OK
    35 ObjHeader    c Server: Zope/(Zope 2.10.4-final, python 2.4.4,
linux2) ZServer/1.1 Plone/3.0
    35 ObjHeader    c Date: Wed, 05 Sep 2007 16:53:36 GMT
    35 ObjHeader    c X-Cache-Headers-Set-By: CachingPolicyManager:
/blog/caching_policy_manager
    35 ObjHeader    c Expires: Thu, 06 Sep 2007 16:53:36 GMT
    35 ObjHeader    c Last-Modified: Sat, 11 Feb 2006 09:46:24 GMT
    35 ObjHeader    c X-Caching-Rule-Id: httpcache
    35 ObjHeader    c Cache-Control: max-age=86400, s-maxage=86400,
public, must-revalidate, proxy-revalidate
    35 ObjHeader    c Content-Type: image/gif
    35 ObjHeader    c X-Header-Set-Id: cache-in-browser-24-hours
    38 BackendReuse b default
    35 TTL          c 1892976569 RFC 86399 1189011216 1189011216
1189097616 86400 0
    35 VCL_call     c fetch
    35 VCL_return   c insert
    35 Length       c 99
    35 VCL_call     c deliver
    35 VCL_return   c deliver
    35 TxProtocol   c HTTP/1.1
    35 TxStatus     c 200
    35 TxResponse   c OK
    35 TxHeader     c Server: Zope/(Zope 2.10.4-final, python 2.4.4,
linux2) ZServer/1.1 Plone/3.0
    35 TxHeader     c Date: Wed, 05 Sep 2007 16:53:36 GMT
    35 TxHeader     c X-Cache-Headers-Set-By: CachingPolicyManager:
/blog/caching_policy_manager
    35 TxHeader     c Expires: Thu, 06 Sep 2007 16:53:36 GMT
    35 TxHeader     c Last-Modified: Sat, 11 Feb 2006 09:46:24 GMT
    35 TxHeader     c X-Caching-Rule-Id: httpcache
    35 TxHeader     c Cache-Control: max-age=86400, s-maxage=86400,
public, must-revalidate, proxy-revalidate
    35 TxHeader     c Content-Type: image/gif
    35 TxHeader     c X-Header-Set-Id: cache-in-browser-24-hours
    35 TxHeader     c Content-Length: 99
    35 TxHeader     c X-Varnish: 1892976569
    35 TxHeader     c Age: 0
    35 TxHeader     c Via: 1.1 varnish
    35 TxHeader     c Connection: keep-alive
    35 ReqEnd       c 1892976569 1189011216.714818954
1189011216.796236038 0.000118017 0.081356049 0.000061035
     0 StatAddr       127.0.0.1 0 949 50 102 0 0 31 36060 329873
    31 SessionOpen  c 127.0.0.1 37993
    31 VCL_acl      c MATCH purge "localhost"
    31 ReqStart     c 127.0.0.1 37993 1892976570
    31 RxRequest    c PURGE
    31 RxURL        c
/VirtualHostBase/http/example.net:80/blog/VirtualHostRoot/arrowRight.gif/%28dynamic%20view%29
    31 RxProtocol   c HTTP/1.1
    31 RxHeader     c Host: 127.0.0.1:8082
    31 RxHeader     c Accept-Encoding: identity
    31 VCL_call     c recv
    31 VCL_return   c lookup
    31 VCL_call     c hash
    31 VCL_return   c hash
    31 VCL_call     c miss
     0 Debug          "VCL_error(404, Not in cache)"
    31 VCL_return   c error
    31 Length       c 425
    31 TxProtocol   c HTTP/1.0
    31 TxStatus     c 404
    31 TxResponse   c Not Found
    31 TxHeader     c Date: Wed, 05 Sep 2007 16:53:36 GMT
    31 TxHeader     c Server: Varnish
    31 TxHeader     c Retry-After: 0
    31 TxHeader     c Content-Type: text/html; charset=utf-8
    31 TxHeader     c Content-Length: 425
    31 TxHeader     c X-Varnish: 1892976570
    31 TxHeader     c Age: nan
    31 TxHeader     c Via: 1.1 varnish
    31 TxHeader     c Connection: keep-alive
    31 ReqEnd       c 1892976570 1189011216.798091888
1189011216.798286915 0.002460003 nan nan
     0 StatAddr       127.0.0.1 0 949 51 103 0 0 31 36292 330298
    31 VCL_acl      c MATCH purge "localhost"
    31 ReqStart     c 127.0.0.1 37993 1892976571
    31 RxRequest    c PURGE
    31 RxURL        c
/VirtualHostBase/http/example.net:80/blog/VirtualHostRoot/arrowRight.gif/
    31 RxProtocol   c HTTP/1.1
    31 RxHeader     c Host: 127.0.0.1:8082
    31 RxHeader     c Accept-Encoding: identity
    31 VCL_call     c recv
    31 VCL_return   c lookup
    31 VCL_call     c hash
    31 VCL_return   c hash
    31 VCL_call     c miss
     0 Debug          "VCL_error(404, Not in cache)"
    31 VCL_return   c error
    31 Length       c 425
    31 TxProtocol   c HTTP/1.0
    31 TxStatus     c 404
    31 TxResponse   c Not Found
    31 TxHeader     c Date: Wed, 05 Sep 2007 16:53:36 GMT
    31 TxHeader     c Server: Varnish
    31 TxHeader     c Retry-After: 0
    31 TxHeader     c Content-Type: text/html; charset=utf-8
    31 TxHeader     c Content-Length: 425
    31 TxHeader     c X-Varnish: 1892976571
    31 TxHeader     c Age: nan
    31 TxHeader     c Via: 1.1 varnish
    31 TxHeader     c Connection: keep-alive
    31 ReqEnd       c 1892976571 1189011216.805568933
1189011216.805711031 0.007282019 nan nan
     0 StatAddr       127.0.0.1 0 949 51 104 0 0 31 36524 330723
    31 VCL_acl      c MATCH purge "localhost"
    31 ReqStart     c 127.0.0.1 37993 1892976572
    31 RxRequest    c PURGE
    31 RxURL        c
/VirtualHostBase/http/example.net:80/blog/VirtualHostRoot/arrowRight.gif
    31 RxProtocol   c HTTP/1.1
    31 RxHeader     c Host: 127.0.0.1:8082
    31 RxHeader     c Accept-Encoding: identity
    31 VCL_call     c recv
    31 VCL_return   c lookup
    31 VCL_call     c hash
    31 VCL_return   c hash
    31 VCL_call     c miss
     0 Debug          "VCL_error(404, Not in cache)"
    31 VCL_return   c error
    31 Length       c 425
    31 TxProtocol   c HTTP/1.0
    31 TxStatus     c 404
    31 TxResponse   c Not Found
    31 TxHeader     c Date: Wed, 05 Sep 2007 16:53:36 GMT
    31 TxHeader     c Server: Varnish
    31 TxHeader     c Retry-After: 0
    31 TxHeader     c Content-Type: text/html; charset=utf-8
    31 TxHeader     c Content-Length: 425
    31 TxHeader     c X-Varnish: 1892976572
    31 TxHeader     c Age: nan
    31 TxHeader     c Via: 1.1 varnish
    31 TxHeader     c Connection: keep-alive
    31 ReqEnd       c 1892976572 1189011216.812565088
1189011216.812725067 0.006854057 nan nan
     0 StatAddr       127.0.0.1 0 949 51 105 0 0 31 36756 331148
    31 VCL_acl      c MATCH purge "localhost"
    31 ReqStart     c 127.0.0.1 37993 1892976573
    31 RxRequest    c PURGE
    31 RxURL        c
/VirtualHostBase/http/example.net:80/blog/VirtualHostRoot/arrowRight.gif/folder_contents
    31 RxProtocol   c HTTP/1.1
    31 RxHeader     c Host: 127.0.0.1:8082
    31 RxHeader     c Accept-Encoding: identity
    31 VCL_call     c recv
    31 VCL_return   c lookup
    31 VCL_call     c hash
    31 VCL_return   c hash
    31 VCL_call     c miss
     0 Debug          "VCL_error(404, Not in cache)"
    31 VCL_return   c error
    31 Length       c 425
    31 TxProtocol   c HTTP/1.0
    31 TxStatus     c 404
    31 TxResponse   c Not Found
    31 TxHeader     c Date: Wed, 05 Sep 2007 16:53:36 GMT
    31 TxHeader     c Server: Varnish
    31 TxHeader     c Retry-After: 0
    31 TxHeader     c Content-Type: text/html; charset=utf-8
    31 TxHeader     c Content-Length: 425
    31 TxHeader     c X-Varnish: 1892976573
    31 TxHeader     c Age: nan
    31 TxHeader     c Via: 1.1 varnish
    31 TxHeader     c Connection: keep-alive
    31 ReqEnd       c 1892976573 1189011216.819152117
1189011216.819294930 0.006427050 nan nan
     0 StatAddr       127.0.0.1 0 949 51 106 0 0 31 36988 331573
    31 VCL_acl      c MATCH purge "localhost"
    31 ReqStart     c 127.0.0.1 37993 1892976574
    31 RxRequest    c PURGE
    31 RxURL        c
/VirtualHostBase/http/example.net:80/blog/VirtualHostRoot/arrowRight.gif/RSS
    31 RxProtocol   c HTTP/1.1
    31 RxHeader     c Host: 127.0.0.1:8082
    31 RxHeader     c Accept-Encoding: identity
    31 VCL_call     c recv
    31 VCL_return   c lookup
    31 VCL_call     c hash
    31 VCL_return   c hash
    31 VCL_call     c miss
     0 Debug          "VCL_error(404, Not in cache)"
    31 VCL_return   c error
    31 Length       c 425
    31 TxProtocol   c HTTP/1.0
    31 TxStatus     c 404
    31 TxResponse   c Not Found
    31 TxHeader     c Date: Wed, 05 Sep 2007 16:53:36 GMT
    31 TxHeader     c Server: Varnish
    31 TxHeader     c Retry-After: 0
    31 TxHeader     c Content-Type: text/html; charset=utf-8
    31 TxHeader     c Content-Length: 425
    31 TxHeader     c X-Varnish: 1892976574
    31 TxHeader     c Age: nan
    31 TxHeader     c Via: 1.1 varnish
    31 TxHeader     c Connection: keep-alive
    31 ReqEnd       c 1892976574 1189011216.826606989
1189011216.826745033 0.007312059 nan nan
     0 StatAddr       127.0.0.1 0 949 51 107 0 0 31 37220 331998
    31 VCL_acl      c MATCH purge "localhost"
    31 ReqStart     c 127.0.0.1 37993 1892976575
    31 RxRequest    c PURGE
    31 RxURL        c
/VirtualHostBase/http/example.net:80/blog/VirtualHostRoot/arrowRight.gif/view
    31 RxProtocol   c HTTP/1.1
    31 RxHeader     c Host: 127.0.0.1:8082
    31 RxHeader     c Accept-Encoding: identity
    31 VCL_call     c recv
    31 VCL_return   c lookup
    31 VCL_call     c hash
    31 VCL_return   c hash
    31 VCL_call     c miss
     0 Debug          "VCL_error(404, Not in cache)"
    31 VCL_return   c error
    31 Length       c 425
    31 TxProtocol   c HTTP/1.0
    31 TxStatus     c 404
    31 TxResponse   c Not Found
    31 TxHeader     c Date: Wed, 05 Sep 2007 16:53:36 GMT
    31 TxHeader     c Server: Varnish
    31 TxHeader     c Retry-After: 0
    31 TxHeader     c Content-Type: text/html; charset=utf-8
    31 TxHeader     c Content-Length: 425
    31 TxHeader     c X-Varnish: 1892976575
    31 TxHeader     c Age: nan
    31 TxHeader     c Via: 1.1 varnish
    31 TxHeader     c Connection: keep-alive
    31 ReqEnd       c 1892976575 1189011216.833184958
1189011216.833395958 0.006439924 nan nan
     0 StatAddr       127.0.0.1 0 949 51 108 0 0 31 37452 332423
    39 SessionOpen  c 127.0.0.1 37994
    39 ReqStart     c 127.0.0.1 37994 1892976576
    39 RxRequest    c GET
    39 RxURL        c //spinner.gif
    39 RxProtocol   c HTTP/1.1
    39 RxHeader     c Host: localhost:8082
    39 RxHeader     c User-Agent: Mozilla/5.0 (X11; U; Linux i686;
en-US; rv:1.8.0.13) Gecko/20070824 Thunderbird/1.5.0.13
    39 RxHeader     c Accept: image/png,*/*;q=0.5
    39 RxHeader     c Accept-Language: fr,fr-fr;q=0.8,en-us;q=0.5,en;q=0.3
    39 RxHeader     c Accept-Encoding: gzip,deflate
    39 RxHeader     c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
    39 RxHeader     c Referer:
http://example.net/articles/the-rumours-are-true-a-book-about-plone-3
    39 RxHeader     c Max-Forwards: 10
    39 RxHeader     c X-Forwarded-For: 8.223.33.128
    39 RxHeader     c X-Forwarded-Host: example.net
    39 RxHeader     c X-Forwarded-Server: example.net
    39 VCL_call     c recv
    39 VCL_return   c lookup
    39 VCL_call     c hash
    39 VCL_return   c hash
    39 Hit          c 1892976502
    39 VCL_call     c hit
    39 VCL_return   c deliver
    39 Length       c 2037
    39 VCL_call     c deliver
    39 VCL_return   c deliver
    39 TxProtocol   c HTTP/1.1
    39 TxStatus     c 200
    39 TxResponse   c OK
    39 TxHeader     c Server: Zope/(Zope 2.10.4-final, python 2.4.4,
linux2) ZServer/1.1 Plone/3.0
    39 TxHeader     c Date: Wed, 05 Sep 2007 16:38:56 GMT
    39 TxHeader     c X-Cache-Headers-Set-By: CachingPolicyManager:
/blog/caching_policy_manager
    39 TxHeader     c Expires: Thu, 06 Sep 2007 16:38:56 GMT
    39 TxHeader     c Last-Modified: Mon, 18 Jun 2007 08:28:23 GMT
    39 TxHeader     c X-Caching-Rule-Id: httpcache
    39 TxHeader     c Cache-Control: max-age=86400, s-maxage=86400,
public, must-revalidate, proxy-revalidate
    39 TxHeader     c Content-Type: image/gif
    39 TxHeader     c X-Header-Set-Id: cache-in-browser-24-hours
    39 TxHeader     c Content-Length: 2037
    39 TxHeader     c X-Varnish: 1892976576 1892976502
    39 TxHeader     c Age: 880
    39 TxHeader     c Via: 1.1 varnish
    39 TxHeader     c Connection: keep-alive
    39 ReqEnd       c 1892976576 1189011216.841237068
1189011216.841363907 0.002560139 0.000052929 0.000073910
     0 StatAddr       127.0.0.1 0 949 52 109 0 0 31 38044 334460
    31 VCL_acl      c MATCH purge "localhost"
    31 ReqStart     c 127.0.0.1 37993 1892976577
    31 RxRequest    c PURGE
    31 RxURL        c
/VirtualHostBase/http/example.net:80/blog/VirtualHostRoot/arrowRight.gif/%28dynamic%20view%29
    31 RxProtocol   c HTTP/1.1
    31 RxHeader     c Host: 127.0.0.1:8082
    31 RxHeader     c Accept-Encoding: identity
    31 VCL_call     c recv
    31 VCL_return   c lookup
    31 VCL_call     c hash
    31 VCL_return   c hash
    31 VCL_call     c miss
     0 Debug          "VCL_error(404, Not in cache)"
    31 VCL_return   c error
    31 Length       c 425
    31 TxProtocol   c HTTP/1.0
    31 TxStatus     c 404
    31 TxResponse   c Not Found
    31 TxHeader     c Date: Wed, 05 Sep 2007 16:53:36 GMT
    31 TxHeader     c Server: Varnish
    31 TxHeader     c Retry-After: 0
    31 TxHeader     c Content-Type: text/html; charset=utf-8
    31 TxHeader     c Content-Length: 425
    31 TxHeader     c X-Varnish: 1892976577
    31 TxHeader     c Age: nan
    31 TxHeader     c Via: 1.1 varnish
    31 TxHeader     c Connection: keep-alive
    31 ReqEnd       c 1892976577 1189011216.842278004
1189011216.842431068 0.008882046 nan nan
     0 StatAddr       127.0.0.1 0 949 52 110 0 0 31 38276 334885
    31 VCL_acl      c MATCH purge "localhost"
    31 ReqStart     c 127.0.0.1 37993 1892976578
    31 RxRequest    c PURGE
    31 RxURL        c
/VirtualHostBase/http/example.net:80/blog/VirtualHostRoot/arrowRight.gif/
    31 RxProtocol   c HTTP/1.1
    31 RxHeader     c Host: 127.0.0.1:8082
    31 RxHeader     c Accept-Encoding: identity
    31 VCL_call     c recv
    31 VCL_return   c lookup
    31 VCL_call     c hash
    31 VCL_return   c hash
    31 VCL_call     c miss
     0 Debug          "VCL_error(404, Not in cache)"
    31 VCL_return   c error
    31 Length       c 425
    31 TxProtocol   c HTTP/1.0
    31 TxStatus     c 404
    31 TxResponse   c Not Found
    31 TxHeader     c Date: Wed, 05 Sep 2007 16:53:36 GMT
    31 TxHeader     c Server: Varnish
    31 TxHeader     c Retry-After: 0
    31 TxHeader     c Content-Type: text/html; charset=utf-8
    31 TxHeader     c Content-Length: 425
    31 TxHeader     c X-Varnish: 1892976578
    31 TxHeader     c Age: nan
    31 TxHeader     c Via: 1.1 varnish
    31 TxHeader     c Connection: keep-alive
    31 ReqEnd       c 1892976578 1189011216.849272013
1189011216.849400043 0.006840944 nan nan
     0 StatAddr       127.0.0.1 0 949 52 111 0 0 31 38508 335310
    31 VCL_acl      c MATCH purge "localhost"
    31 ReqStart     c 127.0.0.1 37993 1892976579
    31 RxRequest    c PURGE
    31 RxURL        c
/VirtualHostBase/http/example.net:80/blog/VirtualHostRoot/arrowRight.gif
    31 RxProtocol   c HTTP/1.1
    31 RxHeader     c Host: 127.0.0.1:8082
    31 RxHeader     c Accept-Encoding: identity
    31 VCL_call     c recv
    31 VCL_return   c lookup
    31 VCL_call     c hash
    31 VCL_return   c hash
    31 VCL_call     c miss
     0 Debug          "VCL_error(404, Not in cache)"
    31 VCL_return   c error
    31 Length       c 425
    31 TxProtocol   c HTTP/1.0
    31 TxStatus     c 404
    31 TxResponse   c Not Found
    31 TxHeader     c Date: Wed, 05 Sep 2007 16:53:36 GMT
    31 TxHeader     c Server: Varnish
    31 TxHeader     c Retry-After: 0
    31 TxHeader     c Content-Type: text/html; charset=utf-8
    31 TxHeader     c Content-Length: 425
    31 TxHeader     c X-Varnish: 1892976579
    31 TxHeader     c Age: nan
    31 TxHeader     c Via: 1.1 varnish
    31 TxHeader     c Connection: keep-alive
    31 ReqEnd       c 1892976579 1189011216.856280088
1189011216.856405973 0.006880045 nan nan
     0 StatAddr       127.0.0.1 0 949 52 112 0 0 31 38740 335735
    35 HttpError    c Received nothing
    35 SessionClose c no request
    35 StatSess     c 127.0.0.1 37988 0 1 1 0 0 1 577 99
    31 VCL_acl      c MATCH purge "localhost"
    31 ReqStart     c 127.0.0.1 37993 1892976580
    31 RxRequest    c PURGE
    31 RxURL        c
/VirtualHostBase/http/example.net:80/blog/VirtualHostRoot/arrowRight.gif/folder_contents
    31 RxProtocol   c HTTP/1.1
    31 RxHeader     c Host: 127.0.0.1:8082
    31 RxHeader     c Accept-Encoding: identity
    31 VCL_call     c recv
    31 VCL_return   c lookup
    31 VCL_call     c hash
    31 VCL_return   c hash
    31 VCL_call     c miss
     0 Debug          "VCL_error(404, Not in cache)"
    31 VCL_return   c error
    31 Length       c 425
    31 TxProtocol   c HTTP/1.0
    31 TxStatus     c 404
    31 TxResponse   c Not Found
    31 TxHeader     c Date: Wed, 05 Sep 2007 16:53:36 GMT
    31 TxHeader     c Server: Varnish
    31 TxHeader     c Retry-After: 0
    31 TxHeader     c Content-Type: text/html; charset=utf-8
    31 TxHeader     c Content-Length: 425
    31 TxHeader     c X-Varnish: 1892976580
    31 TxHeader     c Age: nan
    31 TxHeader     c Via: 1.1 varnish
    31 TxHeader     c Connection: keep-alive
    31 ReqEnd       c 1892976580 1189011216.863306046
1189011216.863451004 0.006900072 nan nan
     0 StatAddr       127.0.0.1 0 949 52 113 0 0 31 38972 336160
    31 VCL_acl      c MATCH purge "localhost"
    31 ReqStart     c 127.0.0.1 37993 1892976581
    31 RxRequest    c PURGE
    31 RxURL        c
/VirtualHostBase/http/example.net:80/blog/VirtualHostRoot/arrowRight.gif/RSS
    31 RxProtocol   c HTTP/1.1
    31 RxHeader     c Host: 127.0.0.1:8082
    31 RxHeader     c Accept-Encoding: identity
    31 VCL_call     c recv
    31 VCL_return   c lookup
    31 VCL_call     c hash
    31 VCL_return   c hash
    31 VCL_call     c miss
     0 Debug          "VCL_error(404, Not in cache)"
    31 VCL_return   c error
    31 Length       c 425
    31 TxProtocol   c HTTP/1.0
    31 TxStatus     c 404
    31 TxResponse   c Not Found
    31 TxHeader     c Date: Wed, 05 Sep 2007 16:53:36 GMT
    31 TxHeader     c Server: Varnish
    31 TxHeader     c Retry-After: 0
    31 TxHeader     c Content-Type: text/html; charset=utf-8
    31 TxHeader     c Content-Length: 425
    31 TxHeader     c X-Varnish: 1892976581
    31 TxHeader     c Age: nan
    31 TxHeader     c Via: 1.1 varnish
    31 TxHeader     c Connection: keep-alive
    31 ReqEnd       c 1892976581 1189011216.870321035
1189011216.870450020 0.006870031 nan nan
     0 StatAddr       127.0.0.1 0 949 52 114 0 0 31 39204 336585
    31 VCL_acl      c MATCH purge "localhost"
    31 ReqStart     c 127.0.0.1 37993 1892976582
    31 RxRequest    c PURGE
    31 RxURL        c
/VirtualHostBase/http/example.net:80/blog/VirtualHostRoot/arrowRight.gif/view
    31 RxProtocol   c HTTP/1.1
    31 RxHeader     c Host: 127.0.0.1:8082
    31 RxHeader     c Accept-Encoding: identity
    31 VCL_call     c recv
    31 VCL_return   c lookup
    31 VCL_call     c hash
    31 VCL_return   c hash
    31 VCL_call     c miss
     0 Debug          "VCL_error(404, Not in cache)"
    31 VCL_return   c error
    31 Length       c 425
    31 TxProtocol   c HTTP/1.0
    31 TxStatus     c 404
    31 TxResponse   c Not Found
    31 TxHeader     c Date: Wed, 05 Sep 2007 16:53:36 GMT
    31 TxHeader     c Server: Varnish
    31 TxHeader     c Retry-After: 0
    31 TxHeader     c Content-Type: text/html; charset=utf-8
    31 TxHeader     c Content-Length: 425
    31 TxHeader     c X-Varnish: 1892976582
    31 TxHeader     c Age: nan
    31 TxHeader     c Via: 1.1 varnish
    31 TxHeader     c Connection: keep-alive
    31 ReqEnd       c 1892976582 1189011216.877748966
1189011216.877892017 0.007298946 nan nan
     0 StatAddr       127.0.0.1 0 949 52 115 0 0 31 39436 337010
    39 HttpError    c Received nothing
    39 SessionClose c no request
    39 StatSess     c 127.0.0.1 37994 0 1 1 0 0 0 592 2037
    35 SessionOpen  c 127.0.0.1 37995
    35 ReqStart     c 127.0.0.1 37995 1892976583
    35 RxRequest    c GET
    35 RxURL        c //portal_css/Optilude%20Theme/breadCrumbDivider.gif
    35 RxProtocol   c HTTP/1.1
    35 RxHeader     c Host: localhost:8082
    35 RxHeader     c User-Agent: Mozilla/5.0 (X11; U; Linux i686;
en-US; rv:1.8.0.13) Gecko/20070824 Thunderbird/1.5.0.13
    35 RxHeader     c Accept: image/png,*/*;q=0.5
    35 RxHeader     c Accept-Language: fr,fr-fr;q=0.8,en-us;q=0.5,en;q=0.3
    35 RxHeader     c Accept-Encoding: gzip,deflate
    35 RxHeader     c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
    35 RxHeader     c Referer:
http://example.net/portal_css/Optilude%20Theme/nuplone-cachekey0680.css
    35 RxHeader     c Max-Forwards: 10
    35 RxHeader     c X-Forwarded-For: 8.223.33.128
    35 RxHeader     c X-Forwarded-Host: example.net
    35 RxHeader     c X-Forwarded-Server: example.net
    35 VCL_call     c recv
    35 VCL_return   c lookup
    35 VCL_call     c hash
    35 VCL_return   c hash
    35 VCL_call     c miss
    35 VCL_return   c fetch
    38 BackendXID   b 1892976583
    35 Backend      c 38 default
    38 TxRequest    b GET
    38 TxURL        b
/VirtualHostBase/http/example.net:80/blog/VirtualHostRoot//portal_css/Optilude%20Theme/breadCrumbDivider.gif
    38 TxProtocol   b HTTP/1.1
    38 TxHeader     b Host: localhost:8082
    38 TxHeader     b User-Agent: Mozilla/5.0 (X11; U; Linux i686;
en-US; rv:1.8.0.13) Gecko/20070824 Thunderbird/1.5.0.13
    38 TxHeader     b Accept: image/png,*/*;q=0.5
    38 TxHeader     b Accept-Language: fr,fr-fr;q=0.8,en-us;q=0.5,en;q=0.3
    38 TxHeader     b Accept-Encoding: gzip,deflate
    38 TxHeader     b Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
    38 TxHeader     b Referer:
http://example.net/portal_css/Optilude%20Theme/nuplone-cachekey0680.css
    38 TxHeader     b Max-Forwards: 10
    38 TxHeader     b X-Forwarded-For: 8.223.33.128
    38 TxHeader     b X-Forwarded-Host: example.net
    38 TxHeader     b X-Forwarded-Server: example.net
    38 TxHeader     b X-Varnish: 1892976583
    38 TxHeader     b X-Forwarded-for: 127.0.0.1
    38 RxProtocol   b HTTP/1.1
    38 RxStatus     b 200
    38 RxResponse   b OK
    38 RxHeader     b Server: Zope/(Zope 2.10.4-final, python 2.4.4,
linux2) ZServer/1.1 Plone/3.0
    38 RxHeader     b Date: Wed, 05 Sep 2007 16:53:36 GMT
    38 RxHeader     b Last-Modified: Mon, 27 Aug 2007 20:09:52 GMT
    38 RxHeader     b Content-Length: 42
    38 RxHeader     b Content-Type: image/gif
    35 ObjProtocol  c HTTP/1.1
    35 ObjStatus    c 200
    35 ObjResponse  c OK
    35 ObjHeader    c Server: Zope/(Zope 2.10.4-final, python 2.4.4,
linux2) ZServer/1.1 Plone/3.0
    35 ObjHeader    c Date: Wed, 05 Sep 2007 16:53:36 GMT
    35 ObjHeader    c Last-Modified: Mon, 27 Aug 2007 20:09:52 GMT
    35 ObjHeader    c Content-Type: image/gif
    38 BackendReuse b default
    35 TTL          c 1892976583 RFC 120 1189011216 1189011216 0 0 0
    35 VCL_call     c fetch
    35 VCL_return   c insert
    35 Length       c 42
    35 VCL_call     c deliver
    35 VCL_return   c deliver
    35 TxProtocol   c HTTP/1.1
    35 TxStatus     c 200
    35 TxResponse   c OK
    35 TxHeader     c Server: Zope/(Zope 2.10.4-final, python 2.4.4,
linux2) ZServer/1.1 Plone/3.0
    35 TxHeader     c Date: Wed, 05 Sep 2007 16:53:36 GMT
    35 TxHeader     c Last-Modified: Mon, 27 Aug 2007 20:09:52 GMT
    35 TxHeader     c Content-Type: image/gif
    35 TxHeader     c Content-Length: 42
    35 TxHeader     c X-Varnish: 1892976583
    35 TxHeader     c Age: 0
    35 TxHeader     c Via: 1.1 varnish
    35 TxHeader     c Connection: keep-alive
    35 ReqEnd       c 1892976583 1189011216.949131966
1189011216.997659922 0.000112057 0.048439026 0.000088930
     0 StatAddr       127.0.0.1 0 949 53 116 0 0 32 39734 337052
    39 SessionOpen  c 127.0.0.1 37998
    39 ReqStart     c 127.0.0.1 37998 1892976584
    39 RxRequest    c GET
    39 RxURL        c //portal_css/Optilude%20Theme/searchField.png
    39 RxProtocol   c HTTP/1.1
    39 RxHeader     c Host: localhost:8082
    39 RxHeader     c User-Agent: Mozilla/5.0 (X11; U; Linux i686;
en-US; rv:1.8.0.13) Gecko/20070824 Thunderbird/1.5.0.13
    39 RxHeader     c Accept: image/png,*/*;q=0.5
    39 RxHeader     c Accept-Language: fr,fr-fr;q=0.8,en-us;q=0.5,en;q=0.3
    39 RxHeader     c Accept-Encoding: gzip,deflate
    39 RxHeader     c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
    39 RxHeader     c Referer:
http://example.net/portal_css/Optilude%20Theme/nuplone-cachekey0680.css
    39 RxHeader     c Max-Forwards: 10
    39 RxHeader     c X-Forwarded-For: 8.223.33.128
    39 RxHeader     c X-Forwarded-Host: example.net
    39 RxHeader     c X-Forwarded-Server: example.net
    39 VCL_call     c recv
    39 VCL_return   c lookup
    39 VCL_call     c hash
    39 VCL_return   c hash
    39 VCL_call     c miss
    39 VCL_return   c fetch
    38 BackendXID   b 1892976584
    39 Backend      c 38 default
    38 TxRequest    b GET
    38 TxURL        b
/VirtualHostBase/http/example.net:80/blog/VirtualHostRoot//portal_css/Optilude%20Theme/searchField.png
    38 TxProtocol   b HTTP/1.1
    38 TxHeader     b Host: localhost:8082
    38 TxHeader     b User-Agent: Mozilla/5.0 (X11; U; Linux i686;
en-US; rv:1.8.0.13) Gecko/20070824 Thunderbird/1.5.0.13
    38 TxHeader     b Accept: image/png,*/*;q=0.5
    38 TxHeader     b Accept-Language: fr,fr-fr;q=0.8,en-us;q=0.5,en;q=0.3
    38 TxHeader     b Accept-Encoding: gzip,deflate
    38 TxHeader     b Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
    38 TxHeader     b Referer:
http://example.net/portal_css/Optilude%20Theme/nuplone-cachekey0680.css
    38 TxHeader     b Max-Forwards: 10
    38 TxHeader     b X-Forwarded-For: 8.223.33.128
    38 TxHeader     b X-Forwarded-Host: example.net
    38 TxHeader     b X-Forwarded-Server: example.net
    38 TxHeader     b X-Varnish: 1892976584
    38 TxHeader     b X-Forwarded-for: 127.0.0.1
    38 RxProtocol   b HTTP/1.1
    38 RxStatus     b 200
    38 RxResponse   b OK
    38 RxHeader     b Server: Zope/(Zope 2.10.4-final, python 2.4.4,
linux2) ZServer/1.1 Plone/3.0
    38 RxHeader     b Date: Wed, 05 Sep 2007 16:53:37 GMT
    38 RxHeader     b Last-Modified: Mon, 27 Aug 2007 20:09:52 GMT
    38 RxHeader     b Content-Length: 4306
    38 RxHeader     b Content-Type: image/png
    39 ObjProtocol  c HTTP/1.1
    39 ObjStatus    c 200
    39 ObjResponse  c OK
    39 ObjHeader    c Server: Zope/(Zope 2.10.4-final, python 2.4.4,
linux2) ZServer/1.1 Plone/3.0
    39 ObjHeader    c Date: Wed, 05 Sep 2007 16:53:37 GMT
    39 ObjHeader    c Last-Modified: Mon, 27 Aug 2007 20:09:52 GMT
    39 ObjHeader    c Content-Type: image/png
    38 BackendReuse b default
    39 TTL          c 1892976584 RFC 120 1189011217 1189011217 0 0 0
    39 VCL_call     c fetch
    39 VCL_return   c insert
    39 Length       c 4306
    39 VCL_call     c deliver
    39 VCL_return   c deliver
    39 TxProtocol   c HTTP/1.1
    39 TxStatus     c 200
    39 TxResponse   c OK
    39 TxHeader     c Server: Zope/(Zope 2.10.4-final, python 2.4.4,
linux2) ZServer/1.1 Plone/3.0
    39 TxHeader     c Date: Wed, 05 Sep 2007 16:53:37 GMT
    39 TxHeader     c Last-Modified: Mon, 27 Aug 2007 20:09:52 GMT
    39 TxHeader     c Content-Type: image/png
    39 TxHeader     c Content-Length: 4306
    39 TxHeader     c X-Varnish: 1892976584
    39 TxHeader     c Age: 0
    39 TxHeader     c Via: 1.1 varnish
    39 TxHeader     c Connection: keep-alive
    39 ReqEnd       c 1892976584 1189011217.015980005
1189011217.065607071 0.000149012 0.049546003 0.000081062
     0 StatAddr       127.0.0.1 0 949 54 117 0 0 33 40034 341358
    35 HttpError    c Received nothing
    35 SessionClose c no request
    35 StatSess     c 127.0.0.1 37995 0 1 1 0 0 1 298 42
    39 HttpError    c Received nothing
    39 SessionClose c no request
    39 StatSess     c 127.0.0.1 37998 0 1 1 0 0 1 300 4306
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189011219
    31 SessionClose c timeout
    31 StatSess     c 127.0.0.1 37993 0 1 12 0 0 0 2784 5100
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189011222
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189011225
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189011228


Lots of pings... then new error.



-- 
Acquisition is a jealous mistress



From phk at phk.freebsd.dk  Wed Sep  5 21:04:58 2007
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Wed, 05 Sep 2007 21:04:58 +0000
Subject: Varnish 
In-Reply-To: Your message of "Wed, 05 Sep 2007 13:33:18 MST."
	<46DF128E.9040002@wheelhouse.org> 
Message-ID: <9675.1189026298@critter.freebsd.dk>

In message <46DF128E.9040002 at wheelhouse.org>, Jeff writes:
>Poul-Henning Kamp wrote:
>> I'm not sure we know exactly how we want to handle it.
>> 
>> One option is to let people rewrite in vcl_error() and restart the
>> transaction with the (presumably) new url.
>
>Would that be difficult?  In such a case, I gather the guru would hang 
>around to meditate on double-faults, thus avoiding loops?

The plan is to have a "max restarts per request" parameter to break
such loops.

>> putting some relevant in-line C code in your VCL
>> file is probably your best bet.
>> 
>> This is intentionally not well documented, but cases like this is
>> what it is intended for.
>> 
>> The syntax is:
>> 
>> 	C{
>> 	whatever you want
>> 	}C
>
>I will take a look at this, but since it is intentionally not well 
>documented, I am likely to have follow-up questions. :-)

I'm sure :-)

-- 
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.


From james at nyi.net  Wed Sep  5 21:30:19 2007
From: james at nyi.net (James Quacinella)
Date: Wed, 05 Sep 2007 17:30:19 -0400
Subject: VCL.List Output
Message-ID: <46DF1FEB.8030000@nyi.net>

Hello everyone,

I was curious about the output of vcl.list, specifically as to what the 
numbers meant, since I don't think its documented in the man page. I 
went through the source and I think the number outputted is the 
vcl->conf->busy structure member, which is incremented every time in 
VCL_Get. I'm not sure exactly when that happens though.

I ask only because I could not seem to unload a certain configuration 
using vcl.discard, which prompted me to stop and start the child so that 
I could. Thats no big deal as its not on a production environment yet. 
The commands I executed were as follows:

varnishadm -T x.x.x.x:8080 vcl.use boot
varnishadm -T x.x.x.x:8080 vcl.list
*       1 boot
        1 config
varnishadm -T x.x.x.x:8080 vcl.load config1 
/usr/local/etc/varnish/static.vcl
varnishadm -T x.x.x.x:8080 vcl.load config2 
/usr/local/etc/varnish/static_and_dynamic.vcl
varnishadm -T x.x.x.x:8080 vcl.list
*       1 boot
        1 config
        0 static
        0 static_and_dynamic
varnishadm -T x.x.x.x:8080 vcl.discard config

Which returns an error. Any idea why that one config was still 'busy'?

-- james



From phk at phk.freebsd.dk  Wed Sep  5 21:34:13 2007
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Wed, 05 Sep 2007 21:34:13 +0000
Subject: VCL.List Output 
In-Reply-To: Your message of "Wed, 05 Sep 2007 17:30:19 -0400."
	<46DF1FEB.8030000@nyi.net> 
Message-ID: <9816.1189028053@critter.freebsd.dk>

In message <46DF1FEB.8030000 at nyi.net>, James Quacinella writes:
>Hello everyone,
>
>I was curious about the output of vcl.list, specifically as to what the 
>numbers meant, since I don't think its documented in the man page. 

It is the reference count of the compile vcl code: how many threads
have a hold on that vcl right now.

>varnishadm -T x.x.x.x:8080 vcl.list
>*       1 boot
>        1 config
>        0 static
>        0 static_and_dynamic
>varnishadm -T x.x.x.x:8080 vcl.discard config
>
>Which returns an error. Any idea why that one config was still 'busy'?

A client request still hanging in there would be my guess.

-- 
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.


From anders at fupp.net  Thu Sep  6 07:03:28 2007
From: anders at fupp.net (Anders Nordby)
Date: Thu, 6 Sep 2007 09:03:28 +0200
Subject: VCL.List Output
In-Reply-To: <46DF1FEB.8030000@nyi.net>
References: <46DF1FEB.8030000@nyi.net>
Message-ID: <20070906070328.GA18301@fupp.net>

Hi!

On Wed, Sep 05, 2007 at 05:30:19PM -0400, James Quacinella wrote:
> I ask only because I could not seem to unload a certain configuration 
> using vcl.discard, which prompted me to stop and start the child so that 
> I could. Thats no big deal as its not on a production environment yet. 
> The commands I executed were as follows:
> 
> varnishadm -T x.x.x.x:8080 vcl.use boot
> varnishadm -T x.x.x.x:8080 vcl.list
> *       1 boot
>         1 config
> varnishadm -T x.x.x.x:8080 vcl.load config1 
> /usr/local/etc/varnish/static.vcl
> varnishadm -T x.x.x.x:8080 vcl.load config2 
> /usr/local/etc/varnish/static_and_dynamic.vcl
> varnishadm -T x.x.x.x:8080 vcl.list
> *       1 boot
>         1 config
>         0 static
>         0 static_and_dynamic
> varnishadm -T x.x.x.x:8080 vcl.discard config
> 
> Which returns an error. Any idea why that one config was still 'busy'?

I think you meant to write that you loaded static.vcl with config name
static, and static_and_dynamic.vcl with config name static_and_dynamic.
In any case, there are issues with loaded configs getting stuck. Please
see, and report to ticket 145:
http://varnish.projects.linpro.no/ticket/145

Cheers,

-- 
Anders.


From havard.futseter at met.no  Thu Sep  6 12:45:46 2007
From: havard.futseter at met.no (=?UTF-8?B?SMOldmFyZCBGdXRzw6Z0ZXI=?=)
Date: Thu, 06 Sep 2007 14:45:46 +0200
Subject: child process restarts frequently
In-Reply-To: <87ejiw63ps.fsf@des.linpro.no>
References: <468B7A9A.3040706@met.no>
	<87myybdqj8.fsf@des.linpro.no>	<468DF2D9.3090607@met.no>
	<877ipc9hg9.fsf@des.linpro.no>	<469F834C.1080806@met.no>
	<46A73793.2010206@met.no> <87ejiw63ps.fsf@des.linpro.no>
Message-ID: <46DFF67A.608@met.no>

Hi. I was wondering if there has been any change of status for this 
issue ( that is, conflict between purging and timeout)?

Dag-Erling Sm?rgrav wrote:
> H?vard Futs?ter <havard.futseter at met.no> writes:
>> Hi. There have not been any replies to my previous mail (seen below),
>> and I was wondering if this was because my description of the problem
>> was unclear? Or perhaps I did not supply enough data to find the
>> source of the problem?
> 
> We know what causes it, but it isn't trivial to fix without degrading
> performance too much.

Does this mean it is difficult to figure out a satisfactory solution at 
all? Or that you have a solution, but the implementation would take a 
lot of work?

> DES

Would it be helpful if I opened up a bug issue, and reiterated my 
problems there?

-- 
Best regards,
H?vard Futs?ter


From howachen at gmail.com  Mon Sep 10 14:30:29 2007
From: howachen at gmail.com (howard chen)
Date: Mon, 10 Sep 2007 22:30:29 +0800
Subject: Are there a user list?
Message-ID: <b66ddc900709100730i71c0ec9emcb6480ed4e1b6d8a@mail.gmail.com>

Or should general user discussion should also use this misc list?

Thanks.


From des at linpro.no  Mon Sep 10 15:44:46 2007
From: des at linpro.no (=?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?=)
Date: Mon, 10 Sep 2007 17:44:46 +0200
Subject: Are there a user list?
In-Reply-To: <b66ddc900709100730i71c0ec9emcb6480ed4e1b6d8a@mail.gmail.com>
	(howard chen's message of "Mon, 10 Sep 2007 22:30:29 +0800")
References: <b66ddc900709100730i71c0ec9emcb6480ed4e1b6d8a@mail.gmail.com>
Message-ID: <ujrr6l64j9t.fsf@false.linpro.no>

"howard chen" <howachen at gmail.com> writes:
> Or should general user discussion should also use this misc list?

varnish-misc *is* the user list.

DES
-- 
Dag-Erling Sm?rgrav
Senior Software Developer
Linpro AS - www.linpro.no


From tom at razz.com  Mon Sep 10 18:21:27 2007
From: tom at razz.com (Tom Pepper)
Date: Mon, 10 Sep 2007 11:21:27 -0700
Subject: URL rewriting / ignoring query parameters?
Message-ID: <DB38C99E-0E5F-4FD0-8505-3ED870F758CB@razz.com>

Hello all:

I'm using varnish to act as a front-end cache for yet another social  
networking widget site.  Our SWFs are presented with a tracking ID in  
the URI request which allows us to know which instance of the same  
widget in the wild is being viewed the most.  The requests look like:

GET http://content.razz.com/mixer/playerdefaulta.swf? 
u=2743&s=28&o=181618
GET http://content.razz.com/mixer/playerdefaulta.swf? 
u=2743&s=25&o=186119
GET http://content.razz.com/mixer/playerdefaulta.swf?u=178170&s=1

All 3 of these requests serve the same SWF (playerdefaulta.swf).  At  
the moment, we use squid for our reverse-proxy solution.  I'm using  
squirm to provide regexp-rewriting logic within squid since otherwise  
squid would cache 3 separate objects to serve each of these requests,  
when in reality the backend makes no differentiation between which  
object is served (playerdefaulta.swf)

I've tried poking through the varnish documentation I could find, and  
after reviewing the mailing list and the man page on vcl I'm not  
certain if it's possible to perform the following tasks in varnish w/ 
r/t these requests:

1) log the request exactly as it came from the client.  We use these  
logs to track which distinct widget in the wild was viewed.
2) instruct varnish to ignore the query parameters and only cache one  
instance of the swf for all of these requests.

I hope I've explained things adequately.  Thanks in advance for your  
consideration, and I'm really glad someone's tackling reverse-proxy  
with a project specifically designed to address it!

Best,
-t



From phk at phk.freebsd.dk  Mon Sep 10 18:35:17 2007
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Mon, 10 Sep 2007 18:35:17 +0000
Subject: URL rewriting / ignoring query parameters? 
In-Reply-To: Your message of "Mon, 10 Sep 2007 11:21:27 MST."
	<DB38C99E-0E5F-4FD0-8505-3ED870F758CB@razz.com> 
Message-ID: <78567.1189449317@critter.freebsd.dk>

In message <DB38C99E-0E5F-4FD0-8505-3ED870F758CB at razz.com>, Tom Pepper writes:

>1) log the request exactly as it came from the client.  We use these  
>logs to track which distinct widget in the wild was viewed.

Varnish will alway record the request exactly as received.

>2) instruct varnish to ignore the query parameters and only cache one  
>instance of the swf for all of these requests.

	sub vcl_recv {
		set req.url = regsub(req.url, "?.*", "");
	}

should do it.

-- 
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.


From tom at razz.com  Mon Sep 10 20:59:55 2007
From: tom at razz.com (Tom Pepper)
Date: Mon, 10 Sep 2007 13:59:55 -0700
Subject: URL rewriting / ignoring query parameters? 
In-Reply-To: <78567.1189449317@critter.freebsd.dk>
References: <78567.1189449317@critter.freebsd.dk>
Message-ID: <78234BEF-BBF3-489E-A8A7-BD177EE00FDC@razz.com>

HI Poul:

Thanks for what should have probably been a glaringly obvious  
answer.  I now have a somewhat more strange problem.

My disturbingly simple vcl_recv routine is presently:

backend default {
     set backend.host = "nyp-web-3.corp.razz.com";
     set backend.port = "80";
}

sub vcl_recv {

     set req.backend = default;
     set req.http.host = "www.razz.com";

     // change all /static/ requests into /mixer/ requests
     if (req.url ~ "/static/") {
        set req.url = regsub(req.url, "/static/", "/mixer/");
     }

     // strip query parameters from all swf requests (so they cache  
as a single object)
     if (req.url ~ "\.swf?.*") {
         set req.url = regsub(req.url, "\.swf?.*", "\.swf");
     }

     if (req.request != "GET" && req.request != "HEAD") {
         pipe;
     }

     if (req.http.Expect) {
         pipe;
     }

     if (req.http.Authenticate || req.http.Cookie) {
         pass;
     }

     lookup;

}

This would (to my eyes) appear to closely mirror the default example  
in vcf's manpage.  However, in practice, when running under this  
configuration, many distinct requests seem to retrieve the same  
document from the cache.  For example:

1) client requests http://varnish:10080/  -- varnishd returns / off  
the backend correctly.
2) client requests /css/banner.css - varnishd returns correct file / 
css/banner.css off of backend.
3) client requests /css/default.css - varnishd returns banner.css
4) client requests /images/blank.gif - varnishd returns banner.css

and so on.  commenting out the entire routine seems to get things  
functioning, but has the caveat (according to the log) that there's a  
fetch for every request, probably due to the fact that the browser  
presents a cookie used site-wide, which per the above config would  
seem to force a pass on every request.  am i doing something that  
confuses the hash algorithm?  i'm invoking currently as:

varnishd -a 192.168.10.100:10080 -T 192.168.10.100:10088 -f /etc/ 
varnish/main.vcl -s file,/cache/varnish_storage.bin,1G -g nobody -u  
nobody

i issue a url.purge .* before each test run.

Thanks again,
-Tom


On Sep 10, 2007, at 11:35 AM, Poul-Henning Kamp wrote:

> In message <DB38C99E-0E5F-4FD0-8505-3ED870F758CB at razz.com>, Tom  
> Pepper writes:
>
>> 1) log the request exactly as it came from the client.  We use these
>> logs to track which distinct widget in the wild was viewed.
>
> Varnish will alway record the request exactly as received.
>
>> 2) instruct varnish to ignore the query parameters and only cache one
>> instance of the swf for all of these requests.
>
> 	sub vcl_recv {
> 		set req.url = regsub(req.url, "?.*", "");
> 	}
>
> should do it.
>
> -- 
> 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.



From phk at phk.freebsd.dk  Mon Sep 10 22:34:09 2007
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Mon, 10 Sep 2007 22:34:09 +0000
Subject: URL rewriting / ignoring query parameters? 
In-Reply-To: Your message of "Mon, 10 Sep 2007 13:59:55 MST."
	<78234BEF-BBF3-489E-A8A7-BD177EE00FDC@razz.com> 
Message-ID: <79765.1189463649@critter.freebsd.dk>

In message <78234BEF-BBF3-489E-A8A7-BD177EE00FDC at razz.com>, Tom Pepper writes:
>HI Poul:
>
>Thanks for what should have probably been a glaringly obvious  
>answer.  I now have a somewhat more strange problem.

>1) client requests http://varnish:10080/  -- varnishd returns / off  
>the backend correctly.
>2) client requests /css/banner.css - varnishd returns correct file / 
>css/banner.css off of backend.
>3) client requests /css/default.css - varnishd returns banner.css
>4) client requests /images/blank.gif - varnishd returns banner.css

Sounds like one of the rewrites are going haywire.

My best suggestion is to study the varnislog output and try to
find out what exactly is going on.

You may want to enable the "vcl.trace" parameter, that will give
you log records of each file.line.pos of VCL code executed.

-- 
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.


From optilude at gmx.net  Sun Sep  9 17:18:19 2007
From: optilude at gmx.net (Martin Aspeli)
Date: Sun, 09 Sep 2007 18:18:19 +0100
Subject: Varnish appears to hang/requests time out
In-Reply-To: <faqf1s$ji5$1@sea.gmane.org>
References: <faqf1s$ji5$1@sea.gmane.org>
Message-ID: <fc19t8$1mv$1@sea.gmane.org>

Here is a much shorter log entry that exhibits the same behaviour. This 
is with trunk and 1.1.1 final (the log entry is 1.1.1 final)

$
./bin/varnishlog     0 CLI            Rd ping    0 CLI            Wr 0 
200 PONG 1189354743
     0 WorkThread     0xb0303c90 start
    12 SessionOpen  c 127.0.0.1 64496
    12 ReqStart     c 127.0.0.1 64496 1765608679
    12 RxRequest    c GET
    12 RxURL        c /optilux
    12 RxProtocol   c HTTP/1.1
    12 RxHeader     c Accept: */*
    12 RxHeader     c Accept-Language: en
    12 RxHeader     c Accept-Encoding: gzip, deflate
    12 RxHeader     c Cookie: __ac="NjE2NDZkNjk2ZTo2MTY0NmQ2OTZl"; 
wstyle=Normal%20Text
    12 RxHeader     c User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac 
OS X; en) AppleWebKit/419.3 (KHTML, like Gecko) Safari/419.3
    12 RxHeader     c Connection: keep-alive
    12 RxHeader     c Host: localhost:8081
    12 VCL_call     c recv
    12 VCL_return   c pass
    12 VCL_call     c pass
    12 VCL_return   c pass
    15 BackendOpen  b default 127.0.0.1 64497 127.0.0.1 8080
    15 BackendXID   b 1765608679
    12 Backend      c 15 default
    15 TxRequest    b GET
    15 TxURL        b /optilux
    15 TxProtocol   b HTTP/1.1
    15 TxHeader     b Accept: */*
    15 TxHeader     b Accept-Language: en
    15 TxHeader     b Accept-Encoding: gzip, deflate
    15 TxHeader     b Cookie: __ac="NjE2NDZkNjk2ZTo2MTY0NmQ2OTZl"; 
wstyle=Normal%20Text
    15 TxHeader     b User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac 
OS X; en) AppleWebKit/419.3 (KHTML, like Gecko) Safari/419.3
    15 TxHeader     b Host: localhost:8081
    15 TxHeader     b X-Varnish: 1765608679
    15 TxHeader     b X-Forwarded-for: 127.0.0.1
    15 RxProtocol   b HTTP/1.1
    15 RxStatus     b 200
    15 RxResponse   b OK
    15 RxHeader     b Server: Zope/(Zope 2.10.4-final, python 2.4.3, 
darwin) ZServer/1.1 Plone/3.0
    15 RxHeader     b Date: Sun, 09 Sep 2007 16:19:04 GMT
    15 RxHeader     b X-Pagecache: NO-ETAG
    15 RxHeader     b Content-Length: 6690
    15 RxHeader     b Content-Language: en-gb
    15 RxHeader     b Content-Encoding: gzip
    15 RxHeader     b Expires: Thu, 11 Sep 1997 16:19:04 GMT
    15 RxHeader     b Vary: Accept-Encoding, Accept-Language,
    15 RxHeader     b    Accept-Encoding
    15 RxHeader     b ETag: |admin|Optilux Theme|en|1|310||||330376
    15 RxHeader     b X-Caching-Rule-Id: plone-content-types
    15 RxHeader     b Cache-Control: max-age=0, s-maxage=0, private, 
must-revalidate
    15 RxHeader     b Content-Type: text/html;charset=utf-8
    15 RxHeader     b X-Header-Set-Id: cache-with-etag
    12 ObjProtocol  c HTTP/1.1
    12 ObjStatus    c 200
    12 ObjResponse  c OK
    12 ObjHeader    c Server: Zope/(Zope 2.10.4-final, python 2.4.3, 
darwin) ZServer/1.1 Plone/3.0
    12 ObjHeader    c Date: Sun, 09 Sep 2007 16:19:04 GMT
    12 ObjHeader    c X-Pagecache: NO-ETAG
    12 ObjHeader    c Content-Language: en-gb
    12 ObjHeader    c Content-Encoding: gzip
    12 ObjHeader    c Expires: Thu, 11 Sep 1997 16:19:04 GMT
    12 ObjHeader    c Vary: Accept-Encoding, Accept-Language,
    12 ObjHeader    c    Accept-Encoding
    12 ObjHeader    c ETag: |admin|Optilux Theme|en|1|310||||330376
    12 ObjHeader    c X-Caching-Rule-Id: plone-content-types
    12 ObjHeader    c Cache-Control: max-age=0, s-maxage=0, private, 
must-revalidate
    12 ObjHeader    c Content-Type: text/html;charset=utf-8
    12 ObjHeader    c X-Header-Set-Id: cache-with-etag
    15 BackendReuse b default
    12 TTL          c 1765608679 RFC 0 1189354744 1189354744 873994744 0 0
    12 VCL_call     c fetch
    12 VCL_return   c insert
    12 Length       c 6690
    12 VCL_call     c deliver
    12 VCL_return   c deliver
    12 TxProtocol   c HTTP/1.1
    12 TxStatus     c 200
    12 TxResponse   c OK
    12 TxHeader     c Server: Zope/(Zope 2.10.4-final, python 2.4.3, 
darwin) ZServer/1.1 Plone/3.0
    12 TxHeader     c Date: Sun, 09 Sep 2007 16:19:04 GMT
    12 TxHeader     c X-Pagecache: NO-ETAG
    12 TxHeader     c Content-Language: en-gb
    12 TxHeader     c Content-Encoding: gzip
    12 TxHeader     c Expires: Thu, 11 Sep 1997 16:19:04 GMT
    12 TxHeader     c Vary: Accept-Encoding, Accept-Language,
    12 TxHeader     c    Accept-Encoding
    12 TxHeader     c ETag: |admin|Optilux Theme|en|1|310||||330376
    12 TxHeader     c X-Caching-Rule-Id: plone-content-types
    12 TxHeader     c Cache-Control: max-age=0, s-maxage=0, private, 
must-revalidate
    12 TxHeader     c Content-Type: text/html;charset=utf-8
    12 TxHeader     c X-Header-Set-Id: cache-with-etag
    12 TxHeader     c Content-Length: 6690
    12 TxHeader     c X-Varnish: 1765608679
    12 TxHeader     c Age: 0
    12 TxHeader     c Via: 1.1 varnish
    12 TxHeader     c Connection: keep-alive
    12 ReqEnd       c 1765608679 1189354744.079793930 
1189354744.435858965 0.000501871 0.355978012 0.000087023
     0 StatAddr       127.0.0.1 0 0 1 1 0 0 1 623 6690
     0 WorkThread     0xb0384c90 start
    16 SessionOpen  c 127.0.0.1 64501
     0 WorkThread     0xb0405c90 start
    17 SessionOpen  c 127.0.0.1 64502
     0 WorkThread     0xb0486c90 start
    18 SessionOpen  c 127.0.0.1 64503
    12 ReqStart     c 127.0.0.1 64496 1765608680
    12 RxRequest    c GET
    12 RxURL        c 
/optilux/portal_kss/Optilux%20Theme/at-cachekey9321.kss
    12 RxProtocol   c HTTP/1.1
    12 RxHeader     c Accept: */*
    12 RxHeader     c Accept-Language: en
    12 RxHeader     c Accept-Encoding: gzip, deflate
    12 RxHeader     c Cookie: __ac="NjE2NDZkNjk2ZTo2MTY0NmQ2OTZl"; 
wstyle=Normal%20Text
    12 RxHeader     c Referer: http://localhost:8081/optilux
    12 RxHeader     c User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac 
OS X; en) AppleWebKit/419.3 (KHTML, like Gecko) Safari/419.3
    12 RxHeader     c If-Modified-Since: Sun, 09 Sep 2007 16:17:57 GMT
    12 RxHeader     c Connection: keep-alive
    12 RxHeader     c Host: localhost:8081
    12 VCL_call     c recv
    12 VCL_return   c pass
    12 VCL_call     c pass
    12 VCL_return   c pass
    15 BackendXID   b 1765608680
    12 Backend      c 15 default
    15 TxRequest    b GET
    15 TxURL        b 
/optilux/portal_kss/Optilux%20Theme/at-cachekey9321.kss
    15 TxProtocol   b HTTP/1.1
    15 TxHeader     b Accept: */*
    15 TxHeader     b Accept-Language: en
    15 TxHeader     b Accept-Encoding: gzip, deflate
    15 TxHeader     b Cookie: __ac="NjE2NDZkNjk2ZTo2MTY0NmQ2OTZl"; 
wstyle=Normal%20Text
    15 TxHeader     b Referer: http://localhost:8081/optilux
    15 TxHeader     b User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac 
OS X; en) AppleWebKit/419.3 (KHTML, like Gecko) Safari/419.3
    15 TxHeader     b If-Modified-Since: Sun, 09 Sep 2007 16:17:57 GMT
    15 TxHeader     b Host: localhost:8081
    15 TxHeader     b X-Varnish: 1765608680
    15 TxHeader     b X-Forwarded-for: 127.0.0.1
    15 RxProtocol   b HTTP/1.1
    15 RxStatus     b 200
    15 RxResponse   b OK
    15 RxHeader     b Server: Zope/(Zope 2.10.4-final, python 2.4.3, 
darwin) ZServer/1.1 Plone/3.0
    15 RxHeader     b Date: Sun, 09 Sep 2007 16:19:04 GMT
    15 RxHeader     b Content-Length: 9912
    15 RxHeader     b X-Cache-Headers-Set-By: CachingPolicyManager: 
/optilux/caching_policy_manager
    15 RxHeader     b Accept-Ranges: bytes
    15 RxHeader     b Expires: Thu, 11 Sep 1997 16:19:04 GMT
    15 RxHeader     b Last-Modified: Sun, 09 Sep 2007 16:19:04 GMT
    15 RxHeader     b X-Caching-Rule-Id: downloads
    15 RxHeader     b Cache-Control: max-age=0, s-maxage=86400, 
must-revalidate, proxy-revalidate
    15 RxHeader     b Content-Type: text/css;charset=utf-8
    15 RxHeader     b X-Header-Set-Id: cache-in-proxy-24-hours
    12 ObjProtocol  c HTTP/1.1
    12 ObjStatus    c 200
    12 ObjResponse  c OK
    12 ObjHeader    c Server: Zope/(Zope 2.10.4-final, python 2.4.3, 
darwin) ZServer/1.1 Plone/3.0
    12 ObjHeader    c Date: Sun, 09 Sep 2007 16:19:04 GMT
    12 ObjHeader    c X-Cache-Headers-Set-By: CachingPolicyManager: 
/optilux/caching_policy_manager
    12 ObjHeader    c Expires: Thu, 11 Sep 1997 16:19:04 GMT
    12 ObjHeader    c Last-Modified: Sun, 09 Sep 2007 16:19:04 GMT
    12 ObjHeader    c X-Caching-Rule-Id: downloads
    12 ObjHeader    c Cache-Control: max-age=0, s-maxage=86400, 
must-revalidate, proxy-revalidate
    12 ObjHeader    c Content-Type: text/css;charset=utf-8
    12 ObjHeader    c X-Header-Set-Id: cache-in-proxy-24-hours
    15 BackendReuse b default
    12 TTL          c 1765608680 RFC 86400 1189354744 1189354744 
873994744 86400 0
    12 VCL_call     c fetch
    12 VCL_return   c insert
    12 Length       c 9912
    12 VCL_call     c deliver
    12 VCL_return   c deliver
    12 TxProtocol   c HTTP/1.1
    12 TxStatus     c 200
    12 TxResponse   c OK
    12 TxHeader     c Server: Zope/(Zope 2.10.4-final, python 2.4.3, 
darwin) ZServer/1.1 Plone/3.0
    12 TxHeader     c Date: Sun, 09 Sep 2007 16:19:04 GMT
    12 TxHeader     c X-Cache-Headers-Set-By: CachingPolicyManager: 
/optilux/caching_policy_manager
    12 TxHeader     c Expires: Thu, 11 Sep 1997 16:19:04 GMT
    12 TxHeader     c Last-Modified: Sun, 09 Sep 2007 16:19:04 GMT
    12 TxHeader     c X-Caching-Rule-Id: downloads
    12 TxHeader     c Cache-Control: max-age=0, s-maxage=86400, 
must-revalidate, proxy-revalidate
    12 TxHeader     c Content-Type: text/css;charset=utf-8
    12 TxHeader     c X-Header-Set-Id: cache-in-proxy-24-hours
    12 TxHeader     c Content-Length: 9912
    12 TxHeader     c X-Varnish: 1765608680
    12 TxHeader     c Age: 0
    12 TxHeader     c Via: 1.1 varnish
    12 TxHeader     c Connection: keep-alive
    12 ReqEnd       c 1765608680 1189354744.538324118 
1189354744.564362049 0.102465153 0.025976896 0.000061035
     0 StatAddr       127.0.0.1 0 0 1 2 0 0 2 1204 16602
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189354746
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189354749
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189354752
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189354755

I'm not really familiar with this log format, but it seems to me a 
request is being made with keep-alive that never completes? During the 
last pings, Safari is hanging (and appears to have crashed). It comes 
back to life if I kill varnishd. Bad browser behaviour maybe, but still 
nothing like this happens when I access the backend directly.

FWIW, this problems seems most pronounced in Safari, but I have seen it 
with Firefox and IE as well.

I've seen http://varnish.projects.linpro.no/ticket/55 which may be 
related, but there's no mention of where it's fixed (trunk? 1.1 
branch?). In any case, I saw the problem with trunk as well.

Martin



From des at linpro.no  Tue Sep 11 07:59:28 2007
From: des at linpro.no (=?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?=)
Date: Tue, 11 Sep 2007 09:59:28 +0200
Subject: URL rewriting / ignoring query parameters?
In-Reply-To: <78567.1189449317@critter.freebsd.dk> (Poul-Henning Kamp's
	message of "Mon, 10 Sep 2007 18:35:17 +0000")
References: <78567.1189449317@critter.freebsd.dk>
Message-ID: <ujrd4wp4opr.fsf@false.linpro.no>

"Poul-Henning Kamp" <phk at phk.freebsd.dk> writes:
> sub vcl_recv {
> 	set req.url = regsub(req.url, "?.*", "");
> }

You need to quote the ?...

DES
-- 
Dag-Erling Sm?rgrav
Senior Software Developer
Linpro AS - www.linpro.no


From des at linpro.no  Tue Sep 11 08:21:51 2007
From: des at linpro.no (=?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?=)
Date: Tue, 11 Sep 2007 10:21:51 +0200
Subject: child process restarts frequently
In-Reply-To: <46DFF67A.608@met.no> (=?iso-8859-1?Q?H=E5vard_Futs=E6ter's?=
	message of "Thu, 06 Sep 2007 14:45:46 +0200")
References: <468B7A9A.3040706@met.no> <87myybdqj8.fsf@des.linpro.no>
	<468DF2D9.3090607@met.no> <877ipc9hg9.fsf@des.linpro.no>
	<469F834C.1080806@met.no> <46A73793.2010206@met.no>
	<87ejiw63ps.fsf@des.linpro.no> <46DFF67A.608@met.no>
Message-ID: <ujr8x7d4nog.fsf@false.linpro.no>

H?vard Futs?ter <havard.futseter at met.no> writes:
> Dag-Erling Sm?rgrav <des at linpro.no> writes:
> > We know what causes it, but it isn't trivial to fix without degrading
> > performance too much.
> Does this mean it is difficult to figure out a satisfactory solution
> at all?  Or that you have a solution, but the implementation would
> take a lot of work?

The former.  The quick and easy fix is to add a mutex, but that will
kill performance.  We need to find a better solution.

DES
-- 
Dag-Erling Sm?rgrav
Senior Software Developer
Linpro AS - www.linpro.no


From des at linpro.no  Tue Sep 11 08:28:42 2007
From: des at linpro.no (=?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?=)
Date: Tue, 11 Sep 2007 10:28:42 +0200
Subject: Varnishd startup error in mgt_vcc.c
In-Reply-To: <dc32e3beb9abad4b621be50f49df4b42@localhost> (Jim Baack's message
	of "Thu, 30 Aug 2007 10:53:35 -0700")
References: <dc32e3beb9abad4b621be50f49df4b42@localhost>
Message-ID: <ujr4pi14nd1.fsf@false.linpro.no>

Jim Baack <jim at thebaacks.com> writes:
> I am new to Varnish and trying to get it running on FC5.
>
> I get this error on 1.1.1 and the current 1.1 branch from SVN.
>
> Internal error: cc(1) exit status 0xffffffff
>
> My startup command line is
>
> /usr/local/sbin/varnishd -a 127.0.0.1:3000 -f /etc/varnish.conf -P
> /var/run/varnish.pid -u apache -g apache -sfile,/tmp/varnish.cache,1G
>
> I did some very basic debugging and the bin.XXX file appears to be
> successfully generated from the vcl.XXX file. Any idea what the problem
> might be or what I should try?

It's hard to tell.  The error message itself is wrong in that the
return value from pclose(3) is *not* the exit status of the child
process.  In fact, it is possible for pclose(3) to return -1 (which is
what you see here) even if the VCL code compiled just fine.

What happens if you run 'varnishd -C -f /etc/varnish.conf'?

If that fails as well, can you strace it (making sure to trace child
processes as well)?

DES
-- 
Dag-Erling Sm?rgrav
Senior Software Developer
Linpro AS - www.linpro.no


From phk at phk.freebsd.dk  Tue Sep 11 09:34:58 2007
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Tue, 11 Sep 2007 09:34:58 +0000
Subject: slightly offline...
Message-ID: <82656.1189503298@critter.freebsd.dk>


Hi guys,

This is just a little note to say that I have not forgotten about
Varnish and the problems you report with it.

I have been busy working on esi:include, hoping to have a proof-of-
concept implementation before EuroBSDcon2007, but that didn't quite
work out.

The conference is going to take practically all my time until next
wednesday, but I'll be happy to talk varnish with anybody who
attends, time permitting of course.

-- 
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.


From des at linpro.no  Tue Sep 11 09:49:00 2007
From: des at linpro.no (=?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?=)
Date: Tue, 11 Sep 2007 11:49:00 +0200
Subject: slightly offline...
In-Reply-To: <82656.1189503298@critter.freebsd.dk> (Poul-Henning Kamp's
	message of "Tue, 11 Sep 2007 09:34:58 +0000")
References: <82656.1189503298@critter.freebsd.dk>
Message-ID: <ujrzlzt352r.fsf@false.linpro.no>

"Poul-Henning Kamp" <phk at phk.freebsd.dk> writes:
> The conference is going to take practically all my time until next
> wednesday, but I'll be happy to talk varnish with anybody who
> attends, time permitting of course.

I will also be there, and hopefully not quite as busy as Poul-Henning.

DES
-- 
Dag-Erling Sm?rgrav
Senior Software Developer
Linpro AS - www.linpro.no


From jim at thebaacks.com  Tue Sep 11 15:09:25 2007
From: jim at thebaacks.com (Jim Baack)
Date: Tue, 11 Sep 2007 08:09:25 -0700
Subject: Varnishd startup error in mgt_vcc.c
In-Reply-To: <ujr4pi14nd1.fsf@false.linpro.no>
References: <ujr4pi14nd1.fsf@false.linpro.no>
Message-ID: <941f0cccef3c0be099ff7fc0575fd0e8@localhost>

On Tue, 11 Sep 2007 10:28:42 +0200, "Dag-Erling Sm?rgrav" <des at linpro.no>
wrote:
> Jim Baack <jim at thebaacks.com> writes:
>> I am new to Varnish and trying to get it running on FC5.
>>
>> I get this error on 1.1.1 and the current 1.1 branch from SVN.
>>
>> Internal error: cc(1) exit status 0xffffffff
>>
>> My startup command line is
>>
>> /usr/local/sbin/varnishd -a 127.0.0.1:3000 -f /etc/varnish.conf -P
>> /var/run/varnish.pid -u apache -g apache -sfile,/tmp/varnish.cache,1G
>>
>> I did some very basic debugging and the bin.XXX file appears to be
>> successfully generated from the vcl.XXX file. Any idea what the problem
>> might be or what I should try?
> 
> It's hard to tell.  The error message itself is wrong in that the
> return value from pclose(3) is *not* the exit status of the child
> process.  In fact, it is possible for pclose(3) to return -1 (which is
> what you see here) even if the VCL code compiled just fine.
> 
> What happens if you run 'varnishd -C -f /etc/varnish.conf'?
> 
> If that fails as well, can you strace it (making sure to trace child
> processes as well)?
> 
> DES
>

This resolved itself. It was somehow caused by the way I was accessing the
shell I ran 'varnishd...' from. I'm all set. Thanks for the help and sorry
for the noise.

Jim



From tom at razz.com  Tue Sep 11 16:19:59 2007
From: tom at razz.com (Tom Pepper)
Date: Tue, 11 Sep 2007 09:19:59 -0700
Subject: URL rewriting / ignoring query parameters? 
In-Reply-To: <79765.1189463649@critter.freebsd.dk>
References: <79765.1189463649@critter.freebsd.dk>
Message-ID: <51DCE61D-8289-4244-9ED7-8C58FB99A310@razz.com>

Hi Poul:

Thanks for the suggestions.  Removing this routine seems to have  
fixed my issues:

          sub vcl_hash {
              hash;
          }

It appears, contrary to the vcl(7) manpage, to be different than the  
functional default.  Is there an updated routine which would better  
match?  From my experience, cutting and pasting the example out of  
the man page into the first working example seems to have issues (all  
of my hits came back in the logs with the same hash id when I had  
that routine as part of my vcl.)

Best,
-t


On Sep 10, 2007, at 3:34 PM, Poul-Henning Kamp wrote:

> In message <78234BEF-BBF3-489E-A8A7-BD177EE00FDC at razz.com>, Tom  
> Pepper writes:
>> HI Poul:
>>
>> Thanks for what should have probably been a glaringly obvious
>> answer.  I now have a somewhat more strange problem.
>
>> 1) client requests http://varnish:10080/  -- varnishd returns / off
>> the backend correctly.
>> 2) client requests /css/banner.css - varnishd returns correct file /
>> css/banner.css off of backend.
>> 3) client requests /css/default.css - varnishd returns banner.css
>> 4) client requests /images/blank.gif - varnishd returns banner.css
>
> Sounds like one of the rewrites are going haywire.
>
> My best suggestion is to study the varnislog output and try to
> find out what exactly is going on.
>
> You may want to enable the "vcl.trace" parameter, that will give
> you log records of each file.line.pos of VCL code executed.
>
> -- 
> 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.



From phk at phk.freebsd.dk  Tue Sep 11 16:21:14 2007
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Tue, 11 Sep 2007 16:21:14 +0000
Subject: URL rewriting / ignoring query parameters? 
In-Reply-To: Your message of "Tue, 11 Sep 2007 09:19:59 MST."
	<51DCE61D-8289-4244-9ED7-8C58FB99A310@razz.com> 
Message-ID: <85384.1189527674@critter.freebsd.dk>

In message <51DCE61D-8289-4244-9ED7-8C58FB99A310 at razz.com>, Tom Pepper writes:
>Hi Poul:
>
>Thanks for the suggestions.  Removing this routine seems to have  
>fixed my issues:
>
>          sub vcl_hash {
>              hash;
>          }
>

Ahh yes, that wouldn't work, I overlooked that.

I think that may be the vcl(7) being a bit behind.

-- 
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.


From des at linpro.no  Tue Sep 11 16:31:45 2007
From: des at linpro.no (=?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?=)
Date: Tue, 11 Sep 2007 18:31:45 +0200
Subject: URL rewriting / ignoring query parameters?
In-Reply-To: <51DCE61D-8289-4244-9ED7-8C58FB99A310@razz.com> (Tom Pepper's
	message of "Tue, 11 Sep 2007 09:19:59 -0700")
References: <79765.1189463649@critter.freebsd.dk>
	<51DCE61D-8289-4244-9ED7-8C58FB99A310@razz.com>
Message-ID: <ujrsl5l17v2.fsf@false.linpro.no>

Tom Pepper <tom at razz.com> writes:
> From my experience, cutting and pasting the example out of the man
> page into the first working example seems to have issues (all of my
> hits came back in the logs with the same hash id when I had that
> routine as part of my vcl.)

Why did you even cut and paste that into your config?  It is not an
example, but a listing of the built-in configuration.  Copying it into
your config is the best way to ensure that you will be royally screwed
every time you upgrade to a new version.

DES
-- 
Dag-Erling Sm?rgrav
Senior Software Developer
Linpro AS - www.linpro.no


From tom at razz.com  Tue Sep 11 16:43:02 2007
From: tom at razz.com (Tom Pepper)
Date: Tue, 11 Sep 2007 09:43:02 -0700
Subject: URL rewriting / ignoring query parameters?
In-Reply-To: <ujrsl5l17v2.fsf@false.linpro.no>
References: <79765.1189463649@critter.freebsd.dk>
	<51DCE61D-8289-4244-9ED7-8C58FB99A310@razz.com>
	<ujrsl5l17v2.fsf@false.linpro.no>
Message-ID: <C9D834E5-8379-4ABE-BD58-0DE4423AB91F@razz.com>

um, because i am teh crazy?

kidding aside, i was attempting to establish a baseline config from  
which i could get a grasp of how varnish works through each  
particular routine.  i'll be the first to agree that it's not a  
brilliant idea for production, but was rather hoping to have a solid  
grasp of what each routine within VCL was doing, exactly.  call it  
occupational curiosity, I suppose, and a small plea from your end  
users to give the documentation a cursory glance when upgrades take  
place.

Thanks!
-t

On Sep 11, 2007, at 9:31 AM, Dag-Erling Sm?rgrav wrote:

> Tom Pepper <tom at razz.com> writes:
>> From my experience, cutting and pasting the example out of the man
>> page into the first working example seems to have issues (all of my
>> hits came back in the logs with the same hash id when I had that
>> routine as part of my vcl.)
>
> Why did you even cut and paste that into your config?  It is not an
> example, but a listing of the built-in configuration.  Copying it into
> your config is the best way to ensure that you will be royally screwed
> every time you upgrade to a new version.
>
> DES
> -- 
> Dag-Erling Sm?rgrav
> Senior Software Developer
> Linpro AS - www.linpro.no



From duja at torlen.net  Tue Sep 11 18:34:35 2007
From: duja at torlen.net (Erik Torlen)
Date: Tue, 11 Sep 2007 20:34:35 +0200
Subject: Problems with the cache
Message-ID: <46E6DFBB.7040201@torlen.net>

Im trying to get varnish running smoothly on my server with apache on 
it. Unforunately Im having some problems to get the caching thing
working. I have set varnishd to use default.vcl on a Debian 4.0 etch OS. 
it starts up without any problem but doesn't cache anything.

Also the varnishlog doesn't seem to log anything. I'm having it running 
as a daemon, it's writing the log to /var/log/varnish/varnish.log but 
that file is empty. Varnishstat doesn't update itself when using vcl, 
only when using "-b localhost:8080" as a parameter to varnishd.

Im using all default config files, except that I have edited the backend 
in default.vcl and in /etc/default/varnish .

However, if I use the "-b" parameter woith varnishd, I could get 
varnishd to work but nothing is cached. Alot of objects are fetched but 
nothing is parsed out to the client. It just fetches it from the backend 
server over and over again.

As you see, i have alot of problems. It became a big mess after some 
tweaking and now am stuck with alooot of problems :(

/ Erik



From perbu at linpro.no  Tue Sep 11 19:01:47 2007
From: perbu at linpro.no (Per Andreas Buer)
Date: Tue, 11 Sep 2007 21:01:47 +0200
Subject: Problems with the cache
In-Reply-To: <46E6DFBB.7040201@torlen.net>
References: <46E6DFBB.7040201@torlen.net>
Message-ID: <46E6E61B.6030902@linpro.no>

Erik Torlen skrev:
> Im trying to get varnish running smoothly on my server with apache on 
> it. Unforunately Im having some problems to get the caching thing
> working. I have set varnishd to use default.vcl on a Debian 4.0 etch OS. 
> it starts up without any problem but doesn't cache anything.

The default configuration will not cache if your are setting cookies or
if your clients are sending cookies to Varnish. I think this is covered
in the FAQ.

> Also the varnishlog doesn't seem to log anything.

Does it log anything when you're just running it on the command line -
without any options?


Per.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20070911/ec7551ad/attachment.bin>

From perbu at linpro.no  Wed Sep 12 05:51:06 2007
From: perbu at linpro.no (Per Andreas Buer)
Date: Wed, 12 Sep 2007 07:51:06 +0200
Subject: Problems with the cache
In-Reply-To: <46E6FC2F.6030404@torlen.net>
References: <46E6DFBB.7040201@torlen.net> <46E6E61B.6030902@linpro.no>
	<46E6FC2F.6030404@torlen.net>
Message-ID: <46E77E4A.6040805@linpro.no>

(Please stay on the mailing list.)

Erik Torlen skrev:
> 
>> The default configuration will not cache if your are setting cookies or
>> if your clients are sending cookies to Varnish. I think this is covered
>> in the FAQ.
>
> I just made a simple index.html with two example jpeg pics. No extra
> header settings or cookies. I also tried to add some example code from
> the manual page to the default.vcl where they showed how to cache
> cookies. Neither did that work.
>
>> Does it log anything when you're just running it on the command line -
>> without any options?
>>   
> Well, if I use the default.vcl it doesn't show me anything, but if I use
> the "-b" parameter it displays some "ping" and "pong" messages and alot
> of other stuff if I open the site in the browser. But, as I said, this
> is with the "-b" parameter. With the default.vcl, it is totally
> quiet :(


Are you sure you've set up varnish as proxy?
 * What port is varnish binding to?
 * what port is your backend running on?
 * How are you accessing the site?



Per.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20070912/c4b4e6cc/attachment.bin>

From phk at phk.freebsd.dk  Wed Sep 12 18:14:34 2007
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Wed, 12 Sep 2007 18:14:34 +0000
Subject: Caching pages with cookies - feature request 
In-Reply-To: Your message of "Wed, 12 Sep 2007 20:11:05 +0200."
	<46E82BB9.1010808@klaus.dk> 
Message-ID: <24492.1189620874@critter.freebsd.dk>

In message <46E82BB9.1010808 at klaus.dk>, Klaus writes:
>Ah great!
>
>But what if I only want to cache on some of the cookies. Like a 
>sessionID  and ignore the rest?

That's still in the pipeline.  The intended syntax is:

	set req.hash += req.http.cookie[SessionID];

But it's not implemented yet.

You can hack your way out of it for now with the regsub() function.


-- 
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.


From red5 at klaus.dk  Wed Sep 12 18:11:05 2007
From: red5 at klaus.dk (Klaus)
Date: Wed, 12 Sep 2007 20:11:05 +0200
Subject: Caching pages with cookies - feature request
In-Reply-To: <77980.1188810257@critter.freebsd.dk>
References: <77980.1188810257@critter.freebsd.dk>
Message-ID: <46E82BB9.1010808@klaus.dk>

Ah great!

But what if I only want to cache on some of the cookies. Like a 
sessionID  and ignore the rest?

/Klaus

Poul-Henning Kamp wrote:
> In message <46DABC11.9090608 at klaus.dk>, Klaus writes:
>   
>> Hello List,
>>
>>
>> Could it be possible to cache pages per cookie values?
>>
>> Example.
>>
>> http://www.host.dk/page1?var=value1   (cookie: selection=1,2,3,4)
>>     
>
> Yes, just add the cookie header to the hash string in vcl_hash():
>
> 	sub vcl_hash {
> 		set req.hash += req.http.cookie;
> 	}
>
>
> Poul-Henning
>
>   



From tom at razz.com  Thu Sep 13 01:42:26 2007
From: tom at razz.com (Tom Pepper)
Date: Wed, 12 Sep 2007 18:42:26 -0700
Subject: HEAD redirects for HTTP/1.0 backend locally?
Message-ID: <C18A435A-05D7-410C-9AD7-1EB37EE62EE2@razz.com>

Sirs:

I'm seeing some interesting behavior w/r/t HEAD requests that I'd  
appreciate some insights on.  Some background:

We use a foundry serveriron GT for load balancing.  Its IP is  
192.168.10.254.
The varnish test server is 192.168.10.101 under fedora 7, compiled  
from source.
The current back-end server is nyp-web-1.corp.razz.com, at  
192.168.10.80.

The foundry makes health checks to varnish every 5 seconds via HEAD  
requests using HTTP/1.0.

For some reason (unless I'm interpreting this wrong), varnish is  
deciding that the backend of these HEAD requests should be itself,  
and the timestamp on the lookup is off by several hours:

(from varnishncsa)
192.168.10.254 - - [12/Sep/2007:18:32:28 -0700] "HEAD /static/mixer/ 
playerdefault.swf HTTP/1.0" 200 61986 "-" "-"
192.168.10.254 - - [12/Sep/2007:18:32:33 -0700] "HEAD /static/mixer/ 
playerdefault.swf HTTP/1.0" 200 61986 "-" "-"
192.168.10.254 - - [12/Sep/2007:18:32:38 -0700] "HEAD /static/mixer/ 
playerdefault.swf HTTP/1.0" 200 61986 "-" "-"
192.168.10.101 - - [13/Sep/2007:01:32:43 -0700] "GET http://nyp- 
web-1.corp.razz.com/mixer/playerdefault.swf HTTP/1.1" 200 61986 "-" "-"
192.168.10.254 - - [12/Sep/2007:18:32:43 -0700] "HEAD /static/mixer/ 
playerdefault.swf HTTP/1.0" 200 61986 "-" "-"
192.168.10.254 - - [12/Sep/2007:18:32:48 -0700] "HEAD /static/mixer/ 
playerdefault.swf HTTP/1.0" 200 61986 "-" "-"
192.168.10.254 - - [12/Sep/2007:18:32:53 -0700] "HEAD /static/mixer/ 
playerdefault.swf HTTP/1.0" 200 61986 "-" "-"

The GET request is varnish connecting to itself to check the asset  
when the ttl expires.  This request should instead be hitting the  
backend server.

Current config:

backend default {
     set backend.host = "nyp-web-1.corp.razz.com";
     set backend.port = "80";
}

sub vcl_recv {

     set req.backend = default;
     set req.http.host = "nyp-web-1.corp.razz.com";

     // block redirect loops
     if (req.url ~ "^/static/static/") {
        error 404 "Not found.";
     }

     // change all /static/ requests into / backend requests
     if (req.url ~ "^/static/") {
        set req.url = regsub(req.url, "^/static/", "/");
     }

     // strip query parameters from all swf requests (so they cache  
as a single object)
     if (req.url ~ "\.swf\?.*") {
         set req.url = regsub(req.url, "\.swf\?.*", ".swf");
     }

     // force lookup on any of the static object types
     if (req.url ~ "\.(swf|gif|jpg|png|js|bmp|pdf|css|mp3|xml|flv) 
(\?.*)?$") {
         lookup;
     }

     // deny any other kind of request
     error 404 "Not found.";

}

Here's the output of varnishlog for the HEAD requests surrounding the  
GET:

  0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189647149
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189647152
    15 SessionOpen  c 192.168.10.254 1720
    15 ReqStart     c 192.168.10.254 1720 1052036059
    15 RxRequest    c HEAD
    15 RxURL        c /static/mixer/playerdefault.swf
    15 RxProtocol   c HTTP/1.0
    15 VCL_call     c recv
    15 VCL_trace    c 1 7.14
    15 VCL_trace    c 2 13.9
    15 VCL_trace    c 4 18.5
    15 VCL_trace    c 5 18.9
    15 VCL_trace    c 6 18.32
    15 VCL_trace    c 7 23.5
    15 VCL_trace    c 8 23.9
    15 VCL_trace    c 10 28.5
    15 VCL_trace    c 11 28.9
    15 VCL_trace    c 12 28.77
    15 VCL_return   c lookup
    15 VCL_call     c hash
    15 VCL_trace    c 41 22.14
    15 VCL_return   c hash
    15 Hit          c 1052036036
    15 VCL_call     c hit
    15 VCL_trace    c 42 28.13
    15 VCL_trace    c 43 29.9
    15 VCL_trace    c 45 32.5
    15 VCL_return   c deliver
    15 Length       c 61986
    15 VCL_call     c deliver
    15 VCL_trace    c 57 51.17
    15 VCL_return   c deliver
    15 TxProtocol   c HTTP/1.1
    15 TxStatus     c 200
    15 TxResponse   c OK
    15 TxHeader     c Date: Thu, 13 Sep 2007 01:30:38 GMT
    15 TxHeader     c Server: Apache/2.2.4 (Fedora)
    15 TxHeader     c Last-Modified: Thu, 26 Apr 2007 17:42:49 GMT
    15 TxHeader     c ETag: "3368c1-f222-42f078c1f9840"
    15 TxHeader     c Content-Type: application/x-shockwave-flash
    15 TxHeader     c X-Pad: avoid browser bug
    15 TxHeader     c Content-Length: 61986
    15 TxHeader     c X-Varnish: 1052036059 1052036036
    15 TxHeader     c Age: 115
    15 TxHeader     c Via: 1.1 varnish
    15 TxHeader     c Connection: close
    15 ReqEnd       c 1052036059 1189647153.765747786  
1189647153.765867233 0.000073671 0.000063419 0.000056028
     0 StatAddr       192.168.10.254 0 115 24 24 0 0 1 8199 0
    15 SessionClose c not HTTP/1.1
    15 StatSess     c 192.168.10.254 1720 0 1 1 0 0 0 343 0
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189647155
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189647158
    15 SessionOpen  c 192.168.10.254 1727
    15 ReqStart     c 192.168.10.254 1727 1052036060
    15 RxRequest    c HEAD
    15 RxURL        c /static/mixer/playerdefault.swf
    15 RxProtocol   c HTTP/1.0
    15 VCL_call     c recv
    15 VCL_trace    c 1 7.14
    15 VCL_trace    c 2 13.9
    15 VCL_trace    c 4 18.5
    15 VCL_trace    c 5 18.9
    15 VCL_trace    c 6 18.32
    15 VCL_trace    c 7 23.5
    15 VCL_trace    c 8 23.9
    15 VCL_trace    c 10 28.5
    15 VCL_trace    c 11 28.9
    15 VCL_trace    c 12 28.77
    15 VCL_return   c lookup
    15 VCL_call     c hash
    15 VCL_trace    c 41 22.14
    15 VCL_return   c hash
    15 Hit          c 1052036036
    15 VCL_call     c hit
    15 VCL_trace    c 42 28.13
    15 VCL_trace    c 43 29.9
    15 VCL_trace    c 45 32.5
    15 VCL_return   c deliver
    15 Length       c 61986
    15 VCL_call     c deliver
    15 VCL_trace    c 57 51.17
    15 VCL_return   c deliver
    15 TxProtocol   c HTTP/1.1
    15 TxStatus     c 200
    15 TxResponse   c OK
    15 TxHeader     c Date: Thu, 13 Sep 2007 01:30:38 GMT
    15 TxHeader     c Server: Apache/2.2.4 (Fedora)
    15 TxHeader     c Last-Modified: Thu, 26 Apr 2007 17:42:49 GMT
    15 TxHeader     c ETag: "3368c1-f222-42f078c1f9840"
    15 TxHeader     c Content-Type: application/x-shockwave-flash
    15 TxHeader     c X-Pad: avoid browser bug
    15 TxHeader     c Content-Length: 61986
    15 TxHeader     c X-Varnish: 1052036060 1052036036
    15 TxHeader     c Age: 120
    15 TxHeader     c Via: 1.1 varnish
    15 TxHeader     c Connection: close
    15 ReqEnd       c 1052036060 1189647158.765828848  
1189647158.765937805 0.000067711 0.000058413 0.000050545
     0 StatAddr       192.168.10.254 0 120 25 25 0 0 1 8542 0
    15 SessionClose c not HTTP/1.1
    15 StatSess     c 192.168.10.254 1727 0 1 1 0 0 0 343 0
     0 ExpKill        1052036036 0
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189647161
    15 SessionOpen  c 192.168.10.254 1734
    15 ReqStart     c 192.168.10.254 1734 1052036061
    15 RxRequest    c HEAD
    15 RxURL        c /static/mixer/playerdefault.swf
    15 RxProtocol   c HTTP/1.0
    15 VCL_call     c recv
    15 VCL_trace    c 1 7.14
    15 VCL_trace    c 2 13.9
    15 VCL_trace    c 4 18.5
    15 VCL_trace    c 5 18.9
    15 VCL_trace    c 6 18.32
    15 VCL_trace    c 7 23.5
    15 VCL_trace    c 8 23.9
    15 VCL_trace    c 10 28.5
    15 VCL_trace    c 11 28.9
    15 VCL_trace    c 12 28.77
    15 VCL_return   c lookup
    15 VCL_call     c hash
    15 VCL_trace    c 41 22.14
    15 VCL_return   c hash
    15 VCL_call     c miss
    15 VCL_trace    c 46 35.14
    15 VCL_return   c fetch
    18 BackendClose   default
    18 BackendOpen  b default 192.168.10.101 45075 192.168.10.80 80
    18 BackendXID   b 1052036061
    15 Backend      c 18 default
    18 TxRequest    b GET
    18 TxURL        b /mixer/playerdefault.swf
    18 TxProtocol   b HTTP/1.1
    18 TxHeader     b host: nyp-web-1.corp.razz.com
    18 TxHeader     b X-Varnish: 1052036061
    18 TxHeader     b X-Forwarded-for: 192.168.10.254
    18 RxProtocol   b HTTP/1.1
    18 RxStatus     b 200
    18 RxResponse   b OK
    18 RxHeader     b Date: Thu, 13 Sep 2007 01:32:43 GMT
    18 RxHeader     b Server: Apache/2.2.4 (Fedora)
    18 RxHeader     b Last-Modified: Thu, 26 Apr 2007 17:42:49 GMT
    18 RxHeader     b ETag: "3368c1-f222-42f078c1f9840"
    18 RxHeader     b Accept-Ranges: bytes
    18 RxHeader     b Content-Length: 61986
    18 RxHeader     b Content-Type: application/x-shockwave-flash
    18 RxHeader     b X-Pad: avoid browser bug
    15 ObjProtocol  c HTTP/1.1
    15 ObjStatus    c 200
    15 ObjResponse  c OK
    15 ObjHeader    c Date: Thu, 13 Sep 2007 01:32:43 GMT
    15 ObjHeader    c Server: Apache/2.2.4 (Fedora)
    15 ObjHeader    c Last-Modified: Thu, 26 Apr 2007 17:42:49 GMT
    15 ObjHeader    c ETag: "3368c1-f222-42f078c1f9840"
    15 ObjHeader    c Content-Type: application/x-shockwave-flash
    15 ObjHeader    c X-Pad: avoid browser bug
    18 BackendReuse b default
    15 TTL          c 1052036061 RFC 120 1189647163 1189647163 0 0 0
    15 VCL_call     c fetch
    15 VCL_trace    c 14 37.15
    15 VCL_trace    c 15 39.9
    15 VCL_trace    c 17 43.5
    15 VCL_trace    c 18 43.9
    15 VCL_trace    c 20 47.5
    15 VCL_trace    c 21 47.9
    15 VCL_trace    c 23 51.5
    15 VCL_trace    c 24 51.9
    15 VCL_trace    c 26 55.5
    15 VCL_return   c insert
    15 Length       c 61986
    15 VCL_call     c deliver
    15 VCL_trace    c 57 51.17
    15 VCL_return   c deliver
    15 TxProtocol   c HTTP/1.1
    15 TxStatus     c 200
    15 TxResponse   c OK
    15 TxHeader     c Date: Thu, 13 Sep 2007 01:32:43 GMT
    15 TxHeader     c Server: Apache/2.2.4 (Fedora)
    15 TxHeader     c Last-Modified: Thu, 26 Apr 2007 17:42:49 GMT
    15 TxHeader     c ETag: "3368c1-f222-42f078c1f9840"
    15 TxHeader     c Content-Type: application/x-shockwave-flash
    15 TxHeader     c X-Pad: avoid browser bug
    15 TxHeader     c Content-Length: 61986
    15 TxHeader     c X-Varnish: 1052036061
    15 TxHeader     c Age: 0
    15 TxHeader     c Via: 1.1 varnish
    15 TxHeader     c Connection: close
    15 ReqEnd       c 1052036061 1189647163.765805483  
1189647163.767508268 0.000074863 0.001671553 0.000031233
     0 StatAddr       192.168.10.254 0 125 26 26 0 0 2 8872 0
    15 SessionClose c not HTTP/1.1
    15 StatSess     c 192.168.10.254 1734 0 1 1 0 0 1 330 0
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189647164
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189647167
    15 SessionOpen  c 192.168.10.254 1741
    15 ReqStart     c 192.168.10.254 1741 1052036062
    15 RxRequest    c HEAD
    15 RxURL        c /static/mixer/playerdefault.swf
    15 RxProtocol   c HTTP/1.0
    15 VCL_call     c recv
    15 VCL_trace    c 1 7.14
    15 VCL_trace    c 2 13.9
    15 VCL_trace    c 4 18.5
    15 VCL_trace    c 5 18.9
    15 VCL_trace    c 6 18.32
    15 VCL_trace    c 7 23.5
    15 VCL_trace    c 8 23.9
    15 VCL_trace    c 10 28.5
    15 VCL_trace    c 11 28.9
    15 VCL_trace    c 12 28.77
    15 VCL_return   c lookup
    15 VCL_call     c hash
    15 VCL_trace    c 41 22.14
    15 VCL_return   c hash
    15 Hit          c 1052036061
    15 VCL_call     c hit
    15 VCL_trace    c 42 28.13
    15 VCL_trace    c 43 29.9
    15 VCL_trace    c 45 32.5
    15 VCL_return   c deliver
    15 Length       c 61986
    15 VCL_call     c deliver
    15 VCL_trace    c 57 51.17
    15 VCL_return   c deliver
    15 TxProtocol   c HTTP/1.1
    15 TxStatus     c 200
    15 TxResponse   c OK
    15 TxHeader     c Date: Thu, 13 Sep 2007 01:32:43 GMT
    15 TxHeader     c Server: Apache/2.2.4 (Fedora)
    15 TxHeader     c Last-Modified: Thu, 26 Apr 2007 17:42:49 GMT
    15 TxHeader     c ETag: "3368c1-f222-42f078c1f9840"
    15 TxHeader     c Content-Type: application/x-shockwave-flash
    15 TxHeader     c X-Pad: avoid browser bug
    15 TxHeader     c Content-Length: 61986
    15 TxHeader     c X-Varnish: 1052036062 1052036061
    15 TxHeader     c Age: 5
    15 TxHeader     c Via: 1.1 varnish
    15 TxHeader     c Connection: close
    15 ReqEnd       c 1052036062 1189647168.765779495  
1189647168.765885353 0.000075102 0.000062466 0.000043392
     0 StatAddr       192.168.10.254 0 130 27 27 0 0 2 9213 0
    15 SessionClose c not HTTP/1.1
    15 StatSess     c 192.168.10.254 1741 0 1 1 0 0 0 341 0
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189647170
     0 CLI            Rd ping
     0 CLI            Wr 0 200 PONG 1189647173
    15 SessionOpen  c 192.168.10.254 1748
    15 ReqStart     c 192.168.10.254 1748 1052036063
    15 RxRequest    c HEAD
    15 RxURL        c /static/mixer/playerdefault.swf
    15 RxProtocol   c HTTP/1.0
    15 VCL_call     c recv
    15 VCL_trace    c 1 7.14
    15 VCL_trace    c 2 13.9
    15 VCL_trace    c 4 18.5
    15 VCL_trace    c 5 18.9
    15 VCL_trace    c 6 18.32
    15 VCL_trace    c 7 23.5
    15 VCL_trace    c 8 23.9
    15 VCL_trace    c 10 28.5
    15 VCL_trace    c 11 28.9
    15 VCL_trace    c 12 28.77
    15 VCL_return   c lookup
    15 VCL_call     c hash
    15 VCL_trace    c 41 22.14
    15 VCL_return   c hash
    15 Hit          c 1052036061
    15 VCL_call     c hit
    15 VCL_trace    c 42 28.13
    15 VCL_trace    c 43 29.9
    15 VCL_trace    c 45 32.5
    15 VCL_return   c deliver
    15 Length       c 61986
    15 VCL_call     c deliver
    15 VCL_trace    c 57 51.17
    15 VCL_return   c deliver
    15 TxProtocol   c HTTP/1.1
    15 TxStatus     c 200
    15 TxResponse   c OK
    15 TxHeader     c Date: Thu, 13 Sep 2007 01:32:43 GMT
    15 TxHeader     c Server: Apache/2.2.4 (Fedora)
    15 TxHeader     c Last-Modified: Thu, 26 Apr 2007 17:42:49 GMT
    15 TxHeader     c ETag: "3368c1-f222-42f078c1f9840"
    15 TxHeader     c Content-Type: application/x-shockwave-flash
    15 TxHeader     c X-Pad: avoid browser bug
    15 TxHeader     c Content-Length: 61986
    15 TxHeader     c X-Varnish: 1052036063 1052036061
    15 TxHeader     c Age: 10
    15 TxHeader     c Via: 1.1 varnish
    15 TxHeader     c Connection: close
    15 ReqEnd       c 1052036063 1189647173.765821457  
1189647173.765940905 0.000079632 0.000065804 0.000053644
     0 StatAddr       192.168.10.254 0 135 28 28 0 0 2 9555 0
    15 SessionClose c not HTTP/1.1
    15 StatSess     c 192.168.10.254 1748 0 1 1 0 0 0 342 0


Footnote:  it looks like requests from the wild are behaving similarly:

192.168.10.254 - - [12/Sep/2007:18:40:23 -0700] "HEAD /static/mixer/ 
playerdefault.swf HTTP/1.0" 200 61986 "-" "-"
192.168.10.254 - - [12/Sep/2007:18:40:28 -0700] "HEAD /static/mixer/ 
playerdefault.swf HTTP/1.0" 200 61986 "-" "-"
127.0.0.1 - - [12/Sep/2007:18:40:28 -0700] "(null) (null)  
(null)" (null) (null) "-" "-"
192.168.10.101 - - [13/Sep/2007:01:40:30 -0700] "GET http://nyp- 
web-1.corp.razz.com/mixer/player8a.swf HTTP/1.1" 200 59986 "-"  
"Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en) AppleWebKit/522.11.1  
(KHTML, like Gecko) Version/3.0.3 Safari/522.12.1"
208.106.97.31 - - [12/Sep/2007:18:40:30 -0700] "GET http:// 
www.razz.com/static/mixer/player8a.swf?u=2743&s=1&o=2743 HTTP/1.1"  
200 59986 "-" "Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en)  
AppleWebKit/522.11.1 (KHTML, like Gecko) Version/3.0.3 Safari/522.12.1"
127.0.0.1 - - [13/Sep/2007:01:40:31 -0700] "GET http://nyp- 
web-1.corp.razz.com/mixer/saved/1/1/1/e0ca0476.flv HTTP/1.1" 200  
107712 "http://www.razz.com/static/mixer/player8a.swf? 
u=2743&s=1&o=2743" "Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en)  
AppleWebKit/522.11.1 (KHTML, like Gecko) Version/3.0.3 Safari/522.12.1"
208.106.97.31 - - [12/Sep/2007:18:40:32 -0700] "GET http:// 
www.razz.com/static/mixer/saved/1/1/1/e0ca0476.flv HTTP/1.1" 200  
107712 "http://www.razz.com/static/mixer/player8a.swf? 
u=2743&s=1&o=2743" "Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en)  
AppleWebKit/522.11.1 (KHTML, like Gecko) Version/3.0.3 Safari/522.12.1"
192.168.10.254 - - [12/Sep/2007:18:40:33 -0700] "HEAD /static/mixer/ 
playerdefault.swf HTTP/1.0" 200 61986 "-" "-"

Thanks for your consideration!
-Tom




From duja at torlen.net  Thu Sep 13 07:51:35 2007
From: duja at torlen.net (Erik)
Date: Thu, 13 Sep 2007 09:51:35 +0200
Subject: Problems with the cache
Message-ID: <0osjq35ei7xttfr.130920070951@server2k3>

>> Are you sure you've set up varnish as proxy?
>> * What port is varnish binding to?
>> * what port is your backend running on?
>> * How are you accessing the site?

Im sure, I have proxy set to listen on port 80 and my apache2 server on port 8080. I can access my site without any problem on both port 80, through the proxy, and on port 8080.

Erik



From joao.correia at gmail.com  Thu Sep 13 12:03:37 2007
From: joao.correia at gmail.com (Joao Correia)
Date: Thu, 13 Sep 2007 13:03:37 +0100
Subject: Zope/Plone and Varnish
Message-ID: <6af0ecc70709130503g12b6040cr9c4ed6a996abe439@mail.gmail.com>

Hello,

Im trying vernish out. I compiled it from source, everything nice.
I then used CacheFu to generate the vcl file.  Im running Varnish in
port 80 .
It has some strange behauviour I cannot explain, if enable cache on
authenticated sessions the page screws up badly, seams css doesnt load
and I cant understand why.

Also sending content using the form (Exfile, or image) doesnt work.


   /* Do not cache when authenticated via HTTP Basic or Digest
Authentication */
   if (req.http.Authenticate || req.http.Authorization) {
     /*  pipe; */
       lookup;
  }

   /* Do not cache when authenticated via "__ac" cookies */
   if (req.http.Cookie && req.http.Cookie ~ "__ac=") {
     /*  pipe; */
      lookup;
   }

   /* Do not cache when authenticated via "_ZopeId" cookies */
   if (req.http.Cookie && req.http.Cookie ~ "_ZopeId=") {
     /*  pipe; */
      lookup;
   }


Other thing is: Can I make lets say a /content on Varnish to be
http://remote.url/var/$1
On my website I fetch an html from another server using Ajax and it
doesnt work because ajax cant
communicate with other domains because of security issues.



Any tips ?

Thanks
Joao Correia


From wtogami at redhat.com  Thu Sep 13 17:55:25 2007
From: wtogami at redhat.com (Warren Togami)
Date: Thu, 13 Sep 2007 13:55:25 -0400
Subject: Conditional purging possible?
Message-ID: <46E9798D.2040902@redhat.com>

http://download.fedora.redhat.com/pub/fedora/linux/development/i386/os/repodata/

If repomd.xml is a cache miss, I want all other files in this directory 
to be purged from the cache.  Is it possible for VCL to do this?

How often will varnish check to see if a file like repomd.xml has changed?

Warren Togami
wtogami at redhat.com


From optilude at gmx.net  Thu Sep 13 20:44:16 2007
From: optilude at gmx.net (Martin Aspeli)
Date: Thu, 13 Sep 2007 21:44:16 +0100
Subject: Zope/Plone and Varnish
In-Reply-To: <6af0ecc70709130503g12b6040cr9c4ed6a996abe439@mail.gmail.com>
References: <6af0ecc70709130503g12b6040cr9c4ed6a996abe439@mail.gmail.com>
Message-ID: <fcc7fh$d73$1@sea.gmane.org>

Joao Correia wrote:
> Hello,
> 
> Im trying vernish out. I compiled it from source, everything nice.
> I then used CacheFu to generate the vcl file.

CacheFu generates VCL files now?

In any case, discussions of Zope/Plone and CacheFu are not directly 
appropriate here, I doubt the Varnish developers know much about it.

>  Im running Varnish in
> port 80 .
> It has some strange behauviour I cannot explain, if enable cache on
> authenticated sessions the page screws up badly, seams css doesnt load
> and I cant understand why.

I'm using Varnish 1.0.4 with CacheFu 1.1 and Plone 3.0 on my website. 
Varnish 1.0.4 will only compile on Linux, BSD and similar (i.e. not on 
OS X) so be aware of that.

Lots of people (i.e. everyone I've spoken to) have reported problems 
with Varnish 1.1.1 in front of Plone (though it's not directly a Plone 
problem, since accessing it directly does not exhibit the same behvaiour 
- it could of course be some bad cache headers, but I've been unable to 
confirm that). I experience periodic "dropped" requests or requests that 
never complete (see other thread on this list). I'm really hoping 
someone can get to the bottom of this, since being stuck on an older 
version is not ideal. :-(

Martin

-- 
Acquisition is a jealous mistress



From phk at phk.freebsd.dk  Thu Sep 13 20:51:55 2007
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Thu, 13 Sep 2007 20:51:55 +0000
Subject: Conditional purging possible? 
In-Reply-To: Your message of "Thu, 13 Sep 2007 13:55:25 -0400."
	<46E9798D.2040902@redhat.com> 
Message-ID: <1378.1189716715@critter.freebsd.dk>

In message <46E9798D.2040902 at redhat.com>, Warren Togami writes:
>http://download.fedora.redhat.com/pub/fedora/linux/development/i386/os/repodata/
>
>If repomd.xml is a cache miss, I want all other files in this directory 
>to be purged from the cache.  Is it possible for VCL to do this?

No.

First because we don't have a concept of directories, to Varnish
all we have is a URL string.

But second, and more importantly, because we don't have acess to anything
but the current object.

-- 
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.


From ssm at linpro.no  Fri Sep 14 06:20:13 2007
From: ssm at linpro.no (Stig Sandbeck Mathisen)
Date: Fri, 14 Sep 2007 08:20:13 +0200
Subject: Zope/Plone and Varnish
In-Reply-To: <6af0ecc70709130503g12b6040cr9c4ed6a996abe439@mail.gmail.com>
	(Joao Correia's message of "Thu, 13 Sep 2007 13:03:37 +0100")
References: <6af0ecc70709130503g12b6040cr9c4ed6a996abe439@mail.gmail.com>
Message-ID: <7x4phx6a5e.fsf@iostat.e.linpro.no>

"Joao Correia" <joao.correia at gmail.com> writes:

> Im trying vernish out.  I compiled it from source, everything nice.
> I then used CacheFu to generate the vcl file.

Could you post the complete generated vcl file from CacheFu, please?

> Im running Varnish in port 80.

Do you do rewriting somewhere, or do you map hostname to path in your
virtualhostmonster config?

> It has some strange behauviour I cannot explain, if enable cache on
> authenticated sessions the page screws up badly, seams css doesnt
> load and I cant understand why.
>
> Also sending content using the form (Exfile, or image) doesnt work.

Looking at the logs will tell you what varnish does with each request:

## Recieved client requests to varnish
varnishlog -r /var/log/varnish/varnish.log -o -c RxURL /IEFixes.css

## Varnish requests sent to backend
varnishlog -r /var/log/varnish/varnish.log -o -b TxURL /IEFixes.css

-- 
Stig Sandbeck Mathisen, Linpro


From gaute at pht.no  Fri Sep 14 13:31:22 2007
From: gaute at pht.no (gaute at pht.no)
Date: Fri, 14 Sep 2007 15:31:22 +0200
Subject: Conditional purging possible?
In-Reply-To: <1378.1189716715@critter.freebsd.dk>
References: <1378.1189716715@critter.freebsd.dk>
Message-ID: <200709141531.22480.gaute@pht.no>

On Thursday 13 September 2007 22:51:55 Poul-Henning Kamp wrote:
> In message <46E9798D.2040902 at redhat.com>, Warren Togami writes:
> >http://download.fedora.redhat.com/pub/fedora/linux/development/i386/os/rep
> >odata/
> >
> >If repomd.xml is a cache miss, I want all other files in this directory
> >to be purged from the cache.  Is it possible for VCL to do this?
>
> No.
>
> First because we don't have a concept of directories, to Varnish
> all we have is a URL string.
>
> But second, and more importantly, because we don't have acess to anything
> but the current object.

How about having vcl_miss somehow notify an external script?
If you could do that, and you can predict all possible filenames, you could 
just generate PURGE requests externally.

If you could rewrite the request to hit your script instead of repomd.xml but 
have vcl_hash work on the original string, and the script returning the 
content of repomd.xml, I guess you would have a notification mechanism..

Not totally sure if this is doable in the current release tho, I'm still 
running 1.0.4

Hm.. I guess you could use the "drop into C" option as well...

Regards

Gaute Amundsen








From ric at digitalmarbles.com  Sat Sep 15 01:16:07 2007
From: ric at digitalmarbles.com (Ricardo Newbery)
Date: Fri, 14 Sep 2007 18:16:07 -0700
Subject: Zope/Plone and Varnish
In-Reply-To: <6af0ecc70709130503g12b6040cr9c4ed6a996abe439@mail.gmail.com>
References: <6af0ecc70709130503g12b6040cr9c4ed6a996abe439@mail.gmail.com>
Message-ID: <871F314D-5DE5-49C3-9CD9-7ACC9635D418@digitalmarbles.com>


On Sep 13, 2007, at 5:03 AM, Joao Correia wrote:

> Hello,
>
> Im trying vernish out. I compiled it from source, everything nice.
> I then used CacheFu to generate the vcl file.  Im running Varnish in
> port 80 .


First, this may not be the best list for your questions.  If you need  
help with Plone/CacheFu, it might be more productive to try the Plone  
support forums (http://plone.org/support)

Second, the Varnish configs generated by CacheFu are labeled "beta"  
as they haven't been completely tested yet.  (perhaps they should  
have been labeled 'alpha').

Third, CacheFu's varnish-in-front config in particular has not been  
tested well as it depends on the new varnish string substitution  
feature which was recently introduced in Varnish 1.1 (which for  
unknown reasons is currently unstable with the Plone configuration).


> It has some strange behauviour I cannot explain, if enable cache on
> authenticated sessions the page screws up badly, seams css doesnt load
> and I cant understand why.


Another problem.  None of the CacheFu configs are designed to cache  
authenticated sessions.


> Also sending content using the form (Exfile, or image) doesnt work.


Sorry, "doesn't work" is not enough information.



>    /* Do not cache when authenticated via HTTP Basic or Digest
> Authentication */
>    if (req.http.Authenticate || req.http.Authorization) {
>      /*  pipe; */
>        lookup;
>   }
>
>    /* Do not cache when authenticated via "__ac" cookies */
>    if (req.http.Cookie && req.http.Cookie ~ "__ac=") {
>      /*  pipe; */
>       lookup;
>    }
>
>    /* Do not cache when authenticated via "_ZopeId" cookies */
>    if (req.http.Cookie && req.http.Cookie ~ "_ZopeId=") {
>      /*  pipe; */
>       lookup;
>    }
>


These are probably *bad* changes to the config unless you also add  
some extra cache keys for varnish to keep track of the authenticated  
pages.



> Other thing is: Can I make lets say a /content on Varnish to be
> http://remote.url/var/$1
> On my website I fetch an html from another server using Ajax and it
> doesnt work because ajax cant
> communicate with other domains because of security issues.


Sorry, I don't understand what this has to do with Varnish.

Ric






From duja at torlen.net  Mon Sep 17 16:21:37 2007
From: duja at torlen.net (Erik Torlen)
Date: Mon, 17 Sep 2007 18:21:37 +0200
Subject: varnishstat vs. telnet stats
Message-ID: <46EEA991.5090006@torlen.net>

Hi!
I still have problems with varnish and its cache. Its configured to 
listen on port 80 which it does fine. My webserver is set to listen on 
port 8080  and the backend on varnish is configured to:
backend default {
        set backend.host = "127.0.0.1";
        set backend.port = "8080";
}

Now if I make a request of a picture to port 80, I see in apache2 logs 
that it passes the picture fine. But if I check varnishstat, its still 
empty with zeros almost everywhere. The only values that are set is:
/1 N struct sess_mem
2 N struct smf
2 N large free smf
47 SHM records
47 SHM writes
1073741824 bytes free/

This is after a *single *request to a picture has been made.

If I then close down varnishstat and telnets in to port 6082 and type 
/stats/ I get totally different data compared with varnishstat.
Here is exactly what it prints out in the telnet console (when using the 
/stats/ command):

/           1  Client connections accepted
           1  Client requests received
           0  Cache hits
           0  Cache hits for pass
           0  Cache misses
           1  Backend connections success
           0  Backend connections failures
           0  Backend connections reuses
           1  Backend connections recycles
           0  Backend connections unused
           1  N struct srcaddr
           1  N active struct srcaddr
           2  N struct sess_mem
           2  N struct sess
           0  N struct object
           1  N struct objecthead
           2  N struct smf
           0  N small free smf
           2  N large free smf
           1  N struct vbe_conn
           1  N worker threads
           1  N worker threads created
           0  N worker threads not created
           0  N worker threads limited
           0  N queued work requests
           1  N overflowed work requests
           0  N dropped work requests
           0  N expired objects
           0  N objects on deathrow
           0  HTTP header overflows
           0  Objects sent with sendfile
           1  Objects sent with write
           1  Total Sessions
           1  Total Requests
           0  Total pipe
           0  Total pass
           1  Total fetch
         295  Total header bytes
          90  Total body bytes
           0  Session Closed
           0  Session Pipeline
           0  Session Read Ahead
           1  Session herd
          98  SHM records
          27  SHM writes
           0  SHM MTX contention
           1  allocator requests
           0  outstanding allocations
           0  bytes allocated
  1073741824  bytes free
           1  Backend requests made

/Everything looking good to me!

But why doesn't varnishstat display the same data as telnet command 
"stats" did?

Regards
Erik


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20070917/458631b8/attachment.html>

From richard at one.ie  Tue Sep 18 08:40:40 2007
From: richard at one.ie (Richard Welter)
Date: Tue, 18 Sep 2007 15:40:40 +0700
Subject: Zope/Plone and Varnish hanging
Message-ID: <a71872a60709180140x7253bd1au687d6d75db5f25eb@mail.gmail.com>

I've noticed the same problem as Joao Correia and Martin Aspeli; after
some requests, especially having to do with forms, Varnish hangs for a
while.
The problem has to do with these 2 tickets,
http://varnish.projects.linpro.no/ticket/129 and
http://varnish.projects.linpro.no/ticket/47 but it seems there is no
fix yet, even though ticket 129 has been marked fixed.

I found that adding option '-p pipe_timeout=1' made the problem a bit
less noticeable by making the hanging pipe time out after just 1
second, but it still requires you to reload the page after most form
actions and the error message it shows is not very elegant either.

So is there any idea when this problem might get fixed? Seeing how
1.0.4 didn't have this problem there should be a solution for it,
right?

Richard


From optilude at gmx.net  Tue Sep 18 20:02:08 2007
From: optilude at gmx.net (Martin Aspeli)
Date: Tue, 18 Sep 2007 21:02:08 +0100
Subject: Zope/Plone and Varnish hanging
In-Reply-To: <a71872a60709180140x7253bd1au687d6d75db5f25eb@mail.gmail.com>
References: <a71872a60709180140x7253bd1au687d6d75db5f25eb@mail.gmail.com>
Message-ID: <fcpasq$sec$1@sea.gmane.org>

Richard Welter wrote:
> I've noticed the same problem as Joao Correia and Martin Aspeli; after
> some requests, especially having to do with forms, Varnish hangs for a
> while.
> The problem has to do with these 2 tickets,
> http://varnish.projects.linpro.no/ticket/129 and
> http://varnish.projects.linpro.no/ticket/47 but it seems there is no
> fix yet, even though ticket 129 has been marked fixed.
> 
> I found that adding option '-p pipe_timeout=1' made the problem a bit
> less noticeable by making the hanging pipe time out after just 1
> second, but it still requires you to reload the page after most form
> actions and the error message it shows is not very elegant either.
> 
> So is there any idea when this problem might get fixed? Seeing how
> 1.0.4 didn't have this problem there should be a solution for it,
> right?

I suspect there are different problems exhibiting similar behaviour. The 
fact that pipe mode doesn't handle POST is one thing, and can cause 
forms to hange more or less deterministically. There is a wider issue 
with requests hanging intermittently and less predictably in 1.1 and 
trunk. Maybe it's something that Plone (or CacheFu) does, but I can't 
see a good reason - it's definitely not a problem when accessing the 
backend completely.

I did try to post logs, and I'm willing to help debug this, but so far 
it seems no-one with enough knowledge of Varnish to guide me in doing so 
has had time to look into it.

Martin

-- 
Acquisition is a jealous mistress



From andrew at imeem.com  Tue Sep 18 23:04:58 2007
From: andrew at imeem.com (Andrew Knapp)
Date: Tue, 18 Sep 2007 16:04:58 -0700
Subject: Varnish memory leak?
Message-ID: <0A3A6EA86530E64EA3BEA603EC4401CAF07B20@dexbe014-8.exch014.msoutlookonline.net>

I'm running Varnish 1.1.1 on Centos 5 x86_64. varnishd has been running
for about 20 days, but now the machine is using about 100% of the CPU,
and most of it is in iowait because 100% of the swap is being used by
varnishd (this is happening on about 8 different cache servers). 

 

Is this a known issue? Or am I doing something wrong (with the command
line arguments or whatnot)?

 

Here is the relevant information:

 

Command line arguments:

/usr/sbin/varnishd -a :80 -f /etc/varnish/photo.vcl -T 127.0.0.1:6082 -t
120 -w 10,1000,120 -s file,/c01/varnish/varnish_storage.bin ,40% -u
varnish -g varnish -P /var/run/varnish.pid

 

df of /c01:

/dev/sdb1             460G  102G  334G  24% /c01 (it's a raid 10 array
of 14 73gb disks)

 

uname -a:

Linux <hostname> 2.6.18-8.1.8.el5 #1 SMP Tue Jul 10 06:39:17 EDT 2007
x86_64 x86_64 x86_64 GNU/Linux

 

Output of vanishstat -1:

client_conn          30637407        17.88 Client connections accepted

client_req           69880298        40.78 Client requests received

cache_hit            65771178        38.38 Cache hits

cache_hitpass              82         0.00 Cache hits for pass

cache_miss            4107980         2.40 Cache misses

backend_conn          4108677         2.40 Backend connections success

backend_fail                0         0.00 Backend connections failures

backend_reuse         3771264         2.20 Backend connections reuses

backend_recycle       3920436         2.29 Backend connections recycles

backend_unused             16         0.00 Backend connections unused

n_srcaddr                1471          .   N struct srcaddr

n_srcaddr_act              99          .   N active struct srcaddr

n_sess_mem                361          .   N struct sess_mem

n_sess                    129          .   N struct sess

n_object              4171343          .   N struct object

n_objecthead          4171347          .   N struct objecthead

n_smf                 4107787          .   N struct smf

n_smf_frag                  0          .   N small free smf

n_smf_large                 1          .   N large free smf

n_vbe_conn                145          .   N struct vbe_conn

n_wrk                      56          .   N worker threads

n_wrk_create            70814         0.04 N worker threads created

n_wrk_failed                0         0.00 N worker threads not created

n_wrk_max                   0         0.00 N worker threads limited

n_wrk_queue                 0         0.00 N queued work requests

n_wrk_overflow          70814         0.04 N overflowed work requests

n_wrk_drop                  0         0.00 N dropped work requests

n_expired                 195          .   N expired objects

n_deathrow                  0          .   N objects on deathrow

losthdr                     0         0.00 HTTP header overflows

n_objsendfile               0         0.00 Objects sent with sendfile

n_objwrite           69142017        40.35 Objects sent with write

s_sess               30637382        17.88 Total Sessions

s_req                69880318        40.78 Total Requests

s_pipe                     41         0.00 Total pipe

s_pass                      0         0.00 Total pass

s_fetch               4108636         2.40 Total fetch

s_hdrbytes        23065938774     13461.07 Total header bytes

s_bodybytes      1500010438157    875392.50 Total body bytes

sess_closed           2794850         1.63 Session Closed

sess_pipeline           85042         0.05 Session Pipeline

sess_readahead              0         0.00 Session Read Ahead

sess_herd            67587880        39.44 Session herd

shm_records        3193762280      1863.85 SHM records

shm_writes          401219061       234.15 SHM writes

shm_cont                97272         0.06 SHM MTX contention

sm_nreq               4109108         2.40 allocator requests

sm_nobj               4107786          .   outstanding allocations

sm_balloc         51938721792          .   bytes allocated

sm_bfree          57256402944          .   bytes free

backend_req           4108636         2.40 Backend requests made

 

VCL Code:

backend default {

        set backend.host = "127.0.0.1";

        set backend.port = "81";

}

 

sub vcl_recv {

        if (req.request == "GET" && req.http.cookie) {

                lookup;

        }

}

 

sub vcl_fetch {

        if (obj.ttl < 3600s) {

                set obj.ttl = 3600s;

        }

}

 

sub vcl_miss {

        if (req.url ~
"^/g/([a-f0-9])([a-f0-9])([a-f0-9]{30})\.([a-z0-9]{3,4})$") {

                set bereq.url = regsub(req.url,
"^/g/([a-f0-9])([a-f0-9])([a-f0-9]{30})\.([a-z0-9]{3,4})$",
"/$1/$2/$1$2$3.$4");

                fetch;

        }

 

        if (req.url ~ "^/g/([a-f0-9])([a-f0-9])([a-f0-9]{30})$") {

                set bereq.url = regsub(req.url,
"^/g/([a-f0-9])([a-f0-9])([a-f0-9]{30})$", "/$1/$2/$1$2$3");

                fetch;

        }

 

        if (req.url ~
"^/g/i/([a-f0-9])([a-f0-9])([a-f0-9]{30})\.([a-z0-9]{3,4})$") {

                set bereq.url = regsub(req.url,
"^/g/i/([a-f0-9])([a-f0-9])([a-f0-9]{30})\.([a-z0-9]{3,4})$",
"/fullsize/$1/$2/$1$2$3.$4");

                fetch;

        }

 

        if (req.url ~ "^/g/i/([a-f0-9])([a-f0-9])([a-f0-9]{30})$") {

                set bereq.url = regsub(req.url,
"^/g/i/([a-f0-9])([a-f0-9])([a-f0-9]{30})$", "/fullsize/$1/$2/$1$2$3");

                fetch;

        }

 

        if (req.url ~ "^/g/v/([a-f0-9])([a-f0-9])([a-f0-9]{30})\.jpg$")
{

                set bereq.url = regsub(req.url,
"^/g/v/([a-f0-9])([a-f0-9])([a-f0-9]{30})\.jpg$",
"/video/$1/$2/$1$2$3/thumb_hi.jpg");

                fetch;

        }

 

        if (req.url ~
"^/g/v/([a-f0-9])([a-f0-9])([a-f0-9]{30})_([0-9]{5})\.jpg$") {

                set bereq.url = regsub(req.url,
"^/g/v/([a-f0-9])([a-f0-9])([a-f0-9]{30})_([0-9]{5})\.jpg$",
"/video/$1/$2/$1$2$3/frames/frame$4.jpg");

                fetch;

        }

 

        set bereq.url = "/404.html";

        fetch;

}

 

Thanks,

Andy

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20070918/c37949e6/attachment.html>

From trondmm-varnish at crusaders.no  Wed Sep 19 12:34:21 2007
From: trondmm-varnish at crusaders.no (Trond Michelsen)
Date: Wed, 19 Sep 2007 14:34:21 +0200
Subject: Empty logentries
Message-ID: <20070919123421.GA22366@crusaders.no>

Hi.

We're using varnish 1.0.4, and we're seeing some strange logentries.

- - - [19/Sep/2007:14:29:57 +0200] "(null) (null) (null)" (null) (null) "-" "-"
- - - [19/Sep/2007:14:29:58 +0200] "(null) (null) (null)" (null) (null) "-" "-"
- - - [19/Sep/2007:14:29:58 +0200] "(null) (null) (null)" (null) (null) "-" "-"
- - - [19/Sep/2007:14:29:58 +0200] "(null) (null) (null)" (null) (null) "-" "-"
- - - [19/Sep/2007:14:29:58 +0200] "(null) (null) (null)" (null) (null) "-" "-"
- - - [19/Sep/2007:14:29:58 +0200] "(null) (null) (null)" (null) (null) "-" "-"
- - - [19/Sep/2007:14:29:59 +0200] "(null) (null) (null)" (null) (null) "-" "-"
- - - [19/Sep/2007:14:29:59 +0200] "(null) (null) (null)" (null) (null) "-" "-"
- - - [19/Sep/2007:14:29:59 +0200] "(null) (null) (null)" (null) (null) "-" "-"
- - - [19/Sep/2007:14:29:59 +0200] "(null) (null) (null)" (null) (null) "-" "-"
- - - [19/Sep/2007:14:29:59 +0200] "(null) (null) (null)" (null) (null) "-" "-"
- - - [19/Sep/2007:14:29:59 +0200] "(null) (null) (null)" (null) (null) "-" "-"
- - - [19/Sep/2007:14:29:59 +0200] "(null) (null) (null)" (null) (null) "-" "-"
- - - [19/Sep/2007:14:30:00 +0200] "(null) (null) (null)" (null) (null) "-" "-"
- - - [19/Sep/2007:14:30:00 +0200] "(null) (null) (null)" (null) (null) "-" "-"
- - - [19/Sep/2007:14:30:00 +0200] "(null) (null) (null)" (null) (null) "-" "-"
- - - [19/Sep/2007:14:30:00 +0200] "(null) (null) (null)" (null) (null) "-" "-"
- - - [19/Sep/2007:14:30:00 +0200] "(null) (null) (null)" (null) (null) "-" "-"
- - - [19/Sep/2007:14:30:00 +0200] "(null) (null) (null)" (null) (null) "-" "-"
- - - [19/Sep/2007:14:30:00 +0200] "(null) (null) (null)" (null) (null) "-" "-"
- - - [19/Sep/2007:14:30:00 +0200] "(null) (null) (null)" (null) (null) "-" "-"
- - - [19/Sep/2007:14:30:01 +0200] "(null) (null) (null)" (null) (null) "-" "-"

Any idea of what will cause Varnish to create these empty entries?

We have about 250-300 requests per second at the moment.

-- 
Trond Michelsen



From caleb.anthony at gmail.com  Wed Sep 19 17:24:51 2007
From: caleb.anthony at gmail.com (Caleb Anthony)
Date: Wed, 19 Sep 2007 11:24:51 -0600
Subject: Case Insensitive Regular Expressions
Message-ID: <33afbbe70709191024l5c935f7fi11c6f2d9c06b55f1@mail.gmail.com>

Hello,

It doesn't appear that VCL supports case insensitive regular
expressions. Is this true?

I have tried all the methods that I am aware of to signify case
insensitivity, and none seem to work.

Any help would be appreciated.

Thanks.


From phk at phk.freebsd.dk  Wed Sep 19 17:35:02 2007
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Wed, 19 Sep 2007 17:35:02 +0000
Subject: Case Insensitive Regular Expressions 
In-Reply-To: Your message of "Wed, 19 Sep 2007 11:24:51 CST."
	<33afbbe70709191024l5c935f7fi11c6f2d9c06b55f1@mail.gmail.com> 
Message-ID: <3533.1190223302@critter.freebsd.dk>

In message <33afbbe70709191024l5c935f7fi11c6f2d9c06b55f1 at mail.gmail.com>, "Cale
b Anthony" writes:
>Hello,
>
>It doesn't appear that VCL supports case insensitive regular
>expressions. Is this true?

Yes because I didn't think of that.

-- 
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.


From ric at digitalmarbles.com  Thu Sep 20 03:08:56 2007
From: ric at digitalmarbles.com (Ricardo Newbery)
Date: Wed, 19 Sep 2007 20:08:56 -0700
Subject: Case Insensitive Regular Expressions 
In-Reply-To: <3533.1190223302@critter.freebsd.dk>
References: <3533.1190223302@critter.freebsd.dk>
Message-ID: <52EBF0BB-B6EB-4937-AB9A-7ACCE3D08EF0@digitalmarbles.com>


On Sep 19, 2007, at 10:35 AM, Poul-Henning Kamp wrote:

> In message  
> <33afbbe70709191024l5c935f7fi11c6f2d9c06b55f1 at mail.gmail.com>, "Cale
> b Anthony" writes:
>> Hello,
>>
>> It doesn't appear that VCL supports case insensitive regular
>> expressions. Is this true?
>
> Yes because I didn't think of that.


Hmm... won't this potentially mess up support for multiple hostnames/ 
backends?  Using the example from the man page:

          if (req.http.host ~ "^(www.)?example.com$") {
              set req.backend = www;
          }

I assumed this would match example.com and Example.com.  Is this not  
the case?

Ric





From phk at phk.freebsd.dk  Thu Sep 20 06:27:22 2007
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Thu, 20 Sep 2007 06:27:22 +0000
Subject: Case Insensitive Regular Expressions 
In-Reply-To: Your message of "Wed, 19 Sep 2007 20:08:56 MST."
	<52EBF0BB-B6EB-4937-AB9A-7ACCE3D08EF0@digitalmarbles.com> 
Message-ID: <20255.1190269642@critter.freebsd.dk>

In message <52EBF0BB-B6EB-4937-AB9A-7ACCE3D08EF0 at digitalmarbles.com>, Ricardo N
ewbery writes:
>
>On Sep 19, 2007, at 10:35 AM, Poul-Henning Kamp wrote:
>
>> In message  
>> <33afbbe70709191024l5c935f7fi11c6f2d9c06b55f1 at mail.gmail.com>, "Cale
>> b Anthony" writes:
>>> Hello,
>>>
>>> It doesn't appear that VCL supports case insensitive regular
>>> expressions. Is this true?
>>
>> Yes because I didn't think of that.
>
>
>Hmm... won't this potentially mess up support for multiple hostnames/ 
>backends?  Using the example from the man page:
>
>          if (req.http.host ~ "^(www.)?example.com$") {
>              set req.backend = www;
>          }
>
>I assumed this would match example.com and Example.com.  Is this not  
>the case?

Now it is, I just changed regexp's to be case insensitive.

-- 
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.


From phk at phk.freebsd.dk  Thu Sep 20 06:30:34 2007
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Thu, 20 Sep 2007 06:30:34 +0000
Subject: Varnish memory leak? 
In-Reply-To: Your message of "Tue, 18 Sep 2007 16:04:58 MST."
	<0A3A6EA86530E64EA3BEA603EC4401CAF07B20@dexbe014-8.exch014.msoutlookonline.net>
Message-ID: <20304.1190269834@critter.freebsd.dk>

In message <0A3A6EA86530E64EA3BEA603EC4401CAF07B20 at dexbe014-8.exch014.msoutlookonline.net>, "Andrew Knapp" writes:

>I'm running Varnish 1.1.1 on Centos 5 x86_64. varnishd has been running
>for about 20 days, but now the machine is using about 100% of the CPU,
>and most of it is in iowait because 100% of the swap is being used by
>varnishd (this is happening on about 8 different cache servers). 

As far as I can see, you have just cached more stuff than your RAM will
take and now the VM system moves stuff in and out of the paging area.

-- 
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.


From phk at phk.freebsd.dk  Thu Sep 20 08:47:50 2007
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Thu, 20 Sep 2007 08:47:50 +0000
Subject: Varnish hangs/delays on backend connections
Message-ID: <29689.1190278070@critter.freebsd.dk>


Can those of you who have seen hangs/timeouts/delays on backend connections
please test if -trunk @1968 fixes this issue ?

-- 
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.


From duja at torlen.net  Thu Sep 20 08:58:40 2007
From: duja at torlen.net (Erik)
Date: Thu, 20 Sep 2007 10:58:40 +0200
Subject: varnishstat vs. telnet stats
Message-ID: <u5d5cfkvxtu7ern.200920071058@server2k3>

Doesn't anyone have a clue what's wrong with the varnish installation?
I'm using Debian Etch and varnish is installed from the debian package on sourceforge.
 
The only thing that I have changed is the backen in the vcl file.
 
Regards
Erik



From peter.oomen at gmail.com  Thu Sep 20 09:25:04 2007
From: peter.oomen at gmail.com (Peter Oomen)
Date: Thu, 20 Sep 2007 11:25:04 +0200
Subject: varnishstat vs. telnet stats
In-Reply-To: <u5d5cfkvxtu7ern.200920071058@server2k3>
References: <u5d5cfkvxtu7ern.200920071058@server2k3>
Message-ID: <480b36850709200225r7f20091dg1b01ff4d4b6f9a12@mail.gmail.com>

I used

http://varnish.projects.linpro.no/wiki/InstallationOnUbuntuDapper

build-essentials should be build-essential

On 9/20/07, Erik <duja at torlen.net> wrote:
> Doesn't anyone have a clue what's wrong with the varnish installation?
> I'm using Debian Etch and varnish is installed from the debian package on sourceforge.
>
> The only thing that I have changed is the backen in the vcl file.
>
> Regards
> Erik
>
> _______________________________________________
> varnish-misc mailing list
> varnish-misc at projects.linpro.no
> http://projects.linpro.no/mailman/listinfo/varnish-misc
>


From des at linpro.no  Thu Sep 20 11:56:22 2007
From: des at linpro.no (=?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?=)
Date: Thu, 20 Sep 2007 13:56:22 +0200
Subject: 1.1.2 delayed
Message-ID: <ujrfy19sg7t.fsf@false.linpro.no>

I came back from Denmark with a severe cold, and I still haven't
finished merging and documenting changes to 1.1.2, so I'm going to
have to delay the release until Monday.

DES
-- 
Dag-Erling Sm?rgrav
Senior Software Developer
Linpro AS - www.linpro.no


From duja at torlen.net  Thu Sep 20 13:50:35 2007
From: duja at torlen.net (Erik)
Date: Thu, 20 Sep 2007 15:50:35 +0200
Subject: varnishstat vs. telnet stats
Message-ID: <wvs0ck1pqx1thz1.200920071550@server2k3>

Thank you very much. It is up n running ;)

A few question about the cache tho.

The stats are saying that it has fetched like 40 items and have had about 650 cache hits. Is this enough to tell if the cache is running, I mean, "cache hits"? that must mean that its serving from the cache?

// Erik



From gojomo at archive.org  Fri Sep 21 00:16:38 2007
From: gojomo at archive.org (Gordon Mohr)
Date: Thu, 20 Sep 2007 17:16:38 -0700
Subject: Cache replacement/eviction policy?
Message-ID: <46F30D66.8070700@archive.org>

When all available cache space is used, and requests for new resources 
arrive, does Varnish discard older objects to make space for new? Is its 
policy for doing so configurable?

Thanks for any details/pointers,

- Gordon @ IA


From duja at torlen.net  Fri Sep 21 08:04:14 2007
From: duja at torlen.net (Erik)
Date: Fri, 21 Sep 2007 10:04:14 +0200
Subject: varnishstat vs. telnet stats
Message-ID: <6s3fht8p6as33by.210920071004@server2k3>

Ok. Thanks for all your help mate ;)

Erik

> yes, cache hits mean hits from the cache..
>
>



From mike at crusaders.no  Fri Sep 21 08:05:55 2007
From: mike at crusaders.no (Trond Michelsen)
Date: Fri, 21 Sep 2007 10:05:55 +0200
Subject: Description of varnishstat-items
Message-ID: <20070921080551.GB22366@crusaders.no>

Hi. 

We're trying to understand some of the numbers from varnishstat. 

In particular, we're wondering when:
   Client connections accepted
   Client requests received
are increased.

Are they increased when the connection is accepted and when the
request is received, or will Varnish wait until the request is
handled?

The reason I ask, is that we have some backends that are unable to
handle the traffic if there are a lot of cache misses. This will
result in a lot of hanging requests. At the moment, we're rejecting
all the requests to these backends. However, if we turn it back on,
connections and requests decreases to less than 1/5 of what it was
before. 

So basically, I'm wondering if this indicates that there's a
congestion in our network, or if it's just a natural consequence of
the requests taking longer to handle?



-- 
Trond Michelsen


From phk at phk.freebsd.dk  Fri Sep 21 08:22:12 2007
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Fri, 21 Sep 2007 08:22:12 +0000
Subject: Description of varnishstat-items 
In-Reply-To: Your message of "Fri, 21 Sep 2007 10:05:55 +0200."
	<20070921080551.GB22366@crusaders.no> 
Message-ID: <6718.1190362932@critter.freebsd.dk>

In message <20070921080551.GB22366 at crusaders.no>, Trond Michelsen writes:

>In particular, we're wondering when:
>   Client connections accepted

	This is increased when we have accepted the connection.
	On systems with accept-filters this does usually not happen
	until we have also received the first request.

>   Client requests received

	This is increased whenever we have complete request and starts
	to service it.

>The reason I ask, is that we have some backends that are unable to
>handle the traffic if there are a lot of cache misses. This will
>result in a lot of hanging requests. At the moment, we're rejecting
>all the requests to these backends. However, if we turn it back on,
>connections and requests decreases to less than 1/5 of what it was
>before. 
>
>So basically, I'm wondering if this indicates that there's a
>congestion in our network, or if it's just a natural consequence of
>the requests taking longer to handle?

I'm not sure I can answer that based on the information you have
provided...



-- 
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.


From jan at garefelt.se  Fri Sep 21 08:45:00 2007
From: jan at garefelt.se (Jan Garefelt)
Date: Fri, 21 Sep 2007 10:45:00 +0200
Subject: Varnish as http/failover?
Message-ID: <46F3848C.4040706@garefelt.se>

Hi!

I've heard good things about varnish as a reverse proxy.

What I'd like to know is whether it is a good idea to use varnish as a
http failover, but I can't seem to find any documentation to determine
whether this is best practise or even possible.

Is varnish a good thing to use as a http/failover, or would you
recommend something else?


Regards /Jan Garefelt



From phk at phk.freebsd.dk  Fri Sep 21 10:18:54 2007
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Fri, 21 Sep 2007 10:18:54 +0000
Subject: Varnish mini status...
Message-ID: <12057.1190369934@critter.freebsd.dk>


This is just an update to all our patient (and in some cases less
patient :-) users out there.

I'm back on Varnish now, after having spent a week on EuroBSDcon2007
and I thought it would be a good idea to outline what is going to happen
from now on.

The two big things are ESI:include, which we have promised our sponsors
will be finished Real Soon Now, and bugfixes.

Since the ESI:include stuff will be pretty drastic, seen from a
source-code point of view, I want to make sure we have a usable
-trunk version before I pull it apart again.

With respect to bugs, here is a little taxonomy:

    "functional" or "Varnish does something wrong"

	These are usually easy to reproduce and quick to fix, once
	we know them.  I will hit these right away once I can see what
	is going on.

    "stability" or "Varnish crashes after some time"

	Some of these will, upon examination, transpire to be in the
	"functional" category, but digging the evidence out of the
	logfiles to find this out can take considerable time.

	The remainder are often very time consuming to nail down
	because they are hard to reproduce.

	I keep looking for new clues to what might be causing these
	and as I work the source code for different purposes I look
	out for things that could be causing problems.  (memory
	leaks etc).

	However, there is little point in sorting the entire haystack,
	hoping to find a needle, given that I'm not even sure if it
	is a needle I'm looking for, so it is not productive to spend
	my full attention on these, until some kind of clue appears.

	I know it is frustrating to you to have a known bug of this
	class, but trust me, I am trying to nail it.

    "nice to have" or "I wish varnish could do this"

	Some of these are simple and will happen right away, others
	are complex and will be put in the ever-expanding wish-list
	and some are so big that we need sponsors to get through them.


About the <ESI:include> stuff.  One of the things which will fall out
of this is the ability to prefetch, it's essentially the same code
that will be needed and it is my plan to implement this first.

After that, there is a pretty major shift in memory allocation, because
we need to be able to "stack" requests on a session to implement the
nesting of <ESI:include> because the included document can also contain
an <ESI:include>, and so on.

-- 
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.


From trondmm-varnish at crusaders.no  Fri Sep 21 11:27:59 2007
From: trondmm-varnish at crusaders.no (Trond Michelsen)
Date: Fri, 21 Sep 2007 13:27:59 +0200
Subject: Description of varnishstat-items
In-Reply-To: <6718.1190362932@critter.freebsd.dk>
References: <20070921080551.GB22366@crusaders.no>
	<6718.1190362932@critter.freebsd.dk>
Message-ID: <20070921112759.GC22366@crusaders.no>

On Fri, Sep 21, 2007 at 08:22:12AM +0000, Poul-Henning Kamp wrote:
> In message <20070921080551.GB22366 at crusaders.no>, Trond Michelsen writes:
>>In particular, we're wondering when:
>>   Client connections accepted
>
>	This is increased when we have accepted the connection.
>	On systems with accept-filters this does usually not happen
>	until we have also received the first request.
>
>>   Client requests received
>
>	This is increased whenever we have complete request and starts
>	to service it.

Thank you. That's pretty much what we expected.

>>The reason I ask, is that we have some backends that are unable to
>>handle the traffic if there are a lot of cache misses. This will
>>result in a lot of hanging requests. At the moment, we're rejecting
>>all the requests to these backends. However, if we turn it back on,
>>connections and requests decreases to less than 1/5 of what it was
>>before. 

>> So basically, I'm wondering if this indicates that there's a
>> congestion in our network, or if it's just a natural consequence of
>> the requests taking longer to handle?
> I'm not sure I can answer that based on the information you have
> provided...

Yeah, I know I'm a bit vague here. Sorry about that. Here's a quick
overview of our setup:

We have two Varnish mashines. Varnish1 is a frontend for a webservice
that generates images. Varnish2 is a frontent for a webservice that
generates XML-content. These services runs on separate servers. The
Webserver fetches XML-data from Varnish2 to generate HTML-pages, which
contains links to the images that are served by Varnish1. So,
basically all traffic to Varnish2 comes from a single machine, while
the traffic to Varnish1 comes from "everyone".

The Webserver is located offsite. With a single FTP-connection, we get
a transfer rate of 250-300Mbps between the webserver and
Varnish2. Both varnish1 and 2 have a gigabit-connection to NIX. Both
Varnish machines are 2xdual-core Xeon servers with 8GB memory.

The backends for Varnish1 and 2 have NFS-mounted disks from the same
NFS-server. 

Right now, we have added a rule to Varnish1, that will reject any
request for the images that are most time consuming to generate for
the backends. Whenever we remove this restriction, and allow all
requests to go through to the backend - the number of incoming
requests to Varnish1 decreases dramatically. This isn't necessarily
surprising, since the clients will have to wait for the first images
to come through before requesting the next.

The thing that does surprise us is that whenever we try to allow all
images from Varnish1, after about 30s the webserver becomes unable to
connect to Varnish2. Connects from the webserver to Varnish2 piles up,
and without the XML-data, it cannot generate any webpages at all.

So far we have not been able to determine if Varnish2 is refusing
connections, or if the connections never get to the varnish-machines
at all.

-- 
Trond Michelsen


From optilude at gmx.net  Fri Sep 21 18:15:19 2007
From: optilude at gmx.net (Martin Aspeli)
Date: Fri, 21 Sep 2007 19:15:19 +0100
Subject: Varnish hangs/delays on backend connections
In-Reply-To: <29689.1190278070@critter.freebsd.dk>
References: <29689.1190278070@critter.freebsd.dk>
Message-ID: <fd11ok$gpm$1@sea.gmane.org>

Poul-Henning Kamp wrote:
> Can those of you who have seen hangs/timeouts/delays on backend connections
> please test if -trunk @1968 fixes this issue ?

Ooooh! I just tried this with my Plone site that I've previously 
mentioned, where Varnish 1.1.1 was basically useless. I've only been 
using it for ten minutes, but it does seem to be reliable and I can't 
reproduce the earlier problems. I'm very happy with this!

Do you know which release this fix would make it into? 1.1.2? 2.0?

By way of background: Varnish is rapidly becoming the weapon of choice 
for many Plone deployments, since (a) it's much easier to grasp than 
Squid and (b) Plone needs a cache server in front of it. Hopefully, this 
will reflect positively on Varnish in terms of increased uptake.

Unfortunately, this fix is already too late for my book[1] which has 
gone "gold" past couple of days. I had hoped to show how to set up 
Varnish 1.1.1, but decided it was too risky since I couldn't make it 
work reliably on my own site. Thus, I suggested that readers use 1.0.4 
but look out for an updated version of the 1.1 series. If we get a 
release that I can make work reliably, I will try to issue some errata 
to suggest people use that version instead (since 1.1+ has features, 
notably Vary support, that are quite useful for Plone sites).

Cheers,
Martin

[1] http://www.packtpub.com/Professional-Plone-web-applications-CMS/book


-- 
Acquisition is a jealous mistress



From max.goldberg at gmail.com  Sun Sep 23 20:29:24 2007
From: max.goldberg at gmail.com (max goldberg)
Date: Sun, 23 Sep 2007 16:29:24 -0400
Subject: Possible to keep a single cache item for multiple request URLs using
	external logic?
Message-ID: <87e6ded30709231329s5b4bf614g8446a511d86d05a0@mail.gmail.com>

Hello All,

I'm designing a sort of distributed file system used for file serving and
have been looking at multiple methods of reverse proxy caching static
content and I have to say Varnish looks like a really great product.

I have some questions as to how I can incorporate Varnish into my setup in
the most optimal way.

In the current implementation, I have multiple sites using the same content
system on the back end, using CNAME'd domains and a layer of application
logic to decide how to serve the file. In the file system, files are
completely unique in that even if a file exists across multiple sites, it
can be referred to in many ways while only being stored once.

For instance:
-----
app1.example.com is a CNAME for content.example.com
app2.example.com is a CNAME for content.example.com
etc.

A request comes in for http://app1.example.com/image.jpg.

content.example.com examines the request and responds with:

Location: http://server10.content.example.com/storage/real_image_name.jpg

Another request comes in for http://app2.example.com/test.jpg which
content.example.com identifies as being the same file as real_image_name.jpg
and responds with an identical Location header.
-----

I'm trying to keep my path translation in logic that would be external from
Varnish, as in some cases it's more extensive than a regular expression. The
whole ordeal can be an expensive process which is where caching comes in.

So is there some method of hosting the same file in multiple places while
only having to cache the file once inside Varnish using an external
application to decide what the ultimate URL is?
Does Varnish follow Location headers? Or is there some method of redirecting
Varnish to the end location of a file?

If these are features that are not currently available, can anyone point me
to any past discussions about similar setups or give me a heads up if it's
even something Varnish ever plans on doing?

This would be less of an issue if this didn't happen so often in the way I'm
using the back end file system. but as it is, it happens quite a bit and in
a straight URL to cache item configuration causes me to waste a lot of disk
space/memory/IO performance.


Thanks in advance,
-Max
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20070923/d9236049/attachment.html>

From Samuel.Martin at ac-nantes.fr  Mon Sep 24 15:57:58 2007
From: Samuel.Martin at ac-nantes.fr (Samuel.Martin at ac-nantes.fr)
Date: Mon, 24 Sep 2007 17:57:58 +0200
Subject: apache+zope+varnish
Message-ID: <e951c7391b56e90d.46f7faa6@ac-nantes.fr>

Hi,

My configuration :
I've a apache server with the mod proxy activated listening in the port 80 and redirect to 9080 where my plone site listen.

And i know that varnish is the best solution to cache
How integrated varnish in this achitecture ? (What port must listen varnish in my architecture? How specify to apache to cache with varnish? ...)

I begin to install varnish with the source but i've some problem to understand how implemented all this technologies (i'm french and ...)

Thanks for your answer
(i've read architect note and i'm beginning to read the man and other doc but au user guide will be so useful)
long life to varnish it will be a standard...




From ric at digitalmarbles.com  Mon Sep 24 18:49:44 2007
From: ric at digitalmarbles.com (Ricardo Newbery)
Date: Mon, 24 Sep 2007 11:49:44 -0700
Subject: apache+zope+varnish
In-Reply-To: <e951c7391b56e90d.46f7faa6@ac-nantes.fr>
References: <e951c7391b56e90d.46f7faa6@ac-nantes.fr>
Message-ID: <FD6AC1E7-D56C-4F86-8654-E23816D6DCA5@digitalmarbles.com>


On Sep 24, 2007, at 8:57 AM, <Samuel.Martin at ac-nantes.fr> wrote:

> Hi,
>
> My configuration :
> I've a apache server with the mod proxy activated listening in the  
> port 80 and redirect to 9080 where my plone site listen.
>
> And i know that varnish is the best solution to cache
> How integrated varnish in this achitecture ? (What port must listen  
> varnish in my architecture? How specify to apache to cache with  
> varnish? ...)
>
> I begin to install varnish with the source but i've some problem to  
> understand how implemented all this technologies (i'm french and ...)
>
> Thanks for your answer
> (i've read architect note and i'm beginning to read the man and  
> other doc but au user guide will be so useful)
> long life to varnish it will be a standard...


If you're using Plone, I suggest looking at CacheFu (http://plone.org/ 
products/cachefu).  Even if you're not using Plone, CacheFu generates  
some beta Varnish configs that might be useful as a reference.

Another one to look at is plone.recipe.varnish (http:// 
pypi.python.org/pypi/plone.recipe.varnish), which despite the name is  
NOT specific to Plone.

Ric




From jean-marc.pouchoulon at ac-montpellier.fr  Mon Sep 24 19:18:39 2007
From: jean-marc.pouchoulon at ac-montpellier.fr (jean-marc pouchoulon)
Date: Mon, 24 Sep 2007 21:18:39 +0200
Subject: apache+zope+varnish
In-Reply-To: <FD6AC1E7-D56C-4F86-8654-E23816D6DCA5@digitalmarbles.com>
References: <e951c7391b56e90d.46f7faa6@ac-nantes.fr>
	<FD6AC1E7-D56C-4F86-8654-E23816D6DCA5@digitalmarbles.com>
Message-ID: <46F80D8F.4010206@ac-montpellier.fr>


bonjour,
>>
>>
>> And i know that varnish is the best solution to cache
>> How integrated varnish in this achitecture ? (What port must listen  
>> varnish in my architecture? How specify to apache to cache with  
>> varnish? ...)
>>
>>     
put varnish in front of apache
apache don't have to cache anything just using it to load balance to zeo 
client

>> I begin to install varnish with the source but i've some problem to  
>> understand how implemented all this technologies (i'm french and ...)
>>
>>     
I'm french too.... and working for the the same big entity ( :-D ) 
...and we use varnish with zope/cps.
I did some slides on varnish and had presented them to other systems 
administrators in June. If you want them and our config you can contact me.

Jean-marc Pouchoulon
Rectorat de Montpellier






From ric at digitalmarbles.com  Mon Sep 24 22:44:43 2007
From: ric at digitalmarbles.com (Ricardo Newbery)
Date: Mon, 24 Sep 2007 15:44:43 -0700
Subject: apache+zope+varnish
In-Reply-To: <46F80D8F.4010206@ac-montpellier.fr>
References: <e951c7391b56e90d.46f7faa6@ac-nantes.fr>
	<FD6AC1E7-D56C-4F86-8654-E23816D6DCA5@digitalmarbles.com>
	<46F80D8F.4010206@ac-montpellier.fr>
Message-ID: <AC8B979D-31AD-4DF9-A2A2-AB074AC06116@digitalmarbles.com>


On Sep 24, 2007, at 12:18 PM, jean-marc pouchoulon wrote:

>
> bonjour,
>>>
>>>
>>> And i know that varnish is the best solution to cache
>>> How integrated varnish in this achitecture ? (What port must listen
>>> varnish in my architecture? How specify to apache to cache with
>>> varnish? ...)
>>>
>>>
> put varnish in front of apache
> apache don't have to cache anything just using it to load balance  
> to zeo
> client
>
>>> I begin to install varnish with the source but i've some problem to
>>> understand how implemented all this technologies (i'm french  
>>> and ...)
>>>
>>>
> I'm french too.... and working for the the same big entity ( :-D )
> ...and we use varnish with zope/cps.
> I did some slides on varnish and had presented them to other systems
> administrators in June. If you want them and our config you can  
> contact me.
>
> Jean-marc Pouchoulon
> Rectorat de Montpellier


Use-cases differ of course, but I'm partial to the other way around.   
Put Apache in front of Varnish and Varnish in front of Zope.  And if  
you need load balancing, insert something like Pound between Varnish  
and the Zeo clients (although there is some work in Varnish trunk to  
add load balancing).  This configuration frees up Apache to serve  
other stuff besides the Varnish cached content.

Ric




From jan at garefelt.se  Thu Sep 20 14:52:57 2007
From: jan at garefelt.se (Jan Garefelt)
Date: Thu, 20 Sep 2007 16:52:57 +0200
Subject: varnish as http/failover?
Message-ID: <46F28949.3080200@garefelt.se>

Hi!

I've heard good things about varnish as a reverse proxy.

What I'd like to know is whether it is a good idea to use varnish as a
http failover, but I can't seem to find any documentation to determine
whether this is best practise or even possible.

Is varnish a good thing to use as a http/failover, or would you
recommend something else?


Regards /Jan Garefelt


From jean-marc.pouchoulon at ac-montpellier.fr  Tue Sep 25 06:20:37 2007
From: jean-marc.pouchoulon at ac-montpellier.fr (jean-marc pouchoulon)
Date: Tue, 25 Sep 2007 08:20:37 +0200
Subject: apache+zope+varnish
In-Reply-To: <AC8B979D-31AD-4DF9-A2A2-AB074AC06116@digitalmarbles.com>
References: <e951c7391b56e90d.46f7faa6@ac-nantes.fr>
	<FD6AC1E7-D56C-4F86-8654-E23816D6DCA5@digitalmarbles.com>
	<46F80D8F.4010206@ac-montpellier.fr>
	<AC8B979D-31AD-4DF9-A2A2-AB074AC06116@digitalmarbles.com>
Message-ID: <46F8A8B5.50402@ac-montpellier.fr>


>
> Use-cases differ of course, but I'm partial to the other way around.  
> Put Apache in front of Varnish and Varnish in front of Zope.  And if 
> you need load balancing, insert something like Pound between Varnish 
> and the Zeo clients (although there is some work in Varnish trunk to 
> add load balancing).  This configuration frees up Apache to serve 
> other stuff besides the Varnish cached content.
>
IMHO apache perf cannot rivalize with varnish , that's why I put them  
behind varnish. We have differents applications (differents apache) and 
varnish regex are sufficient to switch the traffic.
Apache 2.2 (load balancing + mod_rewrite) is used to do load balancing 
on ZEO .In our case there are also hardware compression and load 
balancing in front of varnish.

but "Use-cases differ of course" and there are many good solutions and  
I am not using plone

jean-marc


> Ric
>
>



From des at linpro.no  Tue Sep 25 07:48:00 2007
From: des at linpro.no (=?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?=)
Date: Tue, 25 Sep 2007 09:48:00 +0200
Subject: 1.1.2 delayed
In-Reply-To: <ujrfy19sg7t.fsf@false.linpro.no> (Dag-Erling
	=?iso-8859-1?Q?Sm=F8rgrav's?= message
	of "Thu, 20 Sep 2007 13:56:22 +0200")
References: <ujrfy19sg7t.fsf@false.linpro.no>
Message-ID: <ujrsl53mbin.fsf@false.linpro.no>

Dag-Erling Sm?rgrav <des at linpro.no> writes:
> I came back from Denmark with a severe cold, and I still haven't
> finished merging and documenting changes to 1.1.2, so I'm going to
> have to delay the release until Monday.

I got a lot of stuff done during the weekend, but my cold turned into
bronchitis.  I'm afraid 1.1.2 will have to wait until I get better (or
I kick the bucket and somebody else takes over...)

DES
-- 
Dag-Erling Sm?rgrav
Senior Software Developer
Linpro AS - www.linpro.no


From ric at digitalmarbles.com  Tue Sep 25 07:54:13 2007
From: ric at digitalmarbles.com (Ricardo Newbery)
Date: Tue, 25 Sep 2007 00:54:13 -0700
Subject: apache+zope+varnish
In-Reply-To: <46F8A8B5.50402@ac-montpellier.fr>
References: <e951c7391b56e90d.46f7faa6@ac-nantes.fr>
	<FD6AC1E7-D56C-4F86-8654-E23816D6DCA5@digitalmarbles.com>
	<46F80D8F.4010206@ac-montpellier.fr>
	<AC8B979D-31AD-4DF9-A2A2-AB074AC06116@digitalmarbles.com>
	<46F8A8B5.50402@ac-montpellier.fr>
Message-ID: <8BC5F890-57AB-414C-A686-393D6FEB3BE8@digitalmarbles.com>


On Sep 24, 2007, at 11:20 PM, jean-marc pouchoulon wrote:

>> Use-cases differ of course, but I'm partial to the other way  
>> around.  Put Apache in front of Varnish and Varnish in front of  
>> Zope.  And if you need load balancing, insert something like Pound  
>> between Varnish and the Zeo clients (although there is some work  
>> in Varnish trunk to add load balancing).  This configuration frees  
>> up Apache to serve other stuff besides the Varnish cached content.
>>
> IMHO apache perf cannot rivalize with varnish , that's why I put  
> them  behind varnish. We have differents applications (differents  
> apache) and varnish regex are sufficient to switch the traffic.
> Apache 2.2 (load balancing + mod_rewrite) is used to do load  
> balancing on ZEO .In our case there are also hardware compression  
> and load balancing in front of varnish.
>
> but "Use-cases differ of course" and there are many good solutions  
> and  I am not using plone


Note, this configuration has nothing to do with whether one is using  
Plone.  :-)

Varnish is good as a proxy in front of *slow* backends generating  
dynamic content, but I suspect it's probably of marginal benefit as a  
proxy to serve static content and possibly even when serving *fast*  
dynamic content.

I'm curious about the claim about Apache performance in comparison to  
Varnish.  Is Varnish serving from cache really that much faster than  
Apache serving static files?  I suppose an argument can be made that  
Apache-in-front-of-Varnish might add an extra delay compared to  
Varnish serving from cache directly.  I wonder if this delay is  
significant.  Anyone have any benchmarks?

Ric




From des at linpro.no  Tue Sep 25 08:07:03 2007
From: des at linpro.no (=?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?=)
Date: Tue, 25 Sep 2007 10:07:03 +0200
Subject: apache+zope+varnish
In-Reply-To: <8BC5F890-57AB-414C-A686-393D6FEB3BE8@digitalmarbles.com>
	(Ricardo Newbery's message of "Tue, 25 Sep 2007 00:54:13 -0700")
References: <e951c7391b56e90d.46f7faa6@ac-nantes.fr>
	<FD6AC1E7-D56C-4F86-8654-E23816D6DCA5@digitalmarbles.com>
	<46F80D8F.4010206@ac-montpellier.fr>
	<AC8B979D-31AD-4DF9-A2A2-AB074AC06116@digitalmarbles.com>
	<46F8A8B5.50402@ac-montpellier.fr>
	<8BC5F890-57AB-414C-A686-393D6FEB3BE8@digitalmarbles.com>
Message-ID: <ujrhcljmamw.fsf@false.linpro.no>

Ricardo Newbery <ric at digitalmarbles.com> writes:
> Varnish is good as a proxy in front of *slow* backends generating
> dynamic content, but I suspect it's probably of marginal benefit as
> a proxy to serve static content and possibly even when serving
> *fast* dynamic content.

You're wrong.  Varnish improves performance even for static content
and fast dynamic content.  Varnish serves requests from memory, and
doesn't spend valuable time writing logs.

> I'm curious about the claim about Apache performance in comparison
> to Varnish.  Is Varnish serving from cache really that much faster
> than Apache serving static files?

Yes, as long as your client isn't apachebench.

DES
-- 
Dag-Erling Sm?rgrav
Senior Software Developer
Linpro AS - www.linpro.no


From ric at digitalmarbles.com  Tue Sep 25 08:52:59 2007
From: ric at digitalmarbles.com (Ricardo Newbery)
Date: Tue, 25 Sep 2007 01:52:59 -0700
Subject: apache+zope+varnish
In-Reply-To: <ujrhcljmamw.fsf@false.linpro.no>
References: <e951c7391b56e90d.46f7faa6@ac-nantes.fr>
	<FD6AC1E7-D56C-4F86-8654-E23816D6DCA5@digitalmarbles.com>
	<46F80D8F.4010206@ac-montpellier.fr>
	<AC8B979D-31AD-4DF9-A2A2-AB074AC06116@digitalmarbles.com>
	<46F8A8B5.50402@ac-montpellier.fr>
	<8BC5F890-57AB-414C-A686-393D6FEB3BE8@digitalmarbles.com>
	<ujrhcljmamw.fsf@false.linpro.no>
Message-ID: <5DBF87A5-4EC1-4CF1-B3A1-75552C20A1D7@digitalmarbles.com>


On Sep 25, 2007, at 1:07 AM, Dag-Erling Sm?rgrav wrote:

> Ricardo Newbery <ric at digitalmarbles.com> writes:
>> Varnish is good as a proxy in front of *slow* backends generating
>> dynamic content, but I suspect it's probably of marginal benefit as
>> a proxy to serve static content and possibly even when serving
>> *fast* dynamic content.
>
> You're wrong.  Varnish improves performance even for static content
> and fast dynamic content.  Varnish serves requests from memory, and
> doesn't spend valuable time writing logs.


If you don't need logs, it just as easy to turn this off in Apache.



>> I'm curious about the claim about Apache performance in comparison
>> to Varnish.  Is Varnish serving from cache really that much faster
>> than Apache serving static files?
>
> Yes, as long as your client isn't apachebench.


I'm sure it's faster, but how much faster?  Any benchmarks against a  
performance-optimized Apache?

Performance-tweaking is like security-tweaking.  At a certain point,  
it's just a black hole you can throw more money and effort into and  
get marginal returns.  And increasing performance (as in increasing  
security) often means sacrificing some power or flexibility  
elsewhere.  For some use-cases, the marginal returns and decreased  
flexibility are worth the effort.  For many, I suspect it's probably  
not.  In any case, it's better to make these decisions based on some  
objective measurements.

Ric





From andrew at imeem.com  Tue Sep 25 22:08:02 2007
From: andrew at imeem.com (Andrew Knapp)
Date: Tue, 25 Sep 2007 15:08:02 -0700
Subject: Varnish memory leak? 
In-Reply-To: <20304.1190269834@critter.freebsd.dk>
References: Your message of "Tue, 18 Sep 2007 16:04:58 MST."
	<0A3A6EA86530E64EA3BEA603EC4401CAF07B20@dexbe014-8.exch014.msoutlookonline.net>
	<20304.1190269834@critter.freebsd.dk>
Message-ID: <0A3A6EA86530E64EA3BEA603EC4401CAFAFA05@dexbe014-8.exch014.msoutlookonline.net>

> -----Original Message-----
> From: phk at critter.freebsd.dk [mailto:phk at critter.freebsd.dk] On Behalf
> Of Poul-Henning Kamp
> Sent: Wednesday, September 19, 2007 11:31 PM
> To: Andrew Knapp
> Cc: varnish-misc at projects.linpro.no
> Subject: Re: Varnish memory leak?
> 
> In message <0A3A6EA86530E64EA3BEA603EC4401CAF07B20 at dexbe014-
> 8.exch014.msoutlookonline.net>, "Andrew Knapp" writes:
> 
> >I'm running Varnish 1.1.1 on Centos 5 x86_64. varnishd has been
> running
> >for about 20 days, but now the machine is using about 100% of the
CPU,
> >and most of it is in iowait because 100% of the swap is being used by
> >varnishd (this is happening on about 8 different cache servers).
> 
> As far as I can see, you have just cached more stuff than your RAM
will
> take and now the VM system moves stuff in and out of the paging area.
> 

I guess I don't understand this. These servers have 8GB of RAM in them,
so why doesn't it fill up then RAM and then move onto filling up the
disk storage, instead of swap space?

-Andy


From optilude at gmx.net  Tue Sep 25 23:22:39 2007
From: optilude at gmx.net (Martin Aspeli)
Date: Wed, 26 Sep 2007 00:22:39 +0100
Subject: Error compiling VCL with trunk (r2043)
Message-ID: <fdc596$nfn$1@sea.gmane.org>

Hi,

This may be a known issue (couldn't find anything in trac), but with the 
VCL pasted below and trunk as of right now (r2043), I get this error 
trying to start Varnish:

System error:
C-compiler command complained.
Command attempted: exec /bin/sh -c "exec cc -nostdinc -fpic -shared 
-Wl,-x -o ./bin.XXo1HaX1 -x c - < ./vcl.XXo1HaX1" 2>&1
Message:
<stdin>: In function `VGC_Init':
<stdin>:906: warning: passing arg 1 of `VRT_acl_init' discards 
qualifiers from pointer target type
<stdin>: In function `VGC_Fini':
<stdin>:917: warning: passing arg 1 of `VRT_acl_fini' discards 
qualifiers from pointer target type

Reverting to r1979 (for no reason other than that this worked for me 
previously) makes it work again.

The VCL:

backend backend_0 {
     set backend.host = "127.0.0.1";
     set backend.port = "8000";
}



acl purge {
     "localhost";
}

sub vcl_recv {


     if (req.request == "PURGE") {
         if (!client.ip ~ purge) {
                 error 405 "Not allowed.";
         }
         lookup;
     }

     if (req.request != "GET" && req.request != "HEAD") {
         pipe;
     }

     if (req.http.Expect) {
         pipe;
     }

     if (req.http.If-None-Match) {
         pass;
     }

     /* Do not cache other authorised content */
     if (req.http.Authenticate || req.http.Authorization) {
         pass;
     }

     /* We only care about the "__ac.*" cookies, used for authentication */
     if (req.http.Cookie && (req.http.Cookie ~ 
"__ac(_(name|password|persistent))?=" || req.http.Cookie ~ "_ZopeId")) {
         pass;
     }

     lookup;
}

/* Deal with purge requests */
sub vcl_hit {
     if (req.request == "PURGE") {
             set obj.ttl = 0s;
             error 200 "Purged";
     }
}

sub vcl_miss {
     if (req.http.If-Modified-Since) {
         pass;
     }

     if (req.request == "PURGE") {
             error 404 "Not in cache";
     }
}

sub vcl_fetch {
     if (!obj.valid) {
         error;
     }
     if (!obj.cacheable) {
         pass;
     }
     if (obj.http.Set-Cookie) {
         pass;
     }

     if (req.url ~ "(rss_|search_rss)") {
         set obj.ttl = 1800s;
     }
}

sub vcl_hash {
     set req.hash += req.http.Accept-Encoding;
}

-- 
Acquisition is a jealous mistress



From phk at phk.freebsd.dk  Wed Sep 26 19:44:23 2007
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Wed, 26 Sep 2007 19:44:23 +0000
Subject: Error compiling VCL with trunk (r2043) 
In-Reply-To: Your message of "Wed, 26 Sep 2007 00:22:39 +0100."
	<fdc596$nfn$1@sea.gmane.org> 
Message-ID: <11382.1190835863@critter.freebsd.dk>

In message <fdc596$nfn$1 at sea.gmane.org>, Martin Aspeli writes:
>Hi,
>
>This may be a known issue (couldn't find anything in trac), but with the 
>VCL pasted below and trunk as of right now (r2043), I get this error 
>trying to start Varnish:

><stdin>:906: warning: passing arg 1 of `VRT_acl_init' discards 

Should be fixed in 2049

-- 
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.


From trondmm-varnish at crusaders.no  Thu Sep 27 10:34:45 2007
From: trondmm-varnish at crusaders.no (Trond Michelsen)
Date: Thu, 27 Sep 2007 12:34:45 +0200
Subject: Truncated URLs in log
Message-ID: <20070927103445.GA5232@crusaders.no>

Hi. Is it possible to configure varnishncsa so that it doesn't
truncate URLs at 256 characters?

-- 
Trond Michelsen


From des at linpro.no  Thu Sep 27 11:16:06 2007
From: des at linpro.no (=?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?=)
Date: Thu, 27 Sep 2007 13:16:06 +0200
Subject: Truncated URLs in log
In-Reply-To: <20070927103445.GA5232@crusaders.no> (Trond Michelsen's message
	of "Thu, 27 Sep 2007 12:34:45 +0200")
References: <20070927103445.GA5232@crusaders.no>
Message-ID: <ujrlkasmk95.fsf@false.linpro.no>

Trond Michelsen <trondmm-varnish at crusaders.no> writes:
> Hi. Is it possible to configure varnishncsa so that it doesn't
> truncate URLs at 256 characters?

The limitation is not in varnishncsa, but in the shared memory log
format.  We use only one byte to store the length of the log record.

DES
-- 
Dag-Erling Sm?rgrav
Senior Software Developer
Linpro AS - www.linpro.no


From des at linpro.no  Thu Sep 27 11:41:30 2007
From: des at linpro.no (=?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?=)
Date: Thu, 27 Sep 2007 13:41:30 +0200
Subject: Truncated URLs in log
In-Reply-To: <ujrlkasmk95.fsf@false.linpro.no> (Dag-Erling
	=?iso-8859-1?Q?Sm=F8rgrav's?= message
	of "Thu, 27 Sep 2007 13:16:06 +0200")
References: <20070927103445.GA5232@crusaders.no>
	<ujrlkasmk95.fsf@false.linpro.no>
Message-ID: <ujrhclgmj2t.fsf@false.linpro.no>

Dag-Erling Sm?rgrav <des at linpro.no> writes:
> Trond Michelsen <trondmm-varnish at crusaders.no> writes:
> > Hi. Is it possible to configure varnishncsa so that it doesn't
> > truncate URLs at 256 characters?
> The limitation is not in varnishncsa, but in the shared memory log
> format.  We use only one byte to store the length of the log record.

The attached patch increases the limit to 65535 characters, but breaks
binary compatibility with old log files.

DES
-- 
Dag-Erling Sm?rgrav
Senior Software Developer
Linpro AS - www.linpro.no


From des at linpro.no  Thu Sep 27 11:42:16 2007
From: des at linpro.no (=?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?=)
Date: Thu, 27 Sep 2007 13:42:16 +0200
Subject: Truncated URLs in log
In-Reply-To: <ujrhclgmj2t.fsf@false.linpro.no> (Dag-Erling
	=?iso-8859-1?Q?Sm=F8rgrav's?= message
	of "Thu, 27 Sep 2007 13:41:30 +0200")
References: <20070927103445.GA5232@crusaders.no>
	<ujrlkasmk95.fsf@false.linpro.no> <ujrhclgmj2t.fsf@false.linpro.no>
Message-ID: <ujrd4w4mj1j.fsf@false.linpro.no>

Dag-Erling Sm?rgrav <des at linpro.no> writes:
> Dag-Erling Sm?rgrav <des at linpro.no> writes:
> > Trond Michelsen <trondmm-varnish at crusaders.no> writes:
> > > Hi. Is it possible to configure varnishncsa so that it doesn't
> > > truncate URLs at 256 characters?
> > The limitation is not in varnishncsa, but in the shared memory log
> > format.  We use only one byte to store the length of the log record.
> The attached patch increases the limit to 65535 characters, but breaks
> binary compatibility with old log files.

Once more, with patch.

DES
-- 
Dag-Erling Sm?rgrav
Senior Software Developer
Linpro AS - www.linpro.no

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: varnish-shmlog-65535.diff
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20070927/22c4e97f/attachment.ksh>

From phk at phk.freebsd.dk  Fri Sep 28 08:36:27 2007
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Fri, 28 Sep 2007 08:36:27 +0000
Subject: Truncated URLs in log 
In-Reply-To: Your message of "Thu, 27 Sep 2007 13:16:06 +0200."
	<ujrlkasmk95.fsf@false.linpro.no> 
Message-ID: <4200.1190968587@critter.freebsd.dk>

In message <ujrlkasmk95.fsf at false.linpro.no>, =?iso-8859-1?Q?Dag-Erling_Sm=F8rg
rav?= writes:
>Trond Michelsen <trondmm-varnish at crusaders.no> writes:
>> Hi. Is it possible to configure varnishncsa so that it doesn't
>> truncate URLs at 256 characters?
>
>The limitation is not in varnishncsa, but in the shared memory log
>format.  We use only one byte to store the length of the log record.

If this is a problem, we should just change the binary shmlog format,
it's not a big issue.

-- 
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.


From trondmm-varnish at crusaders.no  Fri Sep 28 09:32:17 2007
From: trondmm-varnish at crusaders.no (Trond Michelsen)
Date: Fri, 28 Sep 2007 11:32:17 +0200
Subject: Truncated URLs in log
In-Reply-To: <ujrd4w4mj1j.fsf@false.linpro.no>
References: <20070927103445.GA5232@crusaders.no>
	<ujrlkasmk95.fsf@false.linpro.no> <ujrhclgmj2t.fsf@false.linpro.no>
	<ujrd4w4mj1j.fsf@false.linpro.no>
Message-ID: <20070928093217.GB5232@crusaders.no>

On Thu, Sep 27, 2007 at 01:42:16PM +0200, Dag-Erling Sm?rgrav wrote:
> Dag-Erling Sm?rgrav <des at linpro.no> writes:
>> Dag-Erling Sm?rgrav <des at linpro.no> writes:
>>> Trond Michelsen <trondmm-varnish at crusaders.no> writes:
>>>> Hi. Is it possible to configure varnishncsa so that it doesn't
>>>> truncate URLs at 256 characters?
>>> The limitation is not in varnishncsa, but in the shared memory log
>>> format.  We use only one byte to store the length of the log record.
>> The attached patch increases the limit to 65535 characters, but breaks
>> binary compatibility with old log files.
> Once more, with patch.

Thank you. That was quick :)

BTW: Is it too late for this to be included with 1.1.2?

-- 
Trond Michelsen


From des at linpro.no  Fri Sep 28 17:10:08 2007
From: des at linpro.no (=?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?=)
Date: Fri, 28 Sep 2007 19:10:08 +0200
Subject: Truncated URLs in log
In-Reply-To: <20070928093217.GB5232@crusaders.no> (Trond Michelsen's message
	of "Fri, 28 Sep 2007 11:32:17 +0200")
References: <20070927103445.GA5232@crusaders.no>
	<ujrlkasmk95.fsf@false.linpro.no> <ujrhclgmj2t.fsf@false.linpro.no>
	<ujrd4w4mj1j.fsf@false.linpro.no> <20070928093217.GB5232@crusaders.no>
Message-ID: <ujrbqbmzpfz.fsf@false.linpro.no>

Trond Michelsen <trondmm-varnish at crusaders.no> writes:
> BTW: Is it too late for this to be included with 1.1.2?

It breaks binary compatibility.

DES
-- 
Dag-Erling Sm?rgrav
Senior Software Developer
Linpro AS - www.linpro.no


From phk at phk.freebsd.dk  Fri Sep 28 17:21:58 2007
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Fri, 28 Sep 2007 17:21:58 +0000
Subject: Truncated URLs in log 
In-Reply-To: Your message of "Fri, 28 Sep 2007 19:10:08 +0200."
	<ujrbqbmzpfz.fsf@false.linpro.no> 
Message-ID: <34605.1191000118@critter.freebsd.dk>

In message <ujrbqbmzpfz.fsf at false.linpro.no>, =?iso-8859-1?Q?Dag-Erling_Sm=F8rg
rav?= writes:
>Trond Michelsen <trondmm-varnish at crusaders.no> writes:
>> BTW: Is it too late for this to be included with 1.1.2?
>
>It breaks binary compatibility.

I'd argue that it doesn't.

It only breaks compatibility between varnish tools of different versions
(ie: new varnishd old varnishstat)

Given the moderate userbase of Varnish, I hardly consider that important.

-- 
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.