renaming varnish concepts...
A couple of places in varnish I have clearly missed the boat when it comes to naming. And a couple of places, I should have thought more carefully. I wonder if we should correct these things in 2.1, in order to not confuse future users more than necessary, or if we already have sufficient users that it does not make sense to change things like this now. 2.1 is going to be a flag day anyway, because of the changes which persistent storage will cause, so I'm thinking this might be a good time for this sort of house-cleaning ? Input welcome. 1. Purge vs. Ban - The CLI and VCL commands are named purge, but they don't, they add a ban to the list of bans. I would actually like to rename purge to ban and add a real purge function that gets rid of the current object (ie: one found in the cache) and possibly its Vary: siblings. Purge does sound like it will be gone, whereas ban better explains what happens when we use the delayed regexp checks. Obviously, if I co-opt purge to mean something different, backwards compat is not possible, and all your purge scripts and VCLs with purge facilities will break. 2. CLI greeting When you connect to CLI port (-T argument) it does not announce itself. This was probably a mistake, as it makes it harder to do error detection in scripts that talk to the CLI. The problem is that if I add the greeting, I will break all existing scripts that talk to the CLI. 3. Acceptor vs. waiter --- The subfunction we today call acceptors are not really, they are waiters that monitor client connections for new requests. The real acceptor is a separate piece of code. This one is only visible in a command-line argument/parameter which users generally only fiddle as part of debugging. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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. ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Cacheability - changed in Varnish 2?
In message 497f1224.5060...@giraffen.dk, Anton Stonor writes: I Varnish 2 it looks like the objects must have either Cache-Control or Expires to be cached at all -- and then you can tamper with obj.ttl afterwards. If the backend doesn't set those headers, set obj.ttl doesn't seem have any effect. Can you get me varnishlog of such a request ? I'm not able to tell from your description which path we're talking about. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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. ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
RE : renaming varnish concepts...
+1 for some house-cleaning. - Speaking of bans, is grace used for banned objets ? If i ban an object, the first request will regenerate it from the back-end. Will following requests be getting the stale version during regeneration ? - For the CLI, why not add a compatible mode (inactive by default) to remove the greeting ? Jean-François Message d'origine De: varnish-misc-boun...@projects.linpro.no de la part de Poul-Henning Kamp Date: mer. 28/01/2009 10:11 À: varnish-misc@projects.linpro.no Objet : renaming varnish concepts... A couple of places in varnish I have clearly missed the boat when it comes to naming. And a couple of places, I should have thought more carefully. I wonder if we should correct these things in 2.1, in order to not confuse future users more than necessary, or if we already have sufficient users that it does not make sense to change things like this now. 2.1 is going to be a flag day anyway, because of the changes which persistent storage will cause, so I'm thinking this might be a good time for this sort of house-cleaning ? Input welcome. 1. Purge vs. Ban - The CLI and VCL commands are named purge, but they don't, they add a ban to the list of bans. I would actually like to rename purge to ban and add a real purge function that gets rid of the current object (ie: one found in the cache) and possibly its Vary: siblings. Purge does sound like it will be gone, whereas ban better explains what happens when we use the delayed regexp checks. Obviously, if I co-opt purge to mean something different, backwards compat is not possible, and all your purge scripts and VCLs with purge facilities will break. 2. CLI greeting When you connect to CLI port (-T argument) it does not announce itself. This was probably a mistake, as it makes it harder to do error detection in scripts that talk to the CLI. The problem is that if I add the greeting, I will break all existing scripts that talk to the CLI. 3. Acceptor vs. waiter --- The subfunction we today call acceptors are not really, they are waiters that monitor client connections for new requests. The real acceptor is a separate piece of code. This one is only visible in a command-line argument/parameter which users generally only fiddle as part of debugging. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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. ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Breaking Varnish
In message 20090123222947.gb28...@digdug.corp.631h.metaweb.com, Niall O'Higgi ns writes: Hi Tim, Can I get you to take -trunk for a spin ? At least the second of the problems you pasted I'm pretty sure I have nailed recently and the first one could easily be the same one in a different disguise. I've re-run the load test against varnish-trunk. Trunk is better behaved, but I now get output like this over and over: child (19731) Started Child (19731) said Closed fds: 4 7 8 10 11 Child (19731) said Child starts Child (19731) said managed to mmap 49929912320 bytes of 49929912320 Child (19731) said Ready Child (19731) not responding to ping, killing it. This is a typical indication of raw overload, what levels of traffic are you hitting it with ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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. ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Panic message: Assert error in exp_timer(), cache_expire.c line 303
In message 200901260917.45223.ottol...@web.de, Sascha Ottolski writes: Assert error in exp_timer(), cache_expire.c line 303: Condition(oe2-timer_when = oe-timer_when) not true. thread = (cache-timeout) [...] It all happens with trunk, r3497. Fixed in r3547 -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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. ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Cacheability - changed in Varnish 2?
Poul-Henning Kamp wrote: Can you get me varnishlog of such a request ? I'm not able to tell from your description which path we're talking about. Sure, just thought this was intended behavior so I wouldn't bore with details. Here we go. Running Varnish 2.0.2 on Ubuntu, has tested on Debian Etch 64bit as well. Failure: 9 SessionOpen c 127.0.0.1 41768 127.0.0.1:8000 9 ReqStart c 127.0.0.1 41768 1998529221 9 RxRequestc GET 9 RxURLc /test_varnish 9 RxProtocol c HTTP/1.1 9 RxHeader c Host: localhost:8000 9 RxHeader c User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.5) Gecko/2008121622 Ubuntu/8.10 (intrepid) Firefox/3.0.5 9 RxHeader c Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 9 RxHeader c Accept-Language: en-us,en;q=0.5 9 RxHeader c Accept-Encoding: gzip,deflate 9 RxHeader c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 9 RxHeader c Keep-Alive: 300 9 RxHeader c Connection: keep-alive 9 VCL_call c recv 9 VCL_return c lookup 9 VCL_call c hash 9 VCL_return c hash 9 HitPass c 1998529216 9 VCL_call c pass 9 VCL_return c pass 9 Backend c 10 backend_0 backend_0 10 TxRequest- GET 10 TxURL- /test_varnish 10 TxProtocol - HTTP/1.1 10 TxHeader - Host: localhost:8000 10 TxHeader - User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.5) Gecko/2008121622 Ubuntu/8.10 (intrepid) Firefox/3.0.5 10 TxHeader - Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 10 TxHeader - Accept-Language: en-us,en;q=0.5 10 TxHeader - Accept-Encoding: gzip,deflate 10 TxHeader - Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 10 TxHeader - X-Varnish: 1998529221 10 TxHeader - X-Forwarded-For: 127.0.0.1 10 RxProtocol - HTTP/1.1 10 RxStatus - 200 10 RxResponse - OK 10 RxHeader - Server: Zope/(Zope 2.10.6-final, python 2.4.5, linux2) ZServer/1.1 Plone/3.1.5.1 10 RxHeader - Date: Wed, 28 Jan 2009 10:13:23 GMT 10 RxHeader - Content-Length: 4 10 RxHeader - Content-Type: text/plain; charset=utf-8 9 ObjProtocol c HTTP/1.1 9 ObjStatusc 200 9 ObjResponse c OK 9 ObjHeaderc Server: Zope/(Zope 2.10.6-final, python 2.4.5, linux2) ZServer/1.1 Plone/3.1.5.1 9 ObjHeaderc Date: Wed, 28 Jan 2009 10:13:23 GMT 9 ObjHeaderc Content-Type: text/plain; charset=utf-8 10 BackendReuse - backend_0 9 TTL c 1998529221 RFC 0 1233137603 0 0 0 0 9 VCL_call c fetch 9 TTL c 1998529221 VCL 86400 1233137604 9 VCL_return c pass 9 Length c 4 9 VCL_call c deliver 9 VCL_return c deliver 9 TxProtocol c HTTP/1.1 9 TxStatus c 200 9 TxResponse c OK 9 TxHeader c Server: Zope/(Zope 2.10.6-final, python 2.4.5, linux2) ZServer/1.1 Plone/3.1.5.1 9 TxHeader c Content-Type: text/plain; charset=utf-8 9 TxHeader c Content-Length: 4 9 TxHeader c X-Varnish-Action: FETCH (pass - not cacheable) 9 TxHeader c Date: Wed, 28 Jan 2009 10:13:23 GMT 9 TxHeader c X-Varnish: 1998529221 9 TxHeader c Age: 0 9 TxHeader c Via: 1.1 varnish 9 TxHeader c Connection: keep-alive 9 ReqEnd c 1998529221 1233137603.757895708 1233137603.761220932 0.2 0.003257036 0.68188 0 StatAddr - 127.0.0.1 0 760 6 6 0 5 6 1970 24 Same backend header, just added a cache-control request key. Succes: 9 SessionOpen c 127.0.0.1 41774 127.0.0.1:8000 9 ReqStart c 127.0.0.1 41774 1998529224 9 RxRequestc GET 9 RxURLc /test_varnish 9 RxProtocol c HTTP/1.1 9 RxHeader c Host: localhost:8000 9 RxHeader c User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.5) Gecko/2008121622 Ubuntu/8.10 (intrepid) Firefox/3.0.5 9 RxHeader c Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 9 RxHeader c Accept-Language: en-us,en;q=0.5 9 RxHeader c Accept-Encoding: gzip,deflate 9 RxHeader c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 9 RxHeader c Keep-Alive: 300 9 RxHeader c Connection: keep-alive 9 VCL_call c recv 9 VCL_return c lookup 9 VCL_call c hash 9 VCL_return c hash 9 HitPass c 1998529216 9 VCL_call c pass 9 VCL_return c pass 9 Backend c 10 backend_0 backend_0 10 TxRequest- GET 10 TxURL- /test_varnish 10 TxProtocol - HTTP/1.1 10 TxHeader - Host: localhost:8000 10 TxHeader - User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.5) Gecko/2008121622 Ubuntu/8.10 (intrepid) Firefox/3.0.5 10 TxHeader - Accept:
Re: [varnish] renaming varnish concepts...
On Jan 28, 2009, at 1:11 AM, Poul-Henning Kamp wrote: 1. Purge vs. Ban - The CLI and VCL commands are named purge, but they don't, they add a ban to the list of bans. I would actually like to rename purge to ban and add a real purge function that gets rid of the current object (ie: one found in the cache) and possibly its Vary: siblings. Purge does sound like it will be gone, whereas ban better explains what happens when we use the delayed regexp checks. Obviously, if I co-opt purge to mean something different, backwards compat is not possible, and all your purge scripts and VCLs with purge facilities will break. Can you explain what is the effective difference between a real purge and a ban? Would both still kill all the Vary siblings? Other than possibly releasing the memory quicker, I'm not sure why I should care :-) Ric ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: [varnish] Re: Cacheability - changed in Varnish 2?
On Jan 28, 2009, at 2:23 AM, Anton Stonor wrote:
sub vcl_recv {
set req.grace = 120s;
set req.backend = backend_0;
}
Is this truly all you have in vcl_recv? This will mean that any
cookied requests will get passed. Is this intentional?
Ric
___
varnish-misc mailing list
varnish-misc@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: [varnish] Re: [varnish] renaming varnish concepts...
In message 79a2ce8a-a135-4542-9c8c-1f4327fed...@digitalmarbles.com, Ricardo N ewbery writes: Sorry, I'm still unclear... Right now, doesn't purge_url also ban all Varys? Yes, but they won't be dealt with until they take a catch-hit. The idea is to deal with them all once we find the first one. If so, then why would it matter whether a PURGE request resulted in a real purge or a ban? It would get things out of the system faster. This may not make a big difference to most sites, but very interactive sites can have a LOT of purges going on. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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. ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: [varnish] renaming varnish concepts...
In message e9dd9378-1dae-4077-a0c6-149dbac0c...@digitalmarbles.com, Ricardo N ewbery writes: On Jan 28, 2009, at 4:19 AM, Poul-Henning Kamp wrote: In message 768C2A99-6D24-4D6F- b324-25e13cfbe...@digitalmarbles.com, Ricardo N ewbery writes: Cool... so why do you figure that backwards compatibility is not possible? If my old purge scripts now start purging rather than banning, why should anything break? Purge wouldn't be a CLI command Ah, okay... why not? Because you don't have a cached object at hand to purge, all you can do from the CLI is to add bans that will deal with the objects when they are found in the cache later on. Your question is -exactly- why I want the rename: purge sounds like something happens to the object right now, and that is not possible from the CLI context. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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. ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: [varnish] renaming varnish concepts...
Why is it not possible to purge a URL from CLI for a particular host ? -Paras On Wed, Jan 28, 2009 at 6:40 PM, Ricardo Newbery r...@digitalmarbles.com wrote: On Jan 28, 2009, at 4:30 AM, Poul-Henning Kamp wrote: In message, Ricardo Newbery writes: On Jan 28, 2009, at 4:19 AM, Poul-Henning Kamp wrote: Purge wouldn't be a CLI command Ah, okay... why not? Because you don't have a cached object at hand to purge, all you can do from the CLI is to add bans that will deal with the objects when they are found in the cache later on. Your question is -exactly- why I want the rename: purge sounds like something happens to the object right now, and that is not possible from the CLI context. Sure, I understand the motivation. But FWIW, I already knew what purge meant in the varnish context. I'm just trying to understand the implications of the proposed change. I'm unclear on why we can't acquire the cached object from the CLI to do the purge. I imagine the most common usecase is to purge based on a known url, and with the url don't we have enough information to get at the cache and purge all variants? Ric ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: [+] Re: Breaking Varnish
On Wed, Jan 28, 2009 at 09:54:26AM +, Poul-Henning Kamp wrote: I've re-run the load test against varnish-trunk. Trunk is better behaved, but I now get output like this over and over: child (19731) Started Child (19731) said Closed fds: 4 7 8 10 11 Child (19731) said Child starts Child (19731) said managed to mmap 49929912320 bytes of 49929912320 Child (19731) said Ready Child (19731) not responding to ping, killing it. This is a typical indication of raw overload, what levels of traffic are you hitting it with ? This kind of thing: Transaction rate:3776.65 trans/sec Throughput: 1.68 MB/sec Concurrency: 28.28 Does the parent process give up on restarting the child after a certain number of failures? I was surprised by the eventual complete exit of varnishd with the message: Pushing vcls failed: CLI communication error Also, Varnish seems to be able to handle up to about double that load for a while (we got up to 6701 t/sec), then it dies as above. Seems like it takes around 2-3 hours for the varnishd parent process to die. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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. -- Niall O'Higgins Software Engineer Metaweb Technologies, Inc. ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: [+] Re: Breaking Varnish
In message 20090128183618.ge28...@digdug.corp.631h.metaweb.com, Niall O'Higgi ns writes: On Wed, Jan 28, 2009 at 10:18:48AM -0800, Michael S. Fischer wrote: On Jan 28, 2009, at 10:04 AM, Niall O'Higgins wrote: Varnish is running on a dual CPU (amd64) Linux 2.6 machine. We have pushed it up to 6701 t/sec with multiple load-generation machines. We see the same child-restart behaviour whether we use a single load-generation machine, or three. As I said, increase the cli_timeout parameter, it is probably to short for that kind of scenario. Also, you should probably set srcaddr_ttl to zero, to disable the (effectively unused) per source-IP statistics. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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. ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Breaking Varnish
In message f628e190-8dbb-46f9-8973-d9c0b0f67...@metaweb.com, Tim Kientzle wri tes: It also appears that Varnish eventually exits completely if placed under high load. I'm okay with that as long as it's intentional behavior; It is not intentional. The entire point about the two-process trick is to not ever throw in the towel if we can avoid it. That said, there are classes of bugs for which we have no hope, if for instance the manager process cannot fork or allocate memory, then we are hosed top and bottom. Of course, I understand that killing the child and starting a new one will also lose the cache, which is obviously not particularly desirable under heavy load. Persistent storage coming up in version 2.1 :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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. ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: [varnish] renaming varnish concepts...
In message 75cf5800901280825w50d09916r12ece84c832eb...@mail.gmail.com, Paras Fadte writes: Why is it not possible to purge a URL from CLI for a particular host ? You can enter a ban for it. Prior to the new code in -trunk, you need to use purge.hash and construct an appropriate regexp. With the new code, which will possibly be in 2.0.3, you can express it sensibly: purge req.url ~ some_regexp req.http.host ~ some other regexp But we cannot do an object lookup, so we can not reclaim the storage of those objects immediately. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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. ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Cacheability - changed in Varnish 2?
Hi Poul-Henning, 9 VCL_call c hash 9 VCL_return c hash 9 HitPass c 1998529216 9 VCL_call c pass 9 VCL_return c pass This is the important bit, you have a cached object that says this object cannot be cached, but should be passed. Thanks for digging into this and pointing out the relevant part. I see that my log-snippets wasn't that useful to nail the issue. New try. First, a request with no expire or cache-control header. 9 RxURLc /test_varnish_noheader 9 RxProtocol c HTTP/1.1 9 RxHeader c Host: localhost:8000 9 RxHeader c User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.5) Gecko/2008121622 Ubuntu/8.10 (intrepid) Firefox/3.0.5 9 RxHeader c Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 9 RxHeader c Accept-Language: en-us,en;q=0.5 9 RxHeader c Accept-Encoding: gzip,deflate 9 RxHeader c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 9 RxHeader c Keep-Alive: 300 9 RxHeader c Connection: keep-alive 9 VCL_call c recv 9 VCL_return c lookup 9 VCL_call c hash 9 VCL_return c hash 9 VCL_call c miss 9 VCL_return c fetch 10 BackendOpen b backend_0 127.0.0.1 36975 127.0.0.1 8080 9 Backend c 10 backend_0 backend_0 10 TxRequestb GET 10 TxURLb /test_varnish_noheader 10 TxProtocol b HTTP/1.1 10 TxHeader b Host: localhost:8000 10 TxHeader b User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.5) Gecko/2008121622 Ubuntu/8.10 (intrepid) Firefox/3.0.5 10 TxHeader b Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 10 TxHeader b Accept-Language: en-us,en;q=0.5 10 TxHeader b Accept-Encoding: gzip,deflate 10 TxHeader b Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 10 TxHeader b X-Varnish: 1495399095 10 TxHeader b X-Forwarded-For: 127.0.0.1 10 RxProtocol b HTTP/1.1 10 RxStatus b 200 10 RxResponse b OK 10 RxHeader b Server: Zope/(Zope 2.10.6-final, python 2.4.5, linux2) ZServer/1.1 Plone/3.1.5.1 10 RxHeader b Date: Thu, 29 Jan 2009 00:10:40 GMT 10 RxHeader b Content-Length: 4 10 RxHeader b Content-Type: text/plain; charset=utf-8 9 ObjProtocol c HTTP/1.1 9 ObjStatusc 200 9 ObjResponse c OK 9 ObjHeaderc Server: Zope/(Zope 2.10.6-final, python 2.4.5, linux2) ZServer/1.1 Plone/3.1.5.1 9 ObjHeaderc Date: Thu, 29 Jan 2009 00:10:40 GMT 9 ObjHeaderc Content-Type: text/plain; charset=utf-8 10 BackendReuse b backend_0 9 TTL c 1495399095 RFC 0 1233187840 0 0 0 0 9 VCL_call c fetch 9 TTL c 1495399095 VCL 86400 1233187841 9 VCL_return c pass 9 Length c 4 9 VCL_call c deliver 9 VCL_return c deliver pass is called inside vcl_fetch because the object is classified as !cachable. Subsequent requests gives same result as in my first mail: 9 VCL_call c recv 9 VCL_return c lookup 9 VCL_call c hash 9 VCL_return c hash 9 HitPass c 1495399095 9 VCL_call c pass 9 VCL_return c pass 9 Backend Then, restart Varnish, same vcl file, same backend reponse except that we are now adding a cache-control header: 9 RxRequestc GET 9 RxURLc /test_varnish 9 RxProtocol c HTTP/1.1 9 RxHeader c Host: localhost:8000 9 RxHeader c User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.5) Gecko/2008121622 Ubuntu/8.10 (intrepid) Firefox/3.0.5 9 RxHeader c Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 9 RxHeader c Accept-Language: en-us,en;q=0.5 9 RxHeader c Accept-Encoding: gzip,deflate 9 RxHeader c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 9 RxHeader c Keep-Alive: 300 9 RxHeader c Connection: keep-alive 9 VCL_call c recv 9 VCL_return c lookup 9 VCL_call c hash 9 VCL_return c hash 9 VCL_call c miss 9 VCL_return c fetch 10 BackendOpen b backend_0 127.0.0.1 38871 127.0.0.1 8080 9 Backend c 10 backend_0 backend_0 10 TxRequestb GET 10 TxURLb /test_varnish 10 TxProtocol b HTTP/1.1 10 TxHeader b Host: localhost:8000 10 TxHeader b User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.5) Gecko/2008121622 Ubuntu/8.10 (intrepid) Firefox/3.0.5 10 TxHeader b Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 10 TxHeader b Accept-Language: en-us,en;q=0.5 10 TxHeader b Accept-Encoding: gzip,deflate 10 TxHeader b Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 10 TxHeader b X-Varnish: 1198489031 10 TxHeader b X-Forwarded-For: 127.0.0.1 10 RxProtocol b HTTP/1.1 10
Re: [varnish] Re: Cacheability - changed in Varnish 2?
Ricardo Newbery skrev:
sub vcl_recv {
set req.grace = 120s;
set req.backend = backend_0;
}
Is this truly all you have in vcl_recv? This will mean that any cookied
requests will get passed. Is this intentional?
No, this is not a production setup. My problem is not that I cache too
much, but the opposite.
And yep, I know about the cookie issue:
http://markmail.org/message/pfpx7lanicpumsdg
Thanks for noticing.
/Anton
___
varnish-misc mailing list
varnish-misc@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc
[varnish] Re: Cacheability - changed in Varnish 2?
On Jan 28, 2009, at 4:29 PM, Anton Stonor wrote:
Ricardo Newbery skrev:
sub vcl_recv {
set req.grace = 120s;
set req.backend = backend_0;
}
Is this truly all you have in vcl_recv? This will mean that any
cookied
requests will get passed. Is this intentional?
No, this is not a production setup. My problem is not that I cache too
much, but the opposite.
And yep, I know about the cookie issue:
http://markmail.org/message/pfpx7lanicpumsdg
Thanks for noticing.
/Anton
Sorry, I'm confused. Maybe I'm misunderstanding what you're saying
here, but the cookie issue will mean that you will cache too little,
not too much.
Ric
___
varnish-misc mailing list
varnish-misc@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc
