Re: Varnish and sticky sessions

2008-11-13 Thread JT Justman
Torstein Krause Johansen wrote:
> Heya,
> 
> is there a way to get Varnish load balancing (the director) to support 
> sticky sessions?
> 
> Or do I need to put a load balancer behind the Varnish that ensures that 
> a client with a given session always goes to the same backend server?

Never tried it, but it seems to me you could read a cookie in VCL to
determine the backend to use. This is how most load balancers handle
sticky sessions, right?

-- 
[EMAIL PROTECTED]
http://www.endpoint.com
___
varnish-misc mailing list
varnish-misc@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc


Re: ESI works in IE6 & curl, but not in FF, Opera, Konqueror

2008-11-11 Thread JT Justman
Torstein Krause Johansen wrote:
> Good morning,
> 
> Tollef Fog Heen wrote:
>  > | Turning off Apache mod_deflate solves the problem. However, it's
>  > | probably not the "ultimate" solution as I wager the customer wants to
>  > | still use the deflate module. Setting
>  >
>  > There's unfortunately no way to use ESI and gzipped content at the
>  > moment.
> 
> Ok, thanks for the confirmation :-)
> 
> Sorry for asking, but I know many customers will be asking me this: do 
> you have any idea when we could expect support for this?

Torstein -

We have a client who is interested in ESI and also requires gzip (as I
think most would), and we've been working on it on the back burner for a
while. Faster work from us depends on the client's priorities. It's not
a trivial undertaking, but I have at least got to the point of
understanding the ESI request flow enough to guess where the encoding
should probably be performed.

See here for links to two bugs discussing the issue:

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

JT

-- 
[EMAIL PROTECTED]
http://www.endpoint.com
___
varnish-misc mailing list
varnish-misc@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc


Re: TCP_HIT header

2008-11-05 Thread JT Justman
Alecs Henry wrote:
> Hi Per,
> 
> Here's what I got:
> -
> vcl.load test /usr/local/etc/varnish/configs/test.vcl
> 106 267
> *Variable 'obj.http.X-Cache' not accessible in method 'vcl_miss'.*
> At: (/usr/local/etc/varnish/configs/test.vcl Line 62 Pos 13)
> set obj.http.X-Cache = "TCP_MISS from " server.ip;
> --
> VCL compilation failed
> -
> 
> It works just fine for vcl_hit though.
> Any ideas?
> 

'obj' is only available in 'hit' and 'fetch'. So set it in vcl_fetch.
The only side effect being then your header will be set in the case of a
'pass' as well, which may or may not be what you want.

-- 
[EMAIL PROTECTED]
http://www.endpoint.com
___
varnish-misc mailing list
varnish-misc@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc


Re: Varnish 2.01 - GETs with Grinder end up in PASS

2008-11-04 Thread JT Justman
Robert Ming wrote:
> Hi!
> 
> We do load-testing with 'The Grinder' vers. 3.1 on Varnish in front
> of several Plone3 instances. The tests worked out fine with Varnish
> 2.0 beta. Now with version 2.01 we have the following issue: 
> Executing any GET with the Testing-Framework results always in a PASS
> in Varnish. As a consequence all subsequent requests with the same
> url end up in cache hits for pass, that's not what we like to test.
> Requesting the same urls "manually", say with firefox or ie are first
> LOOKUPed and afterwards cached, the behaviour we would like to test.
> 
> Trying different ways to get around this "PASSing"-issue we came to
> the conclusion that it is not a grinder problem, because a simple GET
> done with the python httplib.HTTPConnection had the same effect.
> 
> Any comments, solutions, enlightments on this issue are appreciated.
> 

Post your vcl? Have you looked at the logs?

-- 
[EMAIL PROTECTED]
http://www.endpoint.com
___
varnish-misc mailing list
varnish-misc@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc


Re: Strange browser hickups with varnish

2008-06-17 Thread JT Justman
Christian Wiese wrote:
> The funny thing is that this seems to be a client thing. When I have a
> browser hanging, I can fetch the same file with curl or wget just fine.
>

This could be due to Varnish having different versions in different 
encodings (gzip/deflate/etc). Take a look at the encoding and see if 
this is the cause of differences between browsers.

As to the larger issue, I don't have much idea, but I think you should 
post more information, at least your varnishlog output.

JT

-- 
End Point Corporation
http://www.endpoint.com
___
varnish-misc mailing list
varnish-misc@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc


Second and subsequent ESI includes not cached

2008-05-09 Thread JT Justman
Hello, Varnish folks! I am currently in the process of testing the ESI 
features of Varnish. I have discovered that if I place more than one 
 on a document, any includes beyond the first are inserted 
to the cache, but never hit on subsequent requests. I have tried to 
determine if this is caused by something in my configuration but have 
been unable to locate anything. I have distilled my test case down to 
something which ought to be reproducible.


We are running varnish-trunk, latest revision within a week or so.

ESI is being triggered off the filename, for simplicity sake, as such:

sub vcl_fetch {
   remove obj.http.Set-Cookie;

   if (req.url ~ "esi\.html$") {
   esi;
   }
}

varnish is being tested by several users on the server simultaneously, 
using different non-privileged usernames and instance names (via -n).


See attached:

1) varnish_esi_case.txt, showing the contents of the source files, 
detailed headers for all objects. Demonstrates that on two subsequent 
requests, the max-age on the second include is not honored


2) varnish_varnishlog_output.txt, showing the output of varnishlog 
(excliding ping/PONG) though a purge, and then both requests to the 
ESI-enabled document.


An observation, which could easily be a mis-correlation: second and 
subsequent requests for esi fragments are logged with an 'XID' of '0'. I 
do not know if this is intentional or perhaps indicative of the 
underlying problem.


Thanks for any insight you can provide!

--
JT Justman
End Point Corporation
http://www.endpoint.com
$ cat cgi-bin/date-5.cgi 
#!/usr/local/bin/perl

use DateTime;

print "Content-Type: text/html; charset=iso-8859-1\nCache-Control: 
max-age=5\n\n";

print DateTime->now();
print "\n";

$ ./date-5.cgi 
Content-Type: text/html; charset=iso-8859-1
Cache-Control: max-age=5

2008-05-09T18:01:05
$ ./date-20.cgi 
Content-Type: text/html; charset=iso-8859-1
Cache-Control: max-age=20

2008-05-09T18:01:12

$ lwp-request -U -s -e http://localhost:9138/cgi-bin/date-20.cgi
GET http://localhost:9138/cgi-bin/date-20.cgi
User-Agent: lwp-request/2.08

200 OK
Cache-Control: max-age=20
Connection: close
Date: Fri, 09 May 2008 18:02:31 GMT
Via: 1.1 varnish
Age: 0
Server: Apache
Content-Length: 20
Content-Type: text/html; charset=iso-8859-1
Client-Date: Fri, 09 May 2008 18:02:30 GMT
Client-Peer: 127.0.0.1:9138
Client-Response-Num: 1
P3P: CP="IND NON DSP PHY ONL UNI FIN PUR COM INT DEM CNT STA PRE POL CUR ADMa 
PSAo PSDo IVAo IVDo CONo OUR", policyref="http://localhost:9138/w3c/p3p.xml";
X-Varnish: 1887710906

2008-05-09T18:02:31

$ lwp-request -U -s -e http://localhost:9138/cgi-bin/date-5.cgi
GET http://localhost:9138/cgi-bin/date-5.cgi
User-Agent: lwp-request/2.08

200 OK
Cache-Control: max-age=5
Connection: close
Date: Fri, 09 May 2008 18:03:13 GMT
Via: 1.1 varnish
Age: 0
Server: Apache
Content-Length: 20
Content-Type: text/html; charset=iso-8859-1
Client-Date: Fri, 09 May 2008 18:03:13 GMT
Client-Peer: 127.0.0.1:9138
Client-Response-Num: 1
P3P: CP="IND NON DSP PHY ONL UNI FIN PUR COM INT DEM CNT STA PRE POL CUR ADMa 
PSAo PSDo IVAo IVDo CONo OUR", policyref="http://localhost:9138/w3c/p3p.xml";
X-Varnish: 1887710907

2008-05-09T18:03:13

$ cat html/test_esi.html


This document will use the default TTL.

Here is an ESI include with a five second timeout: 

Here is an ESI include with a twenty second timeout: 


$ lwp-request -U -s -e http://localhost:9138/test_esi.html
GET http://localhost:9138/test_esi.html
User-Agent: lwp-request/2.08

200 OK
Connection: close
Date: Fri, 09 May 2008 18:16:12 GMT
Via: 1.1 varnish
Age: 0
ETag: "cc135-10d-18c031c0"
Server: Apache
Content-Type: text/html; charset=iso-8859-1
Last-Modified: Fri, 09 May 2008 18:09:19 GMT
Client-Date: Fri, 09 May 2008 18:16:12 GMT
Client-Peer: 127.0.0.1:9138
Client-Response-Num: 1
Client-Transfer-Encoding: chunked
P3P: CP="IND NON DSP PHY ONL UNI FIN PUR COM INT DEM CNT STA PRE POL CUR ADMa 
PSAo PSDo IVAo IVDo CONo OUR", policyref="http://localhost:9138/w3c/p3p.xml";
X-Varnish: 1887710915



This document will use the default TTL.

Here is an ESI include with a five second timeout: 2008-05-09T18:16:12


Here is an ESI include with a twenty second timeout: 2008-05-09T18:16:12



$ lwp-request -U -s -e http://localhost:9138/test_esi.html
GET http://localhost:9138/test_esi.html
User-Agent: lwp-request/2.08

200 OK
Connection: close
Date: Fri, 09 May 2008 18:16:14 GMT
Via: 1.1 varnish
Age: 2
ETag: "cc135-10d-18c031c0"
Server: Apache
Content-Type: text/html; charset=iso-8859-1
Last-Modified: Fri, 09 May 2008 18:09:19 GMT
Client-Date: Fri, 09 May 2008 18:16:14 GMT
Client-Peer: 127.0.0.1:9138
Client-Response-Num: 1
Client-Transfer-Encoding: chunked
P3P: CP="IND NON DSP PHY ONL UNI FIN PUR COM INT DEM CNT STA PRE POL CUR ADMa 
PSAo PSDo IVAo IVDo CONo OUR", policyref="http://localhost:9138/w3c/p3p.xml&q