From jsd at cluttered.com Thu May 1 17:27:01 2008 From: jsd at cluttered.com (Jon Drukman) Date: Thu, 01 May 2008 10:27:01 -0700 Subject: multiple domains -> varnish -> one backend Message-ID: I am using varnish to accelerate several different incoming domains. They all hit the same backend server, but the server responds differently depending on the host header (which I passing in as X-Orig-Host). Varnish however is ignoring the incoming domain name and just using the path as the cache key. Example: http://domain1.com/page1 http://domain2.com/page1 The backend server responds differently but varnish serves whichever one was requested first. How do I tell varnish that host+path is significant instead of just path? my vcl_recv looks like this: sub vcl_recv { set req.url = regsub(req.url, "^", "/site"); set req.http.X-Orig-Host = req.http.host; set req.http.host = "originserver.com"; if (req.request == "POST") { pipe; } # force lookup even when cookies are present if (req.request == "GET" && req.http.cookie) { lookup; } } -jsd- From phk at phk.freebsd.dk Thu May 1 17:33:27 2008 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Thu, 01 May 2008 17:33:27 +0000 Subject: multiple domains -> varnish -> one backend In-Reply-To: Your message of "Thu, 01 May 2008 10:27:01 MST." Message-ID: <39604.1209663207@critter.freebsd.dk> In message , Jon Drukman writes: >I am using varnish to accelerate several different incoming domains. >They all hit the same backend server, but the server responds >differently depending on the host header (which I passing in as >X-Orig-Host). > >Varnish however is ignoring the incoming domain name and just using the >path as the cache key. Example: Which version of varnish ? -- 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 jsd at cluttered.com Thu May 1 19:27:23 2008 From: jsd at cluttered.com (Jon Drukman) Date: Thu, 01 May 2008 12:27:23 -0700 Subject: multiple domains -> varnish -> one backend In-Reply-To: <39604.1209663207@critter.freebsd.dk> References: <39604.1209663207@critter.freebsd.dk> Message-ID: Poul-Henning Kamp wrote: > In message , Jon Drukman writes: >> Varnish however is ignoring the incoming domain name and just using the >> path as the cache key. Example: > > Which version of varnish ? > > 1.1.2 -jsd- From phk at phk.freebsd.dk Thu May 1 19:38:56 2008 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Thu, 01 May 2008 19:38:56 +0000 Subject: multiple domains -> varnish -> one backend In-Reply-To: Your message of "Thu, 01 May 2008 12:27:23 MST." Message-ID: <1347.1209670736@critter.freebsd.dk> In message , Jon Drukman writes: >Poul-Henning Kamp wrote: >> In message , Jon Drukman writes: >>> Varnish however is ignoring the incoming domain name and just using the >>> path as the cache key. Example: >> >> Which version of varnish ? >> >> >1.1.2 Please update to 1.2 or even better: -trunk, this has been fixed in the meantime. -- 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 May 1 20:54:11 2008 From: ric at digitalmarbles.com (Ricardo Newbery) Date: Thu, 1 May 2008 13:54:11 -0700 Subject: zope-plone.vcl Message-ID: <77CC09E5-D7E0-460E-BA8A-0813BB0B06D2@digitalmarbles.com> Just poking around the tracker and I noticed some activity on the example plone vcl. http://varnish.projects.linpro.no/changeset/2634 Just thought I would chime in that the example has issues. First of all, it's unnecessary to filter cookie-authenticated requests as authenticated responses are already set with a past date Expires (although you need to set a default_ttl of zero seconds, http://varnish.projects.linpro.no/ticket/236) . With CacheFu installed, the default policy gives authenticated responses a max-age=0. However, some authenticated responses are deliberately cached -- mostly images, javascript and css files. The rule in the example vcl defeats this strategy. Also, not every non-authenticated item should be set with a minimum ttl of 3600 seconds. CacheFu can't yet purge all items reliably when the view changes. Some view changes may be dependent on changes elsewhere in the site which currently is hard to track reliably in the general case. Subsequently, the default policy for some content and most container views is to NOT cache in the proxy. This is easily overridden in CacheFu as necessary but again the example vcl defeats this strategy. Also, last I heard Varnish strips the conditionals from conditional requests when passed to the backend. This is unfortunate as one default CacheFu policy for private items is to "cache" the items only in the browser with conditional requests ensuring freshness. Stripping the conditionals defeats this strategy. The solution is to pass the conditionals in the vcl which the example vcl does not do. IMHO, a better example of a vcl for plone (for varnish trunk or 1.2) can be found at: http://svn.plone.org/svn/collective/buildout/plone.recipe.varnish/trunk/plone/recipe/varnish/template.vcl Ric From wichert at wiggy.net Thu May 1 21:21:42 2008 From: wichert at wiggy.net (Wichert Akkerman) Date: Thu, 1 May 2008 23:21:42 +0200 Subject: zope-plone.vcl In-Reply-To: <77CC09E5-D7E0-460E-BA8A-0813BB0B06D2@digitalmarbles.com> References: <77CC09E5-D7E0-460E-BA8A-0813BB0B06D2@digitalmarbles.com> Message-ID: <20080501212142.GA20491@wiggy.net> Previously Ricardo Newbery wrote: > Just poking around the tracker and I noticed some activity on the > example plone vcl. http://varnish.projects.linpro.no/changeset/2634 > > Just thought I would chime in that the example has issues. > > First of all, it's unnecessary to filter cookie-authenticated requests > as authenticated responses are already set with a past date Expires > (although you need to set a default_ttl of zero seconds, http://varnish.projects.linpro.no/ticket/236) Actually that is not true. It holds for document, but a quick test shows it does not for images. > . With CacheFu installed, the default policy gives authenticated > responses a max-age=0. However, some authenticated responses are > deliberately cached -- mostly images, javascript and css files. The > rule in the example vcl defeats this strategy. Nitpick: technically you install CacheSetup, not Cachefu. CacheFu is a bundling of which including CacheSetup. A default plone.vcl should also work reasonably for sites without CacheSetup installed. Wichert. -- Wichert Akkerman It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. From wichert at wiggy.net Thu May 1 21:22:17 2008 From: wichert at wiggy.net (Wichert Akkerman) Date: Thu, 1 May 2008 23:22:17 +0200 Subject: zope-plone.vcl In-Reply-To: <77CC09E5-D7E0-460E-BA8A-0813BB0B06D2@digitalmarbles.com> References: <77CC09E5-D7E0-460E-BA8A-0813BB0B06D2@digitalmarbles.com> Message-ID: <20080501212217.GB20491@wiggy.net> Previously Ricardo Newbery wrote: > IMHO, a better example of a vcl for plone (for varnish trunk or 1.2) > can be found at: > http://svn.plone.org/svn/collective/buildout/plone.recipe.varnish/trunk/plone/recipe/varnish/template.vcl I have some improvements pending for that one as well: a few cleanups and switching to url_purge. Wichert. -- Wichert Akkerman It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. From ric at digitalmarbles.com Thu May 1 21:55:22 2008 From: ric at digitalmarbles.com (Ricardo Newbery) Date: Thu, 1 May 2008 14:55:22 -0700 Subject: PURGE http method and compression. In-Reply-To: <6419.1209381684@critter.freebsd.dk> References: <6419.1209381684@critter.freebsd.dk> Message-ID: On Apr 28, 2008, at 4:21 AM, Poul-Henning Kamp wrote: > In message <4815AA34.5040300 at wiggy.net>, Wichert Akkerman writes: > >> That's interesting. So the default VCL for HTTP PURGE requests will >> not >> purge all variants? How can a backend know which variants there are >> so it >> can purge all of them? > > It probably can't, so if your backend returns "Vary:" headers, you > should > use the url.purge or hash.purge method. Well, this is very unfortunate. Both url.purge and hash.purge are command line only, correct? Can you think of any way to purge all variants via a PURGE request with some vcl tricks? If not, then are there any plans to support proper variant purging in vcl? I realize this may be difficult problem -- Squid also only recently managed to fix variant purging. But it's a serious problem regardless. Ric From wichert at wiggy.net Thu May 1 21:57:35 2008 From: wichert at wiggy.net (Wichert Akkerman) Date: Thu, 1 May 2008 23:57:35 +0200 Subject: PURGE http method and compression. In-Reply-To: References: <6419.1209381684@critter.freebsd.dk> Message-ID: <20080501215735.GA25551@wiggy.net> Previously Ricardo Newbery wrote: > > On Apr 28, 2008, at 4:21 AM, Poul-Henning Kamp wrote: > > > In message <4815AA34.5040300 at wiggy.net>, Wichert Akkerman writes: > > > >> That's interesting. So the default VCL for HTTP PURGE requests will > >> not > >> purge all variants? How can a backend know which variants there are > >> so it > >> can purge all of them? > > > > It probably can't, so if your backend returns "Vary:" headers, you > > should > > use the url.purge or hash.purge method. > > > Well, this is very unfortunate. Both url.purge and hash.purge are > command line only, correct? Can you think of any way to purge all > variants via a PURGE request with some vcl tricks? They were exposed in vcl in 1.1.1. Wichert. -- Wichert Akkerman It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. From jsd at cluttered.com Thu May 1 21:58:31 2008 From: jsd at cluttered.com (Jon Drukman) Date: Thu, 01 May 2008 14:58:31 -0700 Subject: multiple domains -> varnish -> one backend In-Reply-To: <1347.1209670736@critter.freebsd.dk> References: <1347.1209670736@critter.freebsd.dk> Message-ID: Poul-Henning Kamp wrote: >> 1.1.2 > > Please update to 1.2 or even better: -trunk, this has been fixed > in the meantime. I am running trunk now and the behavior is the same. here is my complete vcl.conf (actual domain name changed. let me know if you need to see it and i will send the file privately) backend default { .host = "originserver.com"; .port = "80"; } sub vcl_recv { set req.url = regsub(req.url, "^", "/site"); set req.http.X-Orig-Host = req.http.host; set req.http.host = "originserver.com"; if (req.request == "POST") { pipe; } # force lookup even when cookies are present if (req.request == "GET" && req.http.cookie) { lookup; } } sub vcl_fetch { # force minimum ttl of 180 seconds if (obj.ttl < 180s) { set obj.ttl = 180s; } } From ric at digitalmarbles.com Thu May 1 22:13:00 2008 From: ric at digitalmarbles.com (Ricardo Newbery) Date: Thu, 1 May 2008 15:13:00 -0700 Subject: PURGE http method and compression. In-Reply-To: <20080501215735.GA25551@wiggy.net> References: <6419.1209381684@critter.freebsd.dk> <20080501215735.GA25551@wiggy.net> Message-ID: <681844BA-E2F5-4CDD-AA48-150A2CECB448@digitalmarbles.com> On May 1, 2008, at 2:57 PM, Wichert Akkerman wrote: > Previously Ricardo Newbery wrote: >> >> On Apr 28, 2008, at 4:21 AM, Poul-Henning Kamp wrote: >> >>> In message <4815AA34.5040300 at wiggy.net>, Wichert Akkerman writes: >>> >>>> That's interesting. So the default VCL for HTTP PURGE requests will >>>> not >>>> purge all variants? How can a backend know which variants there are >>>> so it >>>> can purge all of them? >>> >>> It probably can't, so if your backend returns "Vary:" headers, you >>> should >>> use the url.purge or hash.purge method. >> >> >> Well, this is very unfortunate. Both url.purge and hash.purge are >> command line only, correct? Can you think of any way to purge all >> variants via a PURGE request with some vcl tricks? > > They were exposed in vcl in 1.1.1. > > Wichert. Really? I was not aware of that. Great! Ric From ric at digitalmarbles.com Thu May 1 22:13:21 2008 From: ric at digitalmarbles.com (Ricardo Newbery) Date: Thu, 1 May 2008 15:13:21 -0700 Subject: zope-plone.vcl In-Reply-To: <20080501212142.GA20491@wiggy.net> References: <77CC09E5-D7E0-460E-BA8A-0813BB0B06D2@digitalmarbles.com> <20080501212142.GA20491@wiggy.net> Message-ID: On May 1, 2008, at 2:21 PM, Wichert Akkerman wrote: > Previously Ricardo Newbery wrote: >> Just poking around the tracker and I noticed some activity on the >> example plone vcl. http://varnish.projects.linpro.no/changeset/2634 >> >> Just thought I would chime in that the example has issues. >> >> First of all, it's unnecessary to filter cookie-authenticated >> requests >> as authenticated responses are already set with a past date Expires >> (although you need to set a default_ttl of zero seconds, http://varnish.projects.linpro.no/ticket/236) > > Actually that is not true. It holds for document, but a quick test > shows > it does not for images. Pardon, can you elaborate? What does not hold true? I realize that setting a default_ttl of zero seconds introduces another problem in that items without explicit cache control would not be cached. That's why fixing the varnish Expires handling would be better. >> . With CacheFu installed, the default policy gives authenticated >> responses a max-age=0. However, some authenticated responses are >> deliberately cached -- mostly images, javascript and css files. The >> rule in the example vcl defeats this strategy. > > Nitpick: technically you install CacheSetup, not Cachefu. CacheFu is a > bundling of which including CacheSetup. > > A default plone.vcl should also work reasonably for sites without > CacheSetup installed. Agreed. Is this not true for the example I linked to? Ric From wichert at wiggy.net Fri May 2 05:50:01 2008 From: wichert at wiggy.net (Wichert Akkerman) Date: Fri, 02 May 2008 07:50:01 +0200 Subject: zope-plone.vcl In-Reply-To: References: <77CC09E5-D7E0-460E-BA8A-0813BB0B06D2@digitalmarbles.com> <20080501212142.GA20491@wiggy.net> Message-ID: <481AAB89.8000306@wiggy.net> Ricardo Newbery wrote: > > On May 1, 2008, at 2:21 PM, Wichert Akkerman wrote: > >> Previously Ricardo Newbery wrote: >>> Just poking around the tracker and I noticed some activity on the >>> example plone vcl. http://varnish.projects.linpro.no/changeset/2634 >>> >>> Just thought I would chime in that the example has issues. >>> >>> First of all, it's unnecessary to filter cookie-authenticated requests >>> as authenticated responses are already set with a past date Expires >>> (although you need to set a default_ttl of zero seconds, >>> http://varnish.projects.linpro.no/ticket/236) >> >> Actually that is not true. It holds for document, but a quick test shows >> it does not for images. > > > Pardon, can you elaborate? What does not hold true? > > I realize that setting a default_ttl of zero seconds introduces > another problem in that items without explicit cache control would not > be cached. That's why fixing the varnish Expires handling would be > better. Authenticated requests do not always get a past Expires-date in their response. This appears to only be true for documents (like ATDocument) but not for images (like ATImage). Wichert. -- Wichert Akkerman It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. From ric at digitalmarbles.com Fri May 2 09:41:11 2008 From: ric at digitalmarbles.com (Ricardo Newbery) Date: Fri, 2 May 2008 02:41:11 -0700 Subject: zope-plone.vcl In-Reply-To: <481AAB89.8000306@wiggy.net> References: <77CC09E5-D7E0-460E-BA8A-0813BB0B06D2@digitalmarbles.com> <20080501212142.GA20491@wiggy.net> <481AAB89.8000306@wiggy.net> Message-ID: <6887A325-782F-49B1-AEE2-529363039E71@digitalmarbles.com> On May 1, 2008, at 10:50 PM, Wichert Akkerman wrote: > Ricardo Newbery wrote: >> >> On May 1, 2008, at 2:21 PM, Wichert Akkerman wrote: >> >>> Previously Ricardo Newbery wrote: >>>> Just poking around the tracker and I noticed some activity on the >>>> example plone vcl. http://varnish.projects.linpro.no/changeset/ >>>> 2634 >>>> >>>> Just thought I would chime in that the example has issues. >>>> >>>> First of all, it's unnecessary to filter cookie-authenticated >>>> requests >>>> as authenticated responses are already set with a past date Expires >>>> (although you need to set a default_ttl of zero seconds, http://varnish.projects.linpro.no/ticket/236) >>> >>> Actually that is not true. It holds for document, but a quick test >>> shows >>> it does not for images. >> >> >> Pardon, can you elaborate? What does not hold true? >> >> I realize that setting a default_ttl of zero seconds introduces >> another problem in that items without explicit cache control would >> not be cached. That's why fixing the varnish Expires handling >> would be better. > > Authenticated requests do not always get a past Expires-date in > their response. This appears to only be true for documents (like > ATDocument) but not for images (like ATImage). Ah right... but I believe this is by design. Images are usually not intended to be excluded from proxy caches. In Plone, by default even if the images are restricted by their workflow state to authenticated requests, the response does not have any cache-control to exclude it from shared caches downstream (in my opinion, this is a bug). And if you can't exclude it from downstream shared caches, it's rather pointless to exclude it from the reverse proxy cache. The problem with the example zope-plone.vcl is that it excludes ALL cookie-authenticated responses -- even those inline images, css, and javascript files that otherwise would be cacheable in downstream caches -- making authenticated browsing unnecessarily taxing on the backend. Ric From cherife at dotimes.com Sun May 4 15:46:19 2008 From: cherife at dotimes.com (Cherife Li) Date: Sun, 04 May 2008 23:46:19 +0800 Subject: sticky conn and health check Message-ID: <481DDA4B.1060004@dotimes.com> Hi all. Varnish is such a wonderful accelerator that I want to say thanks to the Varnish project and all its contributors. We're using Varnish 1.1.2 in production environment. Recently we've got two problems, no solutions found even if searched the web or checked the man pages. One is sticky connection. The problem is how can varnish send request to the same backend when it receives a request it processed before. For example, GET http://foo.com/a.gif how can Varnish pass the request to the *same* backend when it receives this request? (if we don't cache the request) Is there a way to do URI hash? Or any other methods? The other one is health check. Can Varnish do health check? So that when it treats a backend as down, Varnish won't send requests to it any more until Varnish sees it up again. I don't know if heartbeat form High Availability Linux project combines Varnish could do health check. Any suggestions? Thanks all. -- Rgds, Cherife. From jsd at cluttered.com Sun May 4 21:27:54 2008 From: jsd at cluttered.com (Jon Drukman) Date: Sun, 04 May 2008 14:27:54 -0700 Subject: multiple domains -> varnish -> one backend In-Reply-To: References: <1347.1209670736@critter.freebsd.dk> Message-ID: Jon Drukman wrote: > Poul-Henning Kamp wrote: >>> 1.1.2 >> Please update to 1.2 or even better: -trunk, this has been fixed >> in the meantime. > > I am running trunk now and the behavior is the same. i suspect what is going on is that i am changing req.http.host here: > sub vcl_recv { > set req.url = regsub(req.url, "^", "/site"); > set req.http.X-Orig-Host = req.http.host; > set req.http.host = "originserver.com"; > > if (req.request == "POST") { > pipe; > } > > # force lookup even when cookies are present > if (req.request == "GET" && req.http.cookie) { > lookup; > } > } and thus varnish is using that as the hash key. this would explain why the first requested domain is used for all subsequent cached replies. is there a way to 'save' the original req.http.host and use that as the hash key? i tried to mess with req.hash in vcl_recv but varnish says i'm not allowed to tinker with those variables there. -jsd- From havard.futseter at met.no Mon May 5 11:53:34 2008 From: havard.futseter at met.no (=?ISO-8859-1?Q?H=E5vard_Futs=E6ter?=) Date: Mon, 05 May 2008 13:53:34 +0200 Subject: send_timeout causes closed connections? Message-ID: <481EF53E.70308@met.no> Hi. We have a problem with connections closing prematurely when downloading large documents, and we think the send_timeout parameter could be the culprit. Example: Parameter send_timeout is initially set to 45 seconds. A 19M file is downloaded from varnish ( apache - server as backend ) on an adsl - line. 45 - 50s into the download the connection is abruptly closed. Increasing send_timeout ( say from 45s to 120s ) will delay closing the connection by the same amount of time. At send_timeout = 180s the download works just fine ( finishes at 154s ). In the documentation send_timeout is described like so: 'Send timeout for client connections. If no data has been sent to the client in this many seconds, the session is closed.' Any idea what is happening here? Could there be a bug in how varnish handles this parameter? If so, is this something that has been solved in 1.1.2? We use Varnish 1.0.4 on 64-bits debian-etch. - H?vard Futs?ter From ssm at linpro.no Mon May 5 12:59:24 2008 From: ssm at linpro.no (Stig Sandbeck Mathisen) Date: Mon, 05 May 2008 14:59:24 +0200 Subject: zope-plone.vcl In-Reply-To: <6887A325-782F-49B1-AEE2-529363039E71@digitalmarbles.com> (Ricardo Newbery's message of "Fri, 2 May 2008 02:41:11 -0700") References: <77CC09E5-D7E0-460E-BA8A-0813BB0B06D2@digitalmarbles.com> <20080501212142.GA20491@wiggy.net> <481AAB89.8000306@wiggy.net> <6887A325-782F-49B1-AEE2-529363039E71@digitalmarbles.com> Message-ID: <7xod7k6h5f.fsf@iostat.linpro.no> On Fri, 2 May 2008 02:41:11 -0700, Ricardo Newbery said: > The problem with the example zope-plone.vcl is that it excludes ALL > cookie-authenticated responses -- even those inline images, css, and > javascript files that otherwise would be cacheable in downstream > caches -- making authenticated browsing unnecessarily taxing on the > backend. That's certainly true, yes. The zope-plone.vcl example is not in any way efficient for authenticated sessions. As I recall, it was originally used for sites which did not publish through Varnish at all, or used authenticated sessions. I'll look at the points in this thread, test a bit, and update the example. The plone.recipe.varnish template looks especially nice. Are there any good reasons not to run Plone with the CacheFu (or CacheSetup) product installed? Would a non-CacheFu example be of any use? -- Stig Sandbeck Mathisen, Linpro From ssm at linpro.no Mon May 5 13:01:54 2008 From: ssm at linpro.no (Stig Sandbeck Mathisen) Date: Mon, 05 May 2008 15:01:54 +0200 Subject: zope-plone.vcl In-Reply-To: <20080501212217.GB20491@wiggy.net> (Wichert Akkerman's message of "Thu, 1 May 2008 23:22:17 +0200") References: <77CC09E5-D7E0-460E-BA8A-0813BB0B06D2@digitalmarbles.com> <20080501212217.GB20491@wiggy.net> Message-ID: <7xk5i86h19.fsf@iostat.linpro.no> On Thu, 1 May 2008 23:22:17 +0200, Wichert Akkerman said: > I have some improvements pending for that one as well: a few > cleanups and switching to url_purge. Would it make sense, in vcl_recv, to put the PURGE check inside the "not GET and not HEAD" block as well? Not sure what it means performance wise, but it removes one conditional for a normal GET request. -- Stig Sandbeck Mathisen, Linpro From wichert at wiggy.net Mon May 5 13:02:05 2008 From: wichert at wiggy.net (Wichert Akkerman) Date: Mon, 05 May 2008 15:02:05 +0200 Subject: zope-plone.vcl In-Reply-To: <7xod7k6h5f.fsf@iostat.linpro.no> References: <77CC09E5-D7E0-460E-BA8A-0813BB0B06D2@digitalmarbles.com> <20080501212142.GA20491@wiggy.net> <481AAB89.8000306@wiggy.net> <6887A325-782F-49B1-AEE2-529363039E71@digitalmarbles.com> <7xod7k6h5f.fsf@iostat.linpro.no> Message-ID: <481F054D.2030603@wiggy.net> Stig Sandbeck Mathisen wrote: > Are there any good reasons not to run Plone with the CacheFu (or > CacheSetup) product installed? Would a non-CacheFu example be of any > use? CacheSetup monkeypatches a fair amount of things, which breaks some innocent third party products. In general my advise would be to never use CacheSetup unless you really need it. Wichert. -- Wichert Akkerman It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. From wichert at wiggy.net Mon May 5 13:06:26 2008 From: wichert at wiggy.net (Wichert Akkerman) Date: Mon, 05 May 2008 15:06:26 +0200 Subject: zope-plone.vcl In-Reply-To: <7xk5i86h19.fsf@iostat.linpro.no> References: <77CC09E5-D7E0-460E-BA8A-0813BB0B06D2@digitalmarbles.com> <20080501212217.GB20491@wiggy.net> <7xk5i86h19.fsf@iostat.linpro.no> Message-ID: <481F0652.2020008@wiggy.net> Stig Sandbeck Mathisen wrote: > On Thu, 1 May 2008 23:22:17 +0200, Wichert Akkerman said: > >> I have some improvements pending for that one as well: a few >> cleanups and switching to url_purge. > > Would it make sense, in vcl_recv, to put the PURGE check inside the > "not GET and not HEAD" block as well? Not sure what it means > performance wise, but it removes one conditional for a normal GET > request. I felt that that made the vcl harder to read. I highly doubt if the performance difference is noticable, or even measurable. Wichert. -- Wichert Akkerman It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. From ric at digitalmarbles.com Mon May 5 17:23:51 2008 From: ric at digitalmarbles.com (Ricardo Newbery) Date: Mon, 5 May 2008 10:23:51 -0700 Subject: zope-plone.vcl In-Reply-To: <481F054D.2030603@wiggy.net> References: <77CC09E5-D7E0-460E-BA8A-0813BB0B06D2@digitalmarbles.com> <20080501212142.GA20491@wiggy.net> <481AAB89.8000306@wiggy.net> <6887A325-782F-49B1-AEE2-529363039E71@digitalmarbles.com> <7xod7k6h5f.fsf@iostat.linpro.no> <481F054D.2030603@wiggy.net> Message-ID: <65D862A8-8080-4F51-9C8E-59A7FD64AB16@digitalmarbles.com> On May 5, 2008, at 6:02 AM, Wichert Akkerman wrote: > Stig Sandbeck Mathisen wrote: >> Are there any good reasons not to run Plone with the CacheFu (or >> CacheSetup) product installed? Would a non-CacheFu example be of any >> use? > > CacheSetup monkeypatches a fair amount of things, which breaks some > innocent > third party products. In general my advise would be to never use > CacheSetup > unless you really need it. > > Wichert. Breaking third-party products is certainly a risk, but to be fair, I'm aware of only a single product so far that conflicts with CacheSetup. While you certainly don't absolutely need CacheFu to take some advantage of Varnish (or Squid), in general my advice is to always use CacheFu unless you've got a good reason not to. But since CacheFu is not currently included in the base Plone install, any example vcl should probably also support the non-CacheFu case. Fixing http://varnish.projects.linpro.no/ticket/236 would help. :-) Ric From brian at briansmith.org Mon May 5 19:12:31 2008 From: brian at briansmith.org (Brian Smith) Date: Mon, 5 May 2008 12:12:31 -0700 Subject: Conditional Requests (revisited) Message-ID: I have several questions regarding conditional requests in Varnish. (I have read many messages in the archives already and I've read as much VCL documentation as I could find.) (1) I have a back-end that is very fast for validating ETags and generating 304 Not Modified, but very slow when it has to return a new response body. My understanding is that Varnish will never send conditional requests to the backend, and it cannot use a 304 response to update the freshness information for an already-cached response. Is that correct? If so, is there a way to do that in VCL? Would you be willing to accept patches to implement that behavior in the core? (2) I would like to cache entities with max-age=0 by using the logic from (1) above to always revalidate the cached representation with the back-end. What is the VCL code for doing this? If this is not possible, would you accept a patch to make this possible? Thanks, Brian From phk at phk.freebsd.dk Mon May 5 19:23:30 2008 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 05 May 2008 19:23:30 +0000 Subject: Conditional Requests (revisited) In-Reply-To: Your message of "Mon, 05 May 2008 12:12:31 MST." Message-ID: <11513.1210015410@critter.freebsd.dk> In message , "Brian Smith" writes: >(1) I have a back-end that is very fast for validating ETags and generating >304 Not Modified, but very slow when it has to return a new response body. >My understanding is that Varnish will never send conditional requests to the >backend, and it cannot use a 304 response to update the freshness >information for an already-cached response. Is that correct? Correct. >If so, is there a way to do that in VCL? Not that I can think off. >Would you be willing to accept patches to implement that behavior in the core? Provided they are well thought out: yes, then all patches are welcome. Think hard about how to enable this sensibly in VCL. >(2) I would like to cache entities with max-age=0 by using the logic from >(1) above to always revalidate the cached representation with the back-end. You can always override the TTL calculation in VCL, but doing the revalidation with the backend is not possible until it gets implemented. >If this is not possible, would you accept a patch to make this possible? As above. -- 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 pcarrier at openfares.com Mon May 5 19:24:04 2008 From: pcarrier at openfares.com (Pierre Fortin Carrier) Date: Mon, 05 May 2008 15:24:04 -0400 Subject: Naive use of regsub to set req.backend Message-ID: <481F5ED4.6030705@openfares.com> Hello, I am currently using Varnish 1.1.2 in front of a load balancer with impressive success. Congratulation for this jewel. I recently got charmed by the idea of using VCL to send some request directly to a specific node (bypassing the LB) for testing purpose. I seek to avoid the advertised method proposed in VCL man page that will lead to too much elsif in my setup. My current attempt seem to lead to a dead end: backend LB { set backend.host = "10.0.0.1"; set backend.port = "8080"; } backend node1 { set backend.host = "10.0.0.10"; set backend.port = "80"; } backend node2 { set backend.host = "10.0.0.20"; set backend.port = "80"; } sub vcl_recv { if (req.http.host ~ "^webapp\.example\.com$") { set req.backend = LB; } elsif (req.http.host ~ "^.+\.webapp\.example\.com$") { set req.backend = regsub(req.http.host, "\.webapp\.example\.com", ""); set req.http.host = "webapp.example.com"; } else { error 404 "This website isn't living here"; { Symptom: Varnish refuse to start and complaint about: varnishExpected ';' got '(' (on the regsub line) >From what I understand I don't understand. Did I missed something obvious here? Any hint would be much appreciated. Thanks, Pierre From phk at phk.freebsd.dk Mon May 5 19:41:16 2008 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 05 May 2008 19:41:16 +0000 Subject: Naive use of regsub to set req.backend In-Reply-To: Your message of "Mon, 05 May 2008 15:24:04 -0400." <481F5ED4.6030705@openfares.com> Message-ID: <11671.1210016476@critter.freebsd.dk> In message <481F5ED4.6030705 at openfares.com>, Pierre Fortin Carrier writes: > backend LB { > set backend.host = "10.0.0.1"; > set backend.port = "8080"; > } > > backend node1 { >[...] > set req.backend = regsub(req.http.host, "\.webapp\.example\.com", ""); The bad news for this approach is that in VCL variables have types. Some variables are time-intervals, obj.ttl for instance, others are backends, like req.backend and some are strings (req.http.*) The reason I have chosen this approach, is that it allows things to be checked much more carefully at compile time. Your example above could lead to a req.backend being set to a backend which was not declared in VCL, resulting in a run-time error when a request happened to hit that condition. With VCL variable typing, that is simply not possible, as you saw. (Admittedly, the error message could be better). I agree that the if elseif elseif elseif... thing can become quite tedious but I don't have a good way to avoid it. I thought about having a way to set the backend to a string and if the string didn't match any of the available backends a default backend would be used (to avoid the run-time error) but it is not obvious to me how useful that would be. -- 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 zegayews at ifi.uio.no Mon May 5 19:49:42 2008 From: zegayews at ifi.uio.no (zegayews at ifi.uio.no) Date: Mon, 5 May 2008 21:49:42 +0200 (CEST) Subject: few questions Message-ID: <1874.129.240.68.227.1210016982.squirrel@webmail.uio.no> Hi, My name is Zegaye Seifu. I am a phd student at the university of Oslo. Currently I am doing a case study research on Varnish. I just would like to ask you the following 4 questions as you are a participant in the mailing list. Your response to these questions is invaluable to what I am researching. Please take few minutes of your precious time and send your responses as soon as you can. 1)How do you come to use or work on Varnish? 2)What motivates you to contribute to the development and/or interact in the mailing list? 3)What have you contributed to Varnish so far (like participiating in questioning, answering, bug fixing or giving patches)? Or if you have suggested any new ideas to the developers? 4)Anything that you would like to say about the software, the developers and the project organization in general? Any problems that you faced? Thank you for taking part in this study. If you would like to ask any questions or want to know about the study, you are most welcome. best regards, zegaye s. From brian at briansmith.org Tue May 6 03:06:19 2008 From: brian at briansmith.org (Brian Smith) Date: Mon, 5 May 2008 20:06:19 -0700 Subject: Conditional Requests (revisited) References: <11513.1210015410@critter.freebsd.dk> Message-ID: <5EAB25ECEC16464DB22845DEE481843F@T60> Poul-Henning Kamp wrote: > Brian Smith writes: > >>(1) I have a back-end that is very fast for validating ETags and >>generating >>304 Not Modified, but very slow when it has to return a new response body. >>My understanding is that Varnish will never send conditional requests to >>the >>backend, and it cannot use a 304 response to update the freshness >>information for an already-cached response. >>Would you be willing to accept patches to implement that behavior in the >>core? > > Provided they are well thought out: yes, then all patches are welcome. > > Think hard about how to enable this sensibly in VCL. I am not sure I will go ahead and implement this but I did think about it a little bit. In VCL, we can run different instructions for a cache hit or a cache miss. As far as I understand, a cache hit occurs whenever Varnish is able to return a response from the cache without contacting the back-end, and a miss occurs otherwise. However, I think a third case is needed: vcl_stale, where there is a cached entry but it is out of date. To me, it seems like Varnish could manage stale hits itself (without running any VCL code), by automatically revalidating with the back-end, processing the response, and then calling the hit VCL or the miss VCL, based on whether the response was a 304. In other words, it seems reasonable to implement this in such a way that there would be no changes to VCL. Do you think that is reasonable? One benefit to doing everthing automatically is that, when we have "varnishd -t 0" and no VCL file, Varnish would become a transparent cache (in the RFC 2616 sense). Even though the developers seem to not find the idea of a transparent cache very compelling, I think such functionality would make Varnish compelling for many more users. Thoughts? Regards, Brian From apokalyptik at apokalyptik.com Tue May 6 21:25:18 2008 From: apokalyptik at apokalyptik.com (Demitrious Kelly) Date: Tue, 06 May 2008 14:25:18 -0700 Subject: Varnish caching issues, cache size, expires, cache resets, whats going on? Message-ID: <4820CCBE.90404@apokalyptik.com> Hello, We have a varnish (varnish-1.1.2) server handling about 2,500 requests per second. The nature of these requests are extraordinarily random, and the disks cannot keep up with the demand, we therefor must keep the cache in RAM. Under highest traffic conditions this generates about 3GB per hour of cached data. The expires on the data being generated are set to a random number of seconds between 1800 and 3600. So theoretically the cache size should never reach more than 4gb or so, well within the servers RAM capacity of 8Gb. What we are seeing however is that the cache will continue to grow to (and beyond if we allow it,) the 8gb mark. At which point we have to invalidate the cache by restarting the processes (naturally this causes the undesired effect of pegging the back-end servers with very high loads until enough data is back in the cache). We have tried limiting the cache size to 7gb, however once the 7gb mark is reached the varnish cache restarts... with the undesired effect of pegging the back-end servers with very high loads until enough data is back in the cache. One definite oddity in our particular usage patterns is that 30% or more of our cached data is comprised of headers, and not content. Currently, for example, varnishstat tells me: 3424095028 743539.36 851553.10 Total header bytes 7830249685 1718569.76 1947338.89 Total body bytes Does anybody have any insight into this behavior? We would like to not have to resort to multiple varnish servers with mickey mouse hacks like staggering restarts to reduce the effect on the back end servers. System details below: --------------------------------------- root at foo.com:~# uname -a Linux foo.com 2.6.18-6-amd64 #1 SMP Sun Feb 10 17:50:19 UTC 2008 x86_64 GNU/Linux root at foo.com:~# free -m total used free shared buffers cached Mem: 7991 4708 3282 0 91 2317 -/+ buffers/cache: 2300 5691 Swap: 0 0 0 root at foo.com:~# cat /proc/cpuinfo | grep -E 'mhz|model name' -i model name : Dual-Core AMD Opteron(tm) Processor 2218 cpu MHz : 2593.784 model name : Dual-Core AMD Opteron(tm) Processor 2218 cpu MHz : 2593.784 model name : Dual-Core AMD Opteron(tm) Processor 2218 cpu MHz : 2593.784 model name : Dual-Core AMD Opteron(tm) Processor 2218 cpu MHz : 2593.784 Start Command: /usr/local/sbin/varnishd -a 0.0.0.0:80 -f /etc/varnish/varnish.vcl -P /var/run/varnishd.pid -T 192.x.x.x:6969 -t 600 -w /etc/varnish/varnish.vcl backend default { set backend.host = "foo.lan"; set backend.port = "http"; } sub vcl_recv { if ( req.url ~ "^/(part1|part2)" && req.http.cookie ) { lookup; } } sub vcl_fetch { if (obj.ttl < 600s) { set obj.ttl = 600s; } if (obj.status == 404) { set obj.ttl = 10s; } if (obj.status == 500 || obj.status == 503) { pass; } insert; } From brian at briansmith.org Tue May 6 22:22:18 2008 From: brian at briansmith.org (Brian Smith) Date: Tue, 6 May 2008 15:22:18 -0700 Subject: Varnish caching issues, cache size, expires, cache resets, whatsgoing on? References: <4820CCBE.90404@apokalyptik.com> Message-ID: <8B206B39A52D4636916EB980FFD7FC8E@T60> Demitrious Kelly wrote: > Does anybody have any insight into this behavior? We would like to not > have to resort to multiple varnish servers with mickey mouse hacks like > staggering restarts to reduce the effect on the back end servers. Maybe a fragmentation issue? When heaps get fragmented then it is common to see the behavior you are experiencing. Try to use the malloc-based storage instead of the mmap-based storage, and experiment with different malloc implementations that are known to be good w.r.t. fragmentation. Regards, Brian From lars at dcmediahosting.com Wed May 7 13:41:44 2008 From: lars at dcmediahosting.com (Lars Erik Dangvard Jensen) Date: Wed, 7 May 2008 15:41:44 +0200 Subject: X-Forwarded-For and Apache 2.2.3 Message-ID: <6E42D545-C4A7-4335-9187-FB8BE46944C7@dcmediahosting.com> Hello list I've been struggling a little with varnish 1.1.2 and apache 2.2.3 and the X-Forwarded-For header. My problem is that the X-Forwarded-For header keeps returning af comma separated list of the same IP like this in the apache log: 123.456.789.101, 123.456.789.101 - - [07/May/2008:15:27:03 +0200] "GET ....etc. The format I wish I could have is: 123.456.789.101 - - [07/May/2008:15:27:03 +0200] "GET ....etc. Without , 123.456.789.101 in the log line. I've used this in my vcl to remove the port number of the first IP in X-Forwarded-For header: remove req.http.X-Forwarded-For; set req.http.X-Forwarded-For = regsub(client.ip, ":.*$", ""); If I do like this: set req.http.X-Forwarded-For = ""; The log looks like: , 123.456.789.101 - - [07/May/2008:15:27:03 +0200] "GET ....etc. I'm not able to figure out how to remove , 123.456.789.101 from the log line. Even though I set the X-Forwarded-For header to nothing through varnish vcl the , 123.456.789.101 is still showing? My apache 2.2.3 logformat is this: LogFormat "%{X-Forwarded-For}i %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" varnishlog Is it because I use varnish and apache on the same server? I'm using Centos 5.1. Any help is appreciated :) /Lars From anders at fupp.net Wed May 7 17:50:40 2008 From: anders at fupp.net (Anders Nordby) Date: Wed, 7 May 2008 19:50:40 +0200 Subject: Varnish caching issues, cache size, expires, cache resets, whats going on? In-Reply-To: <4820CCBE.90404@apokalyptik.com> References: <4820CCBE.90404@apokalyptik.com> Message-ID: <20080507175040.GA36081@fupp.net> Hi, Varnish will only have the most requested objects in RAM, so why is it a problem to have a large cache? I've been trying to run with large data sets for a long time, and have had a lot of problems with it. But it has gotten better, due to Poul-Hennings and also Dag-Erlings help. Did you check the Performance page on the wiki (http://varnish.projects.linpro.no/wiki/Performance), particularly the section about running with many objects? By lowering obj_workspace, you can reduce how much space Varnish uses to fit HTTP headers. You also may want to switch to run trunk instead of 1.1.2. Cheers, Anders. On Tue, May 06, 2008 at 02:25:18PM -0700, Demitrious Kelly wrote: > We have a varnish (varnish-1.1.2) server handling about 2,500 requests > per second. The nature of these requests are extraordinarily random, > and the disks cannot keep up with the demand, we therefor must keep the > cache in RAM. Under highest traffic conditions this generates about 3GB > per hour of cached data. The expires on the data being generated are > set to a random number of seconds between 1800 and 3600. So > theoretically the cache size should never reach more than 4gb or so, > well within the servers RAM capacity of 8Gb. What we are seeing however > is that the cache will continue to grow to (and beyond if we allow it,) > the 8gb mark. At which point we have to invalidate the cache by > restarting the processes (naturally this causes the undesired effect of > pegging the back-end servers with very high loads until enough data is > back in the cache). We have tried limiting the cache size to 7gb, > however once the 7gb mark is reached the varnish cache restarts... with > the undesired effect of pegging the back-end servers with very high > loads until enough data is back in the cache. > > One definite oddity in our particular usage patterns is that 30% or more > of our cached data is comprised of headers, and not content. Currently, > for example, varnishstat tells me: > 3424095028 743539.36 851553.10 Total header bytes > 7830249685 1718569.76 1947338.89 Total body bytes > > Does anybody have any insight into this behavior? We would like to not > have to resort to multiple varnish servers with mickey mouse hacks like > staggering restarts to reduce the effect on the back end servers. > > System details below: > --------------------------------------- > > root at foo.com:~# uname -a > Linux foo.com 2.6.18-6-amd64 #1 SMP Sun Feb 10 17:50:19 UTC 2008 > x86_64 GNU/Linux > > root at foo.com:~# free -m > total used free shared buffers > cached > Mem: 7991 4708 3282 0 91 > 2317 > -/+ buffers/cache: 2300 5691 > Swap: 0 0 0 > > root at foo.com:~# cat /proc/cpuinfo | grep -E 'mhz|model name' -i > model name : Dual-Core AMD Opteron(tm) Processor 2218 > cpu MHz : 2593.784 > model name : Dual-Core AMD Opteron(tm) Processor 2218 > cpu MHz : 2593.784 > model name : Dual-Core AMD Opteron(tm) Processor 2218 > cpu MHz : 2593.784 > model name : Dual-Core AMD Opteron(tm) Processor 2218 > cpu MHz : 2593.784 > > Start Command: > /usr/local/sbin/varnishd -a 0.0.0.0:80 -f /etc/varnish/varnish.vcl > -P /var/run/varnishd.pid -T 192.x.x.x:6969 -t 600 -w > > /etc/varnish/varnish.vcl > backend default { > set backend.host = "foo.lan"; > set backend.port = "http"; > } > > sub vcl_recv { > if ( req.url ~ "^/(part1|part2)" && req.http.cookie ) { > lookup; > } > } > > sub vcl_fetch { > if (obj.ttl < 600s) { > set obj.ttl = 600s; > } > if (obj.status == 404) { > set obj.ttl = 10s; > } > if (obj.status == 500 || obj.status == 503) { > pass; > } > insert; > } > _______________________________________________ > varnish-misc mailing list > varnish-misc at projects.linpro.no > http://projects.linpro.no/mailman/listinfo/varnish-misc -- Anders. From skye at F4.ca Thu May 8 00:46:00 2008 From: skye at F4.ca (Skye Poier Nott) Date: Wed, 7 May 2008 17:46:00 -0700 Subject: Varnish on FreeBSD 6.3 vs 7.0 Message-ID: <478DC3E8-B2D7-44E8-A9FD-04CA806BCB14@F4.ca> Any advantages (performance, stability, resource usage) from running Varnish on FreeBSD 7.0 instead of 6.3? I know they did some work on the threading for 7.0 but maybe it has no relevance to Varnish. Thanks, Skye From phk at phk.freebsd.dk Thu May 8 07:21:43 2008 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Thu, 08 May 2008 07:21:43 +0000 Subject: Varnish on FreeBSD 6.3 vs 7.0 In-Reply-To: Your message of "Wed, 07 May 2008 17:46:00 MST." <478DC3E8-B2D7-44E8-A9FD-04CA806BCB14@F4.ca> Message-ID: <9392.1210231303@critter.freebsd.dk> In message <478DC3E8-B2D7-44E8-A9FD-04CA806BCB14 at F4.ca>, Skye Poier Nott writes : >Any advantages (performance, stability, resource usage) from running >Varnish on FreeBSD 7.0 instead of 6.3? I know they did some work on >the threading for 7.0 but maybe it has no relevance to Varnish. 7.0 has waaay better network performance and SMP scalability. -- 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 Fri May 9 13:19:25 2008 From: duja at torlen.net (duja at torlen.net) Date: Fri, 9 May 2008 15:19:25 +0200 Subject: X-Forwarded-For and Apache 2.2.3 Message-ID: Varnish is handling the X-Forwarded-For header automatically. When you do like this: remove req.http.X-Forwarded-For; set req.http.X-Forwarded-For = ""; Varnish first removes the X-Forwarded-For header and then adds a X-Forwarded-For header that is empty (""). After that varnish uses the default vcl and appends the X-Forwarded-For header with the client ip. There for you get ", 123.456.789.101". Just do like this: remove req.http.X-Forwarded-For; and Varnish should do the rest. / Erik Original Message ----------------------- Hello list I've been struggling a little with varnish 1.1.2 and apache 2.2.3 and the X-Forwarded-For header. My problem is that the X-Forwarded-For header keeps returning af comma separated list of the same IP like this in the apache log: 123.456.789.101, 123.456.789.101 - - [07/May/2008:15:27:03 +0200] "GET ....etc. The format I wish I could have is: 123.456.789.101 - - [07/May/2008:15:27:03 +0200] "GET ....etc. Without , 123.456.789.101 in the log line. I've used this in my vcl to remove the port number of the first IP in X-Forwarded-For header: remove req.http.X-Forwarded-For; set req.http.X-Forwarded-For = regsub(client.ip, ":.*$", ""); If I do like this: set req.http.X-Forwarded-For = ""; The log looks like: , 123.456.789.101 - - [07/May/2008:15:27:03 +0200] "GET ....etc. I'm not able to figure out how to remove , 123.456.789.101 from the log line. Even though I set the X-Forwarded-For header to nothing through varnish vcl the , 123.456.789.101 is still showing? My apache 2.2.3 logformat is this: LogFormat "%{X-Forwarded-For}i %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" varnishlog Is it because I use varnish and apache on the same server? I'm using Centos 5.1. Any help is appreciated :) /Lars _______________________________________________ varnish-misc mailing list varnish-misc at projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc From jt at endpoint.com Fri May 9 18:47:01 2008 From: jt at endpoint.com (JT Justman) Date: Fri, 09 May 2008 11:47:01 -0700 Subject: Second and subsequent ESI includes not cached Message-ID: <48249C25.8060207@endpoint.com> 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 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: varish_esi_case.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: varnish_varnishlog_output.txt URL: From apokalyptik at apokalyptik.com Fri May 9 19:24:15 2008 From: apokalyptik at apokalyptik.com (Demitrious Kelly) Date: Fri, 09 May 2008 12:24:15 -0700 Subject: Varnish caching issues, cache size, expires, cache resets, whatsgoing on? In-Reply-To: <8B206B39A52D4636916EB980FFD7FC8E@T60> References: <4820CCBE.90404@apokalyptik.com> <8B206B39A52D4636916EB980FFD7FC8E@T60> Message-ID: <4824A4DF.1080107@apokalyptik.com> Seems like you might be right. We added 20Gb of swap space, and ran varnish with -s malloc,16G (we have 8Gb ram.) What started happening, though, is that we would hit between 9Gb and 11Gb of memory usage, and varnish would spike the load on the box to 20 (at which point monit restarts it.) This would generally happen in 6-8 hours. So last night I recompiled varnish against googles tcmalloc. Interestingly the memory usage has stayed under 5Gb for 12 hours now, load have been more stable than ever, and it shows no real signs of quitting. This is much more the behavior we want. Also, interestingly, the response is higher than our other server (we have two handling a split load, what I detailed was just one of them, the other is left alone while we tweak this one.) A 1x1 pixel image request coming from the original (which crashes all the time) gets sent in 0.08x seconds, and this one with tcmalloc in 0.11x seconds. I definitely consider 0.03 seconds a price worth stability, but its an interesting observation nonetheless We're going to run it over the weekend and see what happens. If it stays good we'll probably roll it out globally on all of our varnish servers. Thanks for your advice! Cheers! DK Brian Smith wrote: > Demitrious Kelly wrote: >> Does anybody have any insight into this behavior? We would like to not >> have to resort to multiple varnish servers with mickey mouse hacks like >> staggering restarts to reduce the effect on the back end servers. > > Maybe a fragmentation issue? When heaps get fragmented then it is > common to see the behavior you are experiencing. Try to use the > malloc-based storage instead of the mmap-based storage, and experiment > with different malloc implementations that are known to be good w.r.t. > fragmentation. > > Regards, > Brian From johan at jalbum.net Fri May 9 21:00:16 2008 From: johan at jalbum.net (Johan Groundstroem) Date: Fri, 9 May 2008 23:00:16 +0200 Subject: Problem Squid <-> Varnish <-> Tomcat/Jboss Message-ID: <592815A8-EE52-4914-8E84-CC986BC479C2@jalbum.net> Hi all! Been using Varnish in our live environment since a couple of days and it works fine with one weird exception. Really need some fresh input on this one and don't want to move back the deploy. Problem: When Web browsers / Users are behind a Squid or maybe any proxy and connect to our site that is behind the Varnish Proxy <-> Tomcat / Jboss we receive no error just an empty or "white page". Non Proxy users have no problem. Try yourself To try it out take this temp 100% default Squid proxy 195.7.77.4 port 3120 Connect to my two Varnish server they have identical configurations with one exception one connect to Tomcat/Jboss and the other to Orion Server. If you connect to the webservers respectively ip without Varnish it works fine. Varnish servers http://www.jalbum.net (real none working) and http:// flash.jalbum.net (working against Orion App server) They in turn connect to Appservers http://film.jalbum.net and http:// www.ac (no problem to connect to them without the above confirguration) My observations Squid uses HTTP1.0 headers -> Jboss follows standard RFC and sends back 1.1 response Empty white page gives no error whatsoever about seven seconds timeout and nothing, Firebug loaded on Firefox2. Seen below in varnishlog the packet from Jboss is "0" but in Jboss log the packet is "13KB" so Jboss sends the 13KB in HTTP1.1 format somwhere it Varnishes. :) Keep alive disabled on Tomcat no difference This is my config but also tried with default.vcl with no luck. Bellow varnishlog, from user behind proxy and same computer connecting without proxy. # configuration file for lens.jalbum.net backend default { set backend.host = "195.178.163.148"; # Comment flash.jalbum.net has www.ac IP number set backend.port = "80"; } # # Block unwanted clients # acl blacklisted { # "192.168.100.100"; } # # handling of request that are received from clients. # decide whether or not to lookup data in the cache first. # sub vcl_recv { # reject malicious requests call vcl_recv_sentry; # Add a unique header containing the client address remove req.http.X-Forwarded-For; set req.http.X-forwarded-for = regsub(client.ip, ":.*", ""); if (req.request != "GET" && req.request != "HEAD" && req.request != "PUT" && req.request != "POST" && req.request != "TRACE" && req.request != "OPTIONS" && req.request != "DELETE") { # Non-RFC2616 or CONNECT which is weird. pipe; } if (req.http.Expect) { # Expect is just too hard at present. pipe; } if (req.request != "GET" && req.request != "HEAD") { # we only deal with GET and HEAD # note that we need to use "pipe" instead of "pass" here. Pass isn't supported for # POST requests pipe; } if (req.http.Authorization) { # don't cache pages that are protected by basic authentication pass; } if (req.http.Accept-Encoding) { # Handle compression correctly. Varnish treats headers literally, not # semantically. So it is very well possible that there are cache misses # because the headers sent by different browsers aren't the same. # For more info: http:// varnish.projects.linpro.no/wiki/FAQ/Compression if (req.http.Accept-Encoding ~ "gzip") { # if the browser supports it, we'll use gzip set req.http.Accept-Encoding = "gzip"; } elsif (req.http.Accept-Encoding ~ "deflate") { # next, try deflate if it is supported set req.http.Accept-Encoding = "deflate"; } else { # unknown algorithm. Probably junk, remove it remove req.http.Accept-Encoding; } } if (req.url ~ "\.(jpg|jpeg|gif|png|css|js)$") { # allow caching of all images and css/javascript files lookup; } if (req.url ~ "^/resources") { # anything in icons and images is located in resources folder is static and may be cached lookup; } if (req.url ~ "^/forum") { # anything in forum directory is dynamic and should not be cached pass; } if (req.http.Cookie) { # Not cacheable by default # TODO: do we even need this? Can't we simply make sure dynamic # content never exists in the cache? pass; } # every thing else we try to look up in the cache first lookup; } # # Called when entering pipe mode # #sub vcl_pipe { # pipe; #} # # Called when entering pass mode # #sub vcl_pass { # pass; #} # # Called when entering an object into the cache # #sub vcl_hash { # set req.hash += req.url; # if (req.http.host) { # set req.hash += req.http.host; # } else { # set req.hash += req.http.host; # } # hash; #} # # Called when the requested object was found in the cache # sub vcl_hit { if (!obj.cacheable) { # A response is considered cacheable if all of the following are true: # - it is valid # - HTTP status code is 200, 203, 300, 301, 302, 404 or 410 # - it has a non-zero time-to-live when Expires and Cache-Control headers are taken into account. pass; } deliver; } # # Called when the requested object was not found in the cache # #sub vcl_miss { # fetch; #} # # Called when the requested object has been retrieved from the # backend, or the request to the backend has failed # sub vcl_fetch { if (!obj.valid) { # don't cache invalid responses. error; } if (!obj.cacheable) { # A response is considered cacheable if all of the following are true: # - it is valid # - HTTP status code is 200, 203, 300, 301, 302, 404 or 410 # - it has a non-zero time-to-live when Expires and Cache-Control headers are taken into account. # # If a response is not cachable, simply pass it along to the client. pass; } if (obj.http.Set-Cookie) { # don't cache content that sets cookies (eg dynamic PHP pages). pass; } if (obj.http.Pragma ~ "no-cache" || obj.http.Cache-Control ~ "no- cache" || obj.http.Cache-Control ~ "private") { # varnish by default ignores Pragma and Cache-Control headers. It # only looks at the "max-age=" value in the Cache-Control header to # determine the TTL. So we need this rule so that the cache respects # the wishes of the backend application. pass; } if (obj.ttl < 180s) { # force minimum ttl of 180 seconds for all cached objects. set obj.ttl = 180s; } insert; } # # Called before a cached object is delivered to the client # #sub vcl_deliver { # deliver; #} # # Called when an object nears its expiry time # #sub vcl_timeout { # discard; #} # # Called when an object is about to be discarded # #sub vcl_discard { # discard; #} # # Custom routine to detect malicious requests and reject them (called by vcl_recv). # sub vcl_recv_sentry { if (client.ip ~ blacklisted) { error 503 "Your IP has been blocked. Is this an error? Contact hosting at jalbum.net so we can resolve the issue."; } } Varnishlog with User behind Squid proxy (EMPTY WHITE PAGE) [root at lens varnish]# varnishlog -c -o ReqStart 195.7.77.4 28 SessionOpen c 195.7.77.4 44474 28 VCL_acl c NO_MATCH blacklisted 28 ReqStart c 195.7.77.4 44474 113297311 28 RxRequest c GET 28 RxURL c / 28 RxProtocol c HTTP/1.0 28 RxHeader c Host: www.jalbum.net 28 RxHeader c User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; sv-SE; rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14 28 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 28 RxHeader c Accept-Language: sv,en-us;q=0.7,en;q=0.3 28 RxHeader c Accept-Encoding: gzip,deflate 28 RxHeader c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 28 RxHeader c Cookie: __utma=111792799.766322452.1199878250.1210338312.1210344400.307; __utmz=111792799.1209554064.271.10.utmccn=(referral)|utmcsr=alexa.com| utmcct=/data/details/traffic_details/myjalbum.net|utmcmd=referral; AWSUSER_ID=awsuser_id1205913287048r3497; __ut 28 RxHeader c Via: 1.1 zaphod.frd.net:3120 (squid/2.6.STABLE13) 28 RxHeader c X-Forwarded-For: 83.250.202.38 28 RxHeader c Cache-Control: max-age=0 28 RxHeader c Connection: keep-alive 28 VCL_call c recv pass 28 VCL_call c pass pass 28 Backend c 30 default 28 ObjProtocol c HTTP/1.1 28 ObjStatus c 200 28 ObjResponse c OK 28 ObjHeader c Server: Apache-Coyote/1.1 28 ObjHeader c X-Powered-By: Servlet 2.4; JBoss-4.2.2.GA (build: SVNTag=JBoss_4_2_2_GA date=200710221139)/Tomcat-5.5 28 ObjHeader c Pragma: no-cache 28 ObjHeader c Cache-Control: no-cache, max-age=0, must- revalidate 28 ObjHeader c Content-Type: text/html;charset=UTF-8 28 ObjHeader c Content-Language: en 28 ObjHeader c Date: Fri, 09 May 2008 15:38:59 GMT 28 TTL c 113297311 RFC 0 1210347540 1210347539 0 0 0 28 VCL_call c fetch pass 28 Length c 0 28 VCL_call c deliver deliver 28 TxProtocol c HTTP/1.1 28 TxStatus c 200 28 TxResponse c OK 28 TxHeader c Server: Apache-Coyote/1.1 28 TxHeader c X-Powered-By: Servlet 2.4; JBoss-4.2.2.GA (build: SVNTag=JBoss_4_2_2_GA date=200710221139)/Tomcat-5.5 28 TxHeader c Pragma: no-cache 28 TxHeader c Cache-Control: no-cache, max-age=0, must- revalidate 28 TxHeader c Content-Type: text/html;charset=UTF-8 28 TxHeader c Content-Language: en 28 TxHeader c Date: Fri, 09 May 2008 15:39:00 GMT 28 TxHeader c X-Varnish: 113297311 28 TxHeader c Age: 0 28 TxHeader c Via: 1.1 varnish 28 TxHeader c Connection: keep-alive 28 ReqEnd c 113297311 1210347540.178735018 1210347540.205344677 0.000169039 0.026588202 0.000021458 Varnislog from client without Squid Proxy (WORKS) [root at lens varnish]# vi /etc/varnish/default.vcl [root at lens varnish]# varnishlog -c -o ReqStart 83.250.202.38 24 SessionOpen c 83.250.202.38 37745 24 VCL_acl c NO_MATCH blacklisted 24 ReqStart c 83.250.202.38 37745 113301121 24 RxRequest c GET 24 RxURL c / 24 RxProtocol c HTTP/1.1 24 RxHeader c Host: www.jalbum.net 24 RxHeader c User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; sv; rv:1.8.1.9) Gecko/20071025 Camino/1.5.3 (MultiLang) 24 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 24 RxHeader c Accept-Language: sv,en- US;q=0.9,en;q=0.9,ja;q=0.8,fr;q=0.8,de;q=0.7,es;q=0.6,it;q=0.6,nl;q=0.5, nb;q=0.5,da;q=0.4,fi;q=0.4,pt;q=0.3,zh-Hans;q=0.2,zh- Hant;q=0.2,ko;q=0.1,ru;q=0.1 24 RxHeader c Accept-Encoding: gzip,deflate 24 RxHeader c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 24 RxHeader c Keep-Alive: 300 24 RxHeader c Connection: keep-alive 24 RxHeader c Cookie: __utmz=111792799.1206546583.381.11.utmccn=(organic)|utmcsr=google| utmctr=laza%20jalbum|utmcmd=organic; __utma=111792799.953560163.1191150829.1210339564.1210347506.429; AWSUSER_ID=awsuser_id1205324466107r1647; JSESSIONID=107B95BB3DFEB970B89930C4B39 24 VCL_call c recv pass 24 VCL_call c pass pass 24 Backend c 31 default 24 ObjProtocol c HTTP/1.1 24 ObjStatus c 200 24 ObjResponse c OK 24 ObjHeader c Server: Apache-Coyote/1.1 24 ObjHeader c X-Powered-By: Servlet 2.4; JBoss-4.2.2.GA (build: SVNTag=JBoss_4_2_2_GA date=200710221139)/Tomcat-5.5 24 ObjHeader c Pragma: no-cache 24 ObjHeader c Cache-Control: no-cache, max-age=0, must- revalidate 24 ObjHeader c Content-Type: text/html;charset=UTF-8 24 ObjHeader c Content-Language: en 24 ObjHeader c Date: Fri, 09 May 2008 15:42:40 GMT 24 TTL c 113301121 RFC 0 1210347761 1210347760 0 0 0 24 VCL_call c fetch pass 24 Length c 13714 24 VCL_call c deliver deliver 24 TxProtocol c HTTP/1.1 24 TxStatus c 200 24 TxResponse c OK 24 TxHeader c Server: Apache-Coyote/1.1 24 TxHeader c X-Powered-By: Servlet 2.4; JBoss-4.2.2.GA (build: SVNTag=JBoss_4_2_2_GA date=200710221139)/Tomcat-5.5 24 TxHeader c Pragma: no-cache 24 TxHeader c Cache-Control: no-cache, max-age=0, must- revalidate 24 TxHeader c Content-Type: text/html;charset=UTF-8 24 TxHeader c Content-Language: en 24 TxHeader c Content-Length: 13714 24 TxHeader c Date: Fri, 09 May 2008 15:42:41 GMT 24 TxHeader c X-Varnish: 113301121 24 TxHeader c Age: 0 24 TxHeader c Via: 1.1 varnish 24 TxHeader c Connection: keep-alive 24 ReqEnd c 113301121 1210347761.823969126 1210347761.852042675 0.000282764 0.028034925 0.000038624 24 VCL_acl c NO_MATCH blacklisted 24 ReqStart c 83.250.202.38 37745 113301122 24 RxRequest c GET 24 RxURL c /resources/org.apache.wicket.Application/ albumIcon?type=FEATURED&id=10595 24 RxProtocol c HTTP/1.1 24 RxHeader c Host: www.jalbum.net 24 RxHeader c User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; sv; rv:1.8.1.9) Gecko/20071025 Camino/1.5.3 (MultiLang) 24 RxHeader c Accept: image/png,*/*;q=0.5 24 RxHeader c Accept-Language: sv,en- US;q=0.9,en;q=0.9,ja;q=0.8,fr;q=0.8,de;q=0.7,es;q=0.6,it;q=0.6,nl;q=0.5, nb;q=0.5,da;q=0.4,fi;q=0.4,pt;q=0.3,zh-Hans;q=0.2,zh- Hant;q=0.2,ko;q=0.1,ru;q=0.1 24 RxHeader c Accept-Encoding: gzip,deflate 24 RxHeader c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 24 RxHeader c Keep-Alive: 300 24 RxHeader c Connection: keep-alive 24 RxHeader c Referer: http://www.jalbum.net/ 24 RxHeader c Cookie: __utmz=111792799.1206546583.381.11.utmccn=(organic)|utmcsr=google| utmctr=laza%20jalbum|utmcmd=organic; __utma=111792799.953560163.1191150829.1210339564.1210347506.429; AWSUSER_ID=awsuser_id1205324466107r1647; JSESSIONID=107B95BB3DFEB970B89930C4B39 24 VCL_call c recv lookup 24 VCL_call c hash hash 24 Hit c 113298334 24 VCL_call c hit deliver 24 Length c 38575 24 VCL_call c deliver deliver 24 TxProtocol c HTTP/1.1 24 TxStatus c 200 24 TxResponse c OK 24 TxHeader c Server: Apache-Coyote/1.1 24 TxHeader c X-Powered-By: Servlet 2.4; JBoss-4.2.2.GA (build: SVNTag=JBoss_4_2_2_GA date=200710221139)/Tomcat-5.5 24 TxHeader c Last-Modified: Fri, 09 May 2008 15:40:03 GMT 24 TxHeader c Expires: Fri, 09 May 2008 16:40:03 GMT 24 TxHeader c Cache-Control: max-age=3600 24 TxHeader c Content-Type: image/jpg 24 TxHeader c Content-Length: 38575 24 TxHeader c Date: Fri, 09 May 2008 15:42:41 GMT 24 TxHeader c X-Varnish: 113301122 113298334 24 TxHeader c Age: 158 24 TxHeader c Via: 1.1 varnish 24 TxHeader c Connection: keep-alive 24 ReqEnd c 113301122 1210347761.947785378 1210347761.947865009 0.095742702 0.000027180 0.000052452 32 SessionOpen c 83.250.202.38 37746 32 VCL_acl c NO_MATCH blacklisted 32 ReqStart c 83.250.202.38 37746 113301123 32 RxRequest c GET 32 RxURL c /resources/org.apache.wicket.Application/ userIcon?type=MINI 32 RxProtocol c HTTP/1.1 32 RxHeader c Host: www.jalbum.net 32 RxHeader c User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; sv; rv:1.8.1.9) Gecko/20071025 Camino/1.5.3 (MultiLang) 32 RxHeader c Accept: image/png,*/*;q=0.5 32 RxHeader c Accept-Language: sv,en- US;q=0.9,en;q=0.9,ja;q=0.8,fr;q=0.8,de;q=0.7,es;q=0.6,it;q=0.6,nl;q=0.5, nb;q=0.5,da;q=0.4,fi;q=0.4,pt;q=0.3,zh-Hans;q=0.2,zh- Hant;q=0.2,ko;q=0.1,ru;q=0.1 32 RxHeader c Accept-Encoding: gzip,deflate 32 RxHeader c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 32 RxHeader c Keep-Alive: 300 32 RxHeader c Connection: keep-alive 32 RxHeader c Referer: http://www.jalbum.net/ 32 RxHeader c Cookie: __utmz=111792799.1206546583.381.11.utmccn=(organic)|utmcsr=google| utmctr=laza%20jalbum|utmcmd=organic; __utma=111792799.953560163.1191150829.1210339564.1210347506.429; AWSUSER_ID=awsuser_id1205324466107r1647; JSESSIONID=107B95BB3DFEB970B89930C4B39 32 RxHeader c If-Modified-Since: Fri, 09 May 2008 12:46:57 GMT 32 VCL_call c recv lookup 32 VCL_call c hash hash 32 Hit c 113297190 32 VCL_call c hit deliver 32 Length c 915 32 VCL_call c deliver deliver 32 TxProtocol c HTTP/1.1 32 TxStatus c 200 32 TxResponse c OK 32 TxHeader c Server: Apache-Coyote/1.1 32 TxHeader c X-Powered-By: Servlet 2.4; JBoss-4.2.2.GA (build: SVNTag=JBoss_4_2_2_GA date=200710221139)/Tomcat-5.5 32 TxHeader c Last-Modified: Fri, 09 May 2008 15:38:47 GMT 32 TxHeader c Expires: Fri, 09 May 2008 16:38:47 GMT 32 TxHeader c Cache-Control: max-age=3600 32 TxHeader c Content-Type: image/jpg 32 TxHeader c Content-Length: 915 32 TxHeader c Date: Fri, 09 May 2008 15:42:41 GMT 32 TxHeader c X-Varnish: 113301123 113297190 32 TxHeader c Age: 234 32 TxHeader c Via: 1.1 varnish 32 TxHeader c Connection: keep-alive 32 ReqEnd c 113301123 1210347761.958240986 1210347761.958292484 0.000283718 0.000022411 0.000029087 32 VCL_acl c NO_MATCH blacklisted 32 ReqStart c 83.250.202.38 37746 113301124 32 RxRequest c GET 32 RxURL c /js/awstats_misc_tracker.js? screen=1920x1200&win=1265x656&cdi=32&java=true&shk=n&svg=y&fla=y&rp=y&mo v=n&wma=y&pdf=undefined&uid=awsuser_id1205324466107r1647&sid=awssession_ id1210347505409r3136 32 RxProtocol c HTTP/1.1 32 RxHeader c Host: www.jalbum.net 32 RxHeader c User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; sv; rv:1.8.1.9) Gecko/20071025 Camino/1.5.3 (MultiLang) 32 RxHeader c Accept: image/png,*/*;q=0.5 32 RxHeader c Accept-Language: sv,en- US;q=0.9,en;q=0.9,ja;q=0.8,fr;q=0.8,de;q=0.7,es;q=0.6,it;q=0.6,nl;q=0.5, nb;q=0.5,da;q=0.4,fi;q=0.4,pt;q=0.3,zh-Hans;q=0.2,zh- Hant;q=0.2,ko;q=0.1,ru;q=0.1 32 RxHeader c Accept-Encoding: gzip,deflate 32 RxHeader c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 32 RxHeader c Keep-Alive: 300 32 RxHeader c Connection: keep-alive 32 RxHeader c Referer: http://www.jalbum.net/ 32 RxHeader c Cookie: __utmz=111792799.1206546583.381.11.utmccn=(organic)|utmcsr=google| utmctr=laza%20jalbum|utmcmd=organic; __utma=111792799.953560163.1191150829.1210339564.1210347506.429; AWSUSER_ID=awsuser_id1205324466107r1647; JSESSIONID=107B95BB3DFEB970B89930C4B39 32 VCL_call c recv pass 32 VCL_call c pass pass 32 Backend c 23 default 32 ObjProtocol c HTTP/1.1 32 ObjStatus c 200 32 ObjResponse c OK 32 ObjHeader c Server: Apache-Coyote/1.1 32 ObjHeader c X-Powered-By: Servlet 2.4; JBoss-4.2.2.GA (build: SVNTag=JBoss_4_2_2_GA date=200710221139)/Tomcat-5.5 32 ObjHeader c ETag: W/"7623-1210254928000" 32 ObjHeader c Last-Modified: Thu, 08 May 2008 13:55:28 GMT 32 ObjHeader c Content-Type: text/javascript 32 ObjHeader c Date: Fri, 09 May 2008 15:42:41 GMT 32 TTL c 113301124 RFC 120 1210347761 1210347761 0 0 0 32 VCL_call c fetch 32 TTL c 113301124 VCL 180 1210347762 32 VCL_return c insert 32 Length c 7623 32 VCL_call c deliver deliver 32 TxProtocol c HTTP/1.1 32 TxStatus c 200 32 TxResponse c OK 32 TxHeader c Server: Apache-Coyote/1.1 32 TxHeader c X-Powered-By: Servlet 2.4; JBoss-4.2.2.GA (build: SVNTag=JBoss_4_2_2_GA date=200710221139)/Tomcat-5.5 32 TxHeader c ETag: W/"7623-1210254928000" 32 TxHeader c Last-Modified: Thu, 08 May 2008 13:55:28 GMT 32 TxHeader c Content-Type: text/javascript 32 TxHeader c Content-Length: 7623 32 TxHeader c Date: Fri, 09 May 2008 15:42:41 GMT 32 TxHeader c X-Varnish: 113301124 32 TxHeader c Age: 0 32 TxHeader c Via: 1.1 varnish 32 TxHeader c Connection: keep-alive 32 ReqEnd c 113301124 1210347761.993350506 1210347761.995301247 0.035058022 0.001917601 0.000033140 24 VCL_acl c NO_MATCH blacklisted 24 ReqStart c 83.250.202.38 37745 113301125 24 RxRequest c GET 24 RxURL c /js/mailto.js.jsp?a=the%20new%20site&b=] jalbum.net&c=Comment%20on%20&d=feedback[at 24 RxProtocol c HTTP/1.1 24 RxHeader c Host: www.jalbum.net 24 RxHeader c User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; sv; rv:1.8.1.9) Gecko/20071025 Camino/1.5.3 (MultiLang) 24 RxHeader c Accept: */* 24 RxHeader c Accept-Language: sv,en- US;q=0.9,en;q=0.9,ja;q=0.8,fr;q=0.8,de;q=0.7,es;q=0.6,it;q=0.6,nl;q=0.5, nb;q=0.5,da;q=0.4,fi;q=0.4,pt;q=0.3,zh-Hans;q=0.2,zh- Hant;q=0.2,ko;q=0.1,ru;q=0.1 24 RxHeader c Accept-Encoding: gzip,deflate 24 RxHeader c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 24 RxHeader c Keep-Alive: 300 24 RxHeader c Connection: keep-alive 24 RxHeader c Referer: http://www.jalbum.net/ 24 RxHeader c Cookie: __utmz=111792799.1206546583.381.11.utmccn=(organic)|utmcsr=google| utmctr=laza%20jalbum|utmcmd=organic; __utma=111792799.953560163.1191150829.1210339564.1210347506.429; AWSUSER_ID=awsuser_id1205324466107r1647; JSESSIONID=107B95BB3DFEB970B89930C4B39 24 VCL_call c recv pass 24 VCL_call c pass pass 24 Backend c 23 default 24 ObjProtocol c HTTP/1.1 24 ObjStatus c 200 24 ObjResponse c OK 24 ObjHeader c Server: Apache-Coyote/1.1 24 ObjHeader c X-Powered-By: Servlet 2.4; JBoss-4.2.2.GA (build: SVNTag=JBoss_4_2_2_GA date=200710221139)/Tomcat-5.5 24 ObjHeader c Content-Type: text/javascript;charset=ISO-8859-1 24 ObjHeader c Date: Fri, 09 May 2008 15:42:41 GMT 24 TTL c 113301125 RFC 120 1210347762 1210347761 0 0 0 24 VCL_call c fetch 24 TTL c 113301125 VCL 180 1210347762 24 VCL_return c insert 24 Length c 69 24 VCL_call c deliver deliver 24 TxProtocol c HTTP/1.1 24 TxStatus c 200 24 TxResponse c OK 24 TxHeader c Server: Apache-Coyote/1.1 24 TxHeader c X-Powered-By: Servlet 2.4; JBoss-4.2.2.GA (build: SVNTag=JBoss_4_2_2_GA date=200710221139)/Tomcat-5.5 24 TxHeader c Content-Type: text/javascript;charset=ISO-8859-1 24 TxHeader c Content-Length: 69 24 TxHeader c Date: Fri, 09 May 2008 15:42:42 GMT 24 TxHeader c X-Varnish: 113301125 24 TxHeader c Age: 0 24 TxHeader c Via: 1.1 varnish 24 TxHeader c Connection: keep-alive 24 ReqEnd c 113301125 1210347762.009387732 1210347762.010314703 0.061522722 0.000905991 0.000020981 [root at lens varnish]# From fredrik.nygren at gotamedia.se Sat May 10 06:45:31 2008 From: fredrik.nygren at gotamedia.se (Fredrik Nygren) Date: Sat, 10 May 2008 08:45:31 +0200 Subject: Problem Squid <-> Varnish <-> Tomcat/Jboss In-Reply-To: <592815A8-EE52-4914-8E84-CC986BC479C2@jalbum.net> References: <592815A8-EE52-4914-8E84-CC986BC479C2@jalbum.net> Message-ID: <7F6E55C9-7C67-4101-9881-B333711F35C0@gotamedia.se> I have seen the same problem in my environment. When I upgrade to the latest trunk it disappered. Here are some earlier post about the blank page problem: http://projects.linpro.no/pipermail/varnish-misc/2008-February/001429.html http://projects.linpro.no/pipermail/varnish-dist/2008-February/000075.html Regards On 9 maj 2008, at 23.00, Johan Groundstroem wrote: Hi all! Been using Varnish in our live environment since a couple of days and it works fine with one weird exception. Really need some fresh input on this one and don't want to move back the deploy. Problem: When Web browsers / Users are behind a Squid or maybe any proxy and connect to our site that is behind the Varnish Proxy <-> Tomcat / Jboss we receive no error just an empty or "white page". Non Proxy users have no problem. Try yourself To try it out take this temp 100% default Squid proxy 195.7.77.4 port 3120 Connect to my two Varnish server they have identical configurations with one exception one connect to Tomcat/Jboss and the other to Orion Server. If you connect to the webservers respectively ip without Varnish it works fine. Varnish servers http://www.jalbum.net (real none working) and http:// flash.jalbum.net (working against Orion App server) They in turn connect to Appservers http://film.jalbum.net and http:// www.ac (no problem to connect to them without the above confirguration) My observations Squid uses HTTP1.0 headers -> Jboss follows standard RFC and sends back 1.1 response Empty white page gives no error whatsoever about seven seconds timeout and nothing, Firebug loaded on Firefox2. Seen below in varnishlog the packet from Jboss is "0" but in Jboss log the packet is "13KB" so Jboss sends the 13KB in HTTP1.1 format somwhere it Varnishes. :) Keep alive disabled on Tomcat no difference This is my config but also tried with default.vcl with no luck. Bellow varnishlog, from user behind proxy and same computer connecting without proxy. # configuration file for lens.jalbum.net backend default { set backend.host = "195.178.163.148"; # Comment flash.jalbum.net has www.ac IP number set backend.port = "80"; } # # Block unwanted clients # acl blacklisted { # "192.168.100.100"; } # # handling of request that are received from clients. # decide whether or not to lookup data in the cache first. # sub vcl_recv { # reject malicious requests call vcl_recv_sentry; # Add a unique header containing the client address remove req.http.X-Forwarded-For; set req.http.X-forwarded-for = regsub(client.ip, ":.*", ""); if (req.request != "GET" && req.request != "HEAD" && req.request != "PUT" && req.request != "POST" && req.request != "TRACE" && req.request != "OPTIONS" && req.request != "DELETE") { # Non-RFC2616 or CONNECT which is weird. pipe; } if (req.http.Expect) { # Expect is just too hard at present. pipe; } if (req.request != "GET" && req.request != "HEAD") { # we only deal with GET and HEAD # note that we need to use "pipe" instead of "pass" here. Pass isn't supported for # POST requests pipe; } if (req.http.Authorization) { # don't cache pages that are protected by basic authentication pass; } if (req.http.Accept-Encoding) { # Handle compression correctly. Varnish treats headers literally, not # semantically. So it is very well possible that there are cache misses # because the headers sent by different browsers aren't the same. # For more info: http:// varnish.projects.linpro.no/wiki/FAQ/Compression if (req.http.Accept-Encoding ~ "gzip") { # if the browser supports it, we'll use gzip set req.http.Accept-Encoding = "gzip"; } elsif (req.http.Accept-Encoding ~ "deflate") { # next, try deflate if it is supported set req.http.Accept-Encoding = "deflate"; } else { # unknown algorithm. Probably junk, remove it remove req.http.Accept-Encoding; } } if (req.url ~ "\.(jpg|jpeg|gif|png|css|js)$") { # allow caching of all images and css/javascript files lookup; } if (req.url ~ "^/resources") { # anything in icons and images is located in resources folder is static and may be cached lookup; } if (req.url ~ "^/forum") { # anything in forum directory is dynamic and should not be cached pass; } if (req.http.Cookie) { # Not cacheable by default # TODO: do we even need this? Can't we simply make sure dynamic # content never exists in the cache? pass; } # every thing else we try to look up in the cache first lookup; } # # Called when entering pipe mode # #sub vcl_pipe { # pipe; #} # # Called when entering pass mode # #sub vcl_pass { # pass; #} # # Called when entering an object into the cache # #sub vcl_hash { # set req.hash += req.url; # if (req.http.host) { # set req.hash += req.http.host; # } else { # set req.hash += req.http.host; # } # hash; #} # # Called when the requested object was found in the cache # sub vcl_hit { if (!obj.cacheable) { # A response is considered cacheable if all of the following are true: # - it is valid # - HTTP status code is 200, 203, 300, 301, 302, 404 or 410 # - it has a non-zero time-to-live when Expires and Cache-Control headers are taken into account. pass; } deliver; } # # Called when the requested object was not found in the cache # #sub vcl_miss { # fetch; #} # # Called when the requested object has been retrieved from the # backend, or the request to the backend has failed # sub vcl_fetch { if (!obj.valid) { # don't cache invalid responses. error; } if (!obj.cacheable) { # A response is considered cacheable if all of the following are true: # - it is valid # - HTTP status code is 200, 203, 300, 301, 302, 404 or 410 # - it has a non-zero time-to-live when Expires and Cache-Control headers are taken into account. # # If a response is not cachable, simply pass it along to the client. pass; } if (obj.http.Set-Cookie) { # don't cache content that sets cookies (eg dynamic PHP pages). pass; } if (obj.http.Pragma ~ "no-cache" || obj.http.Cache-Control ~ "no- cache" || obj.http.Cache-Control ~ "private") { # varnish by default ignores Pragma and Cache-Control headers. It # only looks at the "max-age=" value in the Cache-Control header to # determine the TTL. So we need this rule so that the cache respects # the wishes of the backend application. pass; } if (obj.ttl < 180s) { # force minimum ttl of 180 seconds for all cached objects. set obj.ttl = 180s; } insert; } # # Called before a cached object is delivered to the client # #sub vcl_deliver { # deliver; #} # # Called when an object nears its expiry time # #sub vcl_timeout { # discard; #} # # Called when an object is about to be discarded # #sub vcl_discard { # discard; #} # # Custom routine to detect malicious requests and reject them (called by vcl_recv). # sub vcl_recv_sentry { if (client.ip ~ blacklisted) { error 503 "Your IP has been blocked. Is this an error? Contact hosting at jalbum.net so we can resolve the issue."; } } Varnishlog with User behind Squid proxy (EMPTY WHITE PAGE) [root at lens varnish]# varnishlog -c -o ReqStart 195.7.77.4 28 SessionOpen c 195.7.77.4 44474 28 VCL_acl c NO_MATCH blacklisted 28 ReqStart c 195.7.77.4 44474 113297311 28 RxRequest c GET 28 RxURL c / 28 RxProtocol c HTTP/1.0 28 RxHeader c Host: www.jalbum.net 28 RxHeader c User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; sv-SE; rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14 28 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 28 RxHeader c Accept-Language: sv,en-us;q=0.7,en;q=0.3 28 RxHeader c Accept-Encoding: gzip,deflate 28 RxHeader c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 28 RxHeader c Cookie: __utma=111792799.766322452.1199878250.1210338312.1210344400.307; __utmz=111792799.1209554064.271.10.utmccn=(referral)|utmcsr=alexa.com| utmcct=/data/details/traffic_details/myjalbum.net|utmcmd=referral; AWSUSER_ID=awsuser_id1205913287048r3497; __ut 28 RxHeader c Via: 1.1 zaphod.frd.net:3120 (squid/2.6.STABLE13) 28 RxHeader c X-Forwarded-For: 83.250.202.38 28 RxHeader c Cache-Control: max-age=0 28 RxHeader c Connection: keep-alive 28 VCL_call c recv pass 28 VCL_call c pass pass 28 Backend c 30 default 28 ObjProtocol c HTTP/1.1 28 ObjStatus c 200 28 ObjResponse c OK 28 ObjHeader c Server: Apache-Coyote/1.1 28 ObjHeader c X-Powered-By: Servlet 2.4; JBoss-4.2.2.GA (build: SVNTag=JBoss_4_2_2_GA date=200710221139)/Tomcat-5.5 28 ObjHeader c Pragma: no-cache 28 ObjHeader c Cache-Control: no-cache, max-age=0, must- revalidate 28 ObjHeader c Content-Type: text/html;charset=UTF-8 28 ObjHeader c Content-Language: en 28 ObjHeader c Date: Fri, 09 May 2008 15:38:59 GMT 28 TTL c 113297311 RFC 0 1210347540 1210347539 0 0 0 28 VCL_call c fetch pass 28 Length c 0 28 VCL_call c deliver deliver 28 TxProtocol c HTTP/1.1 28 TxStatus c 200 28 TxResponse c OK 28 TxHeader c Server: Apache-Coyote/1.1 28 TxHeader c X-Powered-By: Servlet 2.4; JBoss-4.2.2.GA (build: SVNTag=JBoss_4_2_2_GA date=200710221139)/Tomcat-5.5 28 TxHeader c Pragma: no-cache 28 TxHeader c Cache-Control: no-cache, max-age=0, must- revalidate 28 TxHeader c Content-Type: text/html;charset=UTF-8 28 TxHeader c Content-Language: en 28 TxHeader c Date: Fri, 09 May 2008 15:39:00 GMT 28 TxHeader c X-Varnish: 113297311 28 TxHeader c Age: 0 28 TxHeader c Via: 1.1 varnish 28 TxHeader c Connection: keep-alive 28 ReqEnd c 113297311 1210347540.178735018 1210347540.205344677 0.000169039 0.026588202 0.000021458 Varnislog from client without Squid Proxy (WORKS) [root at lens varnish]# vi /etc/varnish/default.vcl [root at lens varnish]# varnishlog -c -o ReqStart 83.250.202.38 24 SessionOpen c 83.250.202.38 37745 24 VCL_acl c NO_MATCH blacklisted 24 ReqStart c 83.250.202.38 37745 113301121 24 RxRequest c GET 24 RxURL c / 24 RxProtocol c HTTP/1.1 24 RxHeader c Host: www.jalbum.net 24 RxHeader c User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; sv; rv:1.8.1.9) Gecko/20071025 Camino/1.5.3 (MultiLang) 24 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 24 RxHeader c Accept-Language: sv,en- US;q=0.9,en;q=0.9,ja;q=0.8,fr;q=0.8,de;q=0.7,es;q=0.6,it;q=0.6,nl;q=0.5, nb;q=0.5,da;q=0.4,fi;q=0.4,pt;q=0.3,zh-Hans;q=0.2,zh- Hant;q=0.2,ko;q=0.1,ru;q=0.1 24 RxHeader c Accept-Encoding: gzip,deflate 24 RxHeader c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 24 RxHeader c Keep-Alive: 300 24 RxHeader c Connection: keep-alive 24 RxHeader c Cookie: __utmz=111792799.1206546583.381.11.utmccn=(organic)|utmcsr=google| utmctr=laza%20jalbum|utmcmd=organic; __utma=111792799.953560163.1191150829.1210339564.1210347506.429; AWSUSER_ID=awsuser_id1205324466107r1647; JSESSIONID=107B95BB3DFEB970B89930C4B39 24 VCL_call c recv pass 24 VCL_call c pass pass 24 Backend c 31 default 24 ObjProtocol c HTTP/1.1 24 ObjStatus c 200 24 ObjResponse c OK 24 ObjHeader c Server: Apache-Coyote/1.1 24 ObjHeader c X-Powered-By: Servlet 2.4; JBoss-4.2.2.GA (build: SVNTag=JBoss_4_2_2_GA date=200710221139)/Tomcat-5.5 24 ObjHeader c Pragma: no-cache 24 ObjHeader c Cache-Control: no-cache, max-age=0, must- revalidate 24 ObjHeader c Content-Type: text/html;charset=UTF-8 24 ObjHeader c Content-Language: en 24 ObjHeader c Date: Fri, 09 May 2008 15:42:40 GMT 24 TTL c 113301121 RFC 0 1210347761 1210347760 0 0 0 24 VCL_call c fetch pass 24 Length c 13714 24 VCL_call c deliver deliver 24 TxProtocol c HTTP/1.1 24 TxStatus c 200 24 TxResponse c OK 24 TxHeader c Server: Apache-Coyote/1.1 24 TxHeader c X-Powered-By: Servlet 2.4; JBoss-4.2.2.GA (build: SVNTag=JBoss_4_2_2_GA date=200710221139)/Tomcat-5.5 24 TxHeader c Pragma: no-cache 24 TxHeader c Cache-Control: no-cache, max-age=0, must- revalidate 24 TxHeader c Content-Type: text/html;charset=UTF-8 24 TxHeader c Content-Language: en 24 TxHeader c Content-Length: 13714 24 TxHeader c Date: Fri, 09 May 2008 15:42:41 GMT 24 TxHeader c X-Varnish: 113301121 24 TxHeader c Age: 0 24 TxHeader c Via: 1.1 varnish 24 TxHeader c Connection: keep-alive 24 ReqEnd c 113301121 1210347761.823969126 1210347761.852042675 0.000282764 0.028034925 0.000038624 24 VCL_acl c NO_MATCH blacklisted 24 ReqStart c 83.250.202.38 37745 113301122 24 RxRequest c GET 24 RxURL c /resources/org.apache.wicket.Application/ albumIcon?type=FEATURED&id=10595 24 RxProtocol c HTTP/1.1 24 RxHeader c Host: www.jalbum.net 24 RxHeader c User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; sv; rv:1.8.1.9) Gecko/20071025 Camino/1.5.3 (MultiLang) 24 RxHeader c Accept: image/png,*/*;q=0.5 24 RxHeader c Accept-Language: sv,en- US;q=0.9,en;q=0.9,ja;q=0.8,fr;q=0.8,de;q=0.7,es;q=0.6,it;q=0.6,nl;q=0.5, nb;q=0.5,da;q=0.4,fi;q=0.4,pt;q=0.3,zh-Hans;q=0.2,zh- Hant;q=0.2,ko;q=0.1,ru;q=0.1 24 RxHeader c Accept-Encoding: gzip,deflate 24 RxHeader c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 24 RxHeader c Keep-Alive: 300 24 RxHeader c Connection: keep-alive 24 RxHeader c Referer: http://www.jalbum.net/ 24 RxHeader c Cookie: __utmz=111792799.1206546583.381.11.utmccn=(organic)|utmcsr=google| utmctr=laza%20jalbum|utmcmd=organic; __utma=111792799.953560163.1191150829.1210339564.1210347506.429; AWSUSER_ID=awsuser_id1205324466107r1647; JSESSIONID=107B95BB3DFEB970B89930C4B39 24 VCL_call c recv lookup 24 VCL_call c hash hash 24 Hit c 113298334 24 VCL_call c hit deliver 24 Length c 38575 24 VCL_call c deliver deliver 24 TxProtocol c HTTP/1.1 24 TxStatus c 200 24 TxResponse c OK 24 TxHeader c Server: Apache-Coyote/1.1 24 TxHeader c X-Powered-By: Servlet 2.4; JBoss-4.2.2.GA (build: SVNTag=JBoss_4_2_2_GA date=200710221139)/Tomcat-5.5 24 TxHeader c Last-Modified: Fri, 09 May 2008 15:40:03 GMT 24 TxHeader c Expires: Fri, 09 May 2008 16:40:03 GMT 24 TxHeader c Cache-Control: max-age=3600 24 TxHeader c Content-Type: image/jpg 24 TxHeader c Content-Length: 38575 24 TxHeader c Date: Fri, 09 May 2008 15:42:41 GMT 24 TxHeader c X-Varnish: 113301122 113298334 24 TxHeader c Age: 158 24 TxHeader c Via: 1.1 varnish 24 TxHeader c Connection: keep-alive 24 ReqEnd c 113301122 1210347761.947785378 1210347761.947865009 0.095742702 0.000027180 0.000052452 32 SessionOpen c 83.250.202.38 37746 32 VCL_acl c NO_MATCH blacklisted 32 ReqStart c 83.250.202.38 37746 113301123 32 RxRequest c GET 32 RxURL c /resources/org.apache.wicket.Application/ userIcon?type=MINI 32 RxProtocol c HTTP/1.1 32 RxHeader c Host: www.jalbum.net 32 RxHeader c User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; sv; rv:1.8.1.9) Gecko/20071025 Camino/1.5.3 (MultiLang) 32 RxHeader c Accept: image/png,*/*;q=0.5 32 RxHeader c Accept-Language: sv,en- US;q=0.9,en;q=0.9,ja;q=0.8,fr;q=0.8,de;q=0.7,es;q=0.6,it;q=0.6,nl;q=0.5, nb;q=0.5,da;q=0.4,fi;q=0.4,pt;q=0.3,zh-Hans;q=0.2,zh- Hant;q=0.2,ko;q=0.1,ru;q=0.1 32 RxHeader c Accept-Encoding: gzip,deflate 32 RxHeader c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 32 RxHeader c Keep-Alive: 300 32 RxHeader c Connection: keep-alive 32 RxHeader c Referer: http://www.jalbum.net/ 32 RxHeader c Cookie: __utmz=111792799.1206546583.381.11.utmccn=(organic)|utmcsr=google| utmctr=laza%20jalbum|utmcmd=organic; __utma=111792799.953560163.1191150829.1210339564.1210347506.429; AWSUSER_ID=awsuser_id1205324466107r1647; JSESSIONID=107B95BB3DFEB970B89930C4B39 32 RxHeader c If-Modified-Since: Fri, 09 May 2008 12:46:57 GMT 32 VCL_call c recv lookup 32 VCL_call c hash hash 32 Hit c 113297190 32 VCL_call c hit deliver 32 Length c 915 32 VCL_call c deliver deliver 32 TxProtocol c HTTP/1.1 32 TxStatus c 200 32 TxResponse c OK 32 TxHeader c Server: Apache-Coyote/1.1 32 TxHeader c X-Powered-By: Servlet 2.4; JBoss-4.2.2.GA (build: SVNTag=JBoss_4_2_2_GA date=200710221139)/Tomcat-5.5 32 TxHeader c Last-Modified: Fri, 09 May 2008 15:38:47 GMT 32 TxHeader c Expires: Fri, 09 May 2008 16:38:47 GMT 32 TxHeader c Cache-Control: max-age=3600 32 TxHeader c Content-Type: image/jpg 32 TxHeader c Content-Length: 915 32 TxHeader c Date: Fri, 09 May 2008 15:42:41 GMT 32 TxHeader c X-Varnish: 113301123 113297190 32 TxHeader c Age: 234 32 TxHeader c Via: 1.1 varnish 32 TxHeader c Connection: keep-alive 32 ReqEnd c 113301123 1210347761.958240986 1210347761.958292484 0.000283718 0.000022411 0.000029087 32 VCL_acl c NO_MATCH blacklisted 32 ReqStart c 83.250.202.38 37746 113301124 32 RxRequest c GET 32 RxURL c /js/awstats_misc_tracker.js? screen=1920x1200&win=1265x656&cdi=32&java=true&shk=n&svg=y&fla=y&rp=y&mo v=n&wma=y&pdf=undefined&uid=awsuser_id1205324466107r1647&sid=awssession_ id1210347505409r3136 32 RxProtocol c HTTP/1.1 32 RxHeader c Host: www.jalbum.net 32 RxHeader c User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; sv; rv:1.8.1.9) Gecko/20071025 Camino/1.5.3 (MultiLang) 32 RxHeader c Accept: image/png,*/*;q=0.5 32 RxHeader c Accept-Language: sv,en- US;q=0.9,en;q=0.9,ja;q=0.8,fr;q=0.8,de;q=0.7,es;q=0.6,it;q=0.6,nl;q=0.5, nb;q=0.5,da;q=0.4,fi;q=0.4,pt;q=0.3,zh-Hans;q=0.2,zh- Hant;q=0.2,ko;q=0.1,ru;q=0.1 32 RxHeader c Accept-Encoding: gzip,deflate 32 RxHeader c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 32 RxHeader c Keep-Alive: 300 32 RxHeader c Connection: keep-alive 32 RxHeader c Referer: http://www.jalbum.net/ 32 RxHeader c Cookie: __utmz=111792799.1206546583.381.11.utmccn=(organic)|utmcsr=google| utmctr=laza%20jalbum|utmcmd=organic; __utma=111792799.953560163.1191150829.1210339564.1210347506.429; AWSUSER_ID=awsuser_id1205324466107r1647; JSESSIONID=107B95BB3DFEB970B89930C4B39 32 VCL_call c recv pass 32 VCL_call c pass pass 32 Backend c 23 default 32 ObjProtocol c HTTP/1.1 32 ObjStatus c 200 32 ObjResponse c OK 32 ObjHeader c Server: Apache-Coyote/1.1 32 ObjHeader c X-Powered-By: Servlet 2.4; JBoss-4.2.2.GA (build: SVNTag=JBoss_4_2_2_GA date=200710221139)/Tomcat-5.5 32 ObjHeader c ETag: W/"7623-1210254928000" 32 ObjHeader c Last-Modified: Thu, 08 May 2008 13:55:28 GMT 32 ObjHeader c Content-Type: text/javascript 32 ObjHeader c Date: Fri, 09 May 2008 15:42:41 GMT 32 TTL c 113301124 RFC 120 1210347761 1210347761 0 0 0 32 VCL_call c fetch 32 TTL c 113301124 VCL 180 1210347762 32 VCL_return c insert 32 Length c 7623 32 VCL_call c deliver deliver 32 TxProtocol c HTTP/1.1 32 TxStatus c 200 32 TxResponse c OK 32 TxHeader c Server: Apache-Coyote/1.1 32 TxHeader c X-Powered-By: Servlet 2.4; JBoss-4.2.2.GA (build: SVNTag=JBoss_4_2_2_GA date=200710221139)/Tomcat-5.5 32 TxHeader c ETag: W/"7623-1210254928000" 32 TxHeader c Last-Modified: Thu, 08 May 2008 13:55:28 GMT 32 TxHeader c Content-Type: text/javascript 32 TxHeader c Content-Length: 7623 32 TxHeader c Date: Fri, 09 May 2008 15:42:41 GMT 32 TxHeader c X-Varnish: 113301124 32 TxHeader c Age: 0 32 TxHeader c Via: 1.1 varnish 32 TxHeader c Connection: keep-alive 32 ReqEnd c 113301124 1210347761.993350506 1210347761.995301247 0.035058022 0.001917601 0.000033140 24 VCL_acl c NO_MATCH blacklisted 24 ReqStart c 83.250.202.38 37745 113301125 24 RxRequest c GET 24 RxURL c /js/mailto.js.jsp?a=the%20new%20site&b=] jalbum.net&c=Comment%20on%20&d=feedback[at 24 RxProtocol c HTTP/1.1 24 RxHeader c Host: www.jalbum.net 24 RxHeader c User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; sv; rv:1.8.1.9) Gecko/20071025 Camino/1.5.3 (MultiLang) 24 RxHeader c Accept: */* 24 RxHeader c Accept-Language: sv,en- US;q=0.9,en;q=0.9,ja;q=0.8,fr;q=0.8,de;q=0.7,es;q=0.6,it;q=0.6,nl;q=0.5, nb;q=0.5,da;q=0.4,fi;q=0.4,pt;q=0.3,zh-Hans;q=0.2,zh- Hant;q=0.2,ko;q=0.1,ru;q=0.1 24 RxHeader c Accept-Encoding: gzip,deflate 24 RxHeader c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 24 RxHeader c Keep-Alive: 300 24 RxHeader c Connection: keep-alive 24 RxHeader c Referer: http://www.jalbum.net/ 24 RxHeader c Cookie: __utmz=111792799.1206546583.381.11.utmccn=(organic)|utmcsr=google| utmctr=laza%20jalbum|utmcmd=organic; __utma=111792799.953560163.1191150829.1210339564.1210347506.429; AWSUSER_ID=awsuser_id1205324466107r1647; JSESSIONID=107B95BB3DFEB970B89930C4B39 24 VCL_call c recv pass 24 VCL_call c pass pass 24 Backend c 23 default 24 ObjProtocol c HTTP/1.1 24 ObjStatus c 200 24 ObjResponse c OK 24 ObjHeader c Server: Apache-Coyote/1.1 24 ObjHeader c X-Powered-By: Servlet 2.4; JBoss-4.2.2.GA (build: SVNTag=JBoss_4_2_2_GA date=200710221139)/Tomcat-5.5 24 ObjHeader c Content-Type: text/javascript;charset=ISO-8859-1 24 ObjHeader c Date: Fri, 09 May 2008 15:42:41 GMT 24 TTL c 113301125 RFC 120 1210347762 1210347761 0 0 0 24 VCL_call c fetch 24 TTL c 113301125 VCL 180 1210347762 24 VCL_return c insert 24 Length c 69 24 VCL_call c deliver deliver 24 TxProtocol c HTTP/1.1 24 TxStatus c 200 24 TxResponse c OK 24 TxHeader c Server: Apache-Coyote/1.1 24 TxHeader c X-Powered-By: Servlet 2.4; JBoss-4.2.2.GA (build: SVNTag=JBoss_4_2_2_GA date=200710221139)/Tomcat-5.5 24 TxHeader c Content-Type: text/javascript;charset=ISO-8859-1 24 TxHeader c Content-Length: 69 24 TxHeader c Date: Fri, 09 May 2008 15:42:42 GMT 24 TxHeader c X-Varnish: 113301125 24 TxHeader c Age: 0 24 TxHeader c Via: 1.1 varnish 24 TxHeader c Connection: keep-alive 24 ReqEnd c 113301125 1210347762.009387732 1210347762.010314703 0.061522722 0.000905991 0.000020981 [root at lens varnish]# _______________________________________________ varnish-misc mailing list varnish-misc at projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc H?lsar From brian at briansmith.org Sat May 10 16:54:08 2008 From: brian at briansmith.org (Brian Smith) Date: Sat, 10 May 2008 09:54:08 -0700 Subject: Varnish caching issues, cache size, expires, cache resets, whatsgoing on? References: <4820CCBE.90404@apokalyptik.com><8B206B39A52D4636916EB980FFD7FC8E@T60> <4824A4DF.1080107@apokalyptik.com> Message-ID: Demitrious Kelly wrote: > Also, interestingly, the response is higher than our other server (we > have two handling a split load, what I detailed was just one of them, > the other is left alone while we tweak this one.) A 1x1 pixel image > request coming from the original (which crashes all the time) gets sent > in 0.08x seconds, and this one with tcmalloc in 0.11x seconds. I > definitely consider 0.03 seconds a price worth stability, but its an > interesting observation nonetheless Maybe the operating system if trying to proactively write pages to swap in the background. You might be able to tune the configuration to reduce or stop that behavior if the whole working set is supposed to fit in memory. Or, you could increase the expiration times so that the cache is larger than 8GB, and see if you can use the pre-swapping to your benefit. The difference between a cache hit and a cache miss is probably much larger than 0.03 seconds. Regards, Brian From malevo at gmail.com Mon May 12 12:27:36 2008 From: malevo at gmail.com (=?ISO-8859-1?Q?Pablo_Garc=EDa?=) Date: Mon, 12 May 2008 09:27:36 -0300 Subject: Varnish caching issues, cache size, expires, cache resets, whatsgoing on? In-Reply-To: <4824A4DF.1080107@apokalyptik.com> References: <4820CCBE.90404@apokalyptik.com> <8B206B39A52D4636916EB980FFD7FC8E@T60> <4824A4DF.1080107@apokalyptik.com> Message-ID: <4ec3c3f70805120527i4a4760a4u5dfc202d05e35b44@mail.gmail.com> Demitrious, before performing the same recompilation on the other server, try to set the /proc/sys/vm/swappiness to 10, or to 0 that should reduce the natural behavior of Linux to send data to swap. Hope this helps. Regards, Pablo From jsd at cluttered.com Mon May 12 17:13:31 2008 From: jsd at cluttered.com (Jon Drukman) Date: Mon, 12 May 2008 10:13:31 -0700 Subject: Debugging hash keys? Message-ID: I'm trying to figure out what keys certain requests are being cached under. How can I see what varnish is doing under the hood? Somehow my vcl is creating duplicate keys and I want to see if I can figure out a workaround. -jsd- From apokalyptik at apokalyptik.com Mon May 12 17:22:40 2008 From: apokalyptik at apokalyptik.com (Demitrious Kelly) Date: Mon, 12 May 2008 10:22:40 -0700 Subject: Varnish caching issues, cache size, expires, cache resets, whatsgoing on? In-Reply-To: <4824A4DF.1080107@apokalyptik.com> References: <4820CCBE.90404@apokalyptik.com> <8B206B39A52D4636916EB980FFD7FC8E@T60> <4824A4DF.1080107@apokalyptik.com> Message-ID: <48287CE0.7090302@apokalyptik.com> Thanks Brian, and Pablo, Turns out I was not entirely correct. A colleague of mine had been making VCL and command line parameter changes (to troubleshoot this same issue.) So the running parameters were not the same. Also even after the two machines have been brought into sync on VCL, and command line varnish usage the one machine is still 0.2 to 0.3 seconds faster. The difference has to be somewhere else. On a happy note after tcmalloc varnish has stopped crashing every couple of hours. We're just going to be hitting peak traffic for the week here in a bit, but so far so good. I took some graphs from munin and have made them available to look at if you are at all curious to look. http://blog.apokalyptik.com/wp-content/uploads/2008/05/mem.png http://blog.apokalyptik.com/wp-content/uploads/2008/05/load.png http://blog.apokalyptik.com/wp-content/uploads/2008/05/cpu.png Thanks very much for your help! Cheers! DK Demitrious Kelly wrote: > Also, interestingly, the response is higher than our other server (we > have two handling a split load, what I detailed was just one of them, > the other is left alone while we tweak this one.) A 1x1 pixel image > request coming from the original (which crashes all the time) gets sent > in 0.08x seconds, and this one with tcmalloc in 0.11x seconds. I > definitely consider 0.03 seconds a price worth stability, but its an > interesting observation nonetheless From ay at vg.no Tue May 13 12:47:26 2008 From: ay at vg.no (Audun Ytterdal) Date: Tue, 13 May 2008 14:47:26 +0200 Subject: Varnish statistics Message-ID: <48298DDE.7080600@vg.no> Here is a thought. We like varnish, we like munin, we like statistics... Right now it's hard to get information about which backend get what kind of traffic, how much of your traffic is hindered by cookies and so forth My tought: sub vcl_recv { set req.grace = 15s; if (!req.url ~ "^\/tabkonk/" && !req.url ~ "^\/live\/") { inc varcount.tabkonkcookieremove; remove req.http.cookie; } if (req.http.referer ~"^x-gadg") { inc varcount.xgadgetblocked; error 403 "x-gadget blocked"; } if (req.http.host ~ "^skatt.vg.no$"){ inc varcount.backendskatt; set req.backend = skatt; } elseif (req.http.host ~ "^nyheter.vg.no$"){ inc varcount.backendnyheter; set req.backend = nyheter; ....... This way, probably with a better sounding syntax, you could have counters for just about anything, and output them them through varnishstat, and then graph them with munin or similar tool. Any thoughts? ***************************************************************** Denne fotnoten bekrefter at denne e-postmeldingen ble skannet av MailSweeper og funnet fri for virus. ***************************************************************** This footnote confirms that this email message has been swept by MailSweeper for the presence of computer viruses. ***************************************************************** From brian at briansmith.org Tue May 13 16:52:08 2008 From: brian at briansmith.org (Brian Smith) Date: Tue, 13 May 2008 09:52:08 -0700 Subject: Varnish caching issues, cache size, expires, cache resets, whatsgoing on? References: <4820CCBE.90404@apokalyptik.com> <8B206B39A52D4636916EB980FFD7FC8E@T60><4824A4DF.1080107@apokalyptik.com> <48287CE0.7090302@apokalyptik.com> Message-ID: <55A71614B70B431ABE64D95BB477079F@T60> Demitrious Kelly wrote: > On a happy note after tcmalloc varnish has stopped crashing every couple > of hours. We're just going to be hitting peak traffic for the week here > in a bit, but so far so good. How are things working out? I read your blog post where you said requests go through pound, then varnish, then a custom server, then S3. In addition, you use memcached to cache some per-object metadata. Also, you don't cache things right away; you wait until an object has been requested several times before you let varnishd cache it. Do you avoid caching responses right away due to the lack of an automatic LRU purging mechanism in varnishd? And, have you considered caching the responses in memcached directly instead of in varnishd? It seems to me that "varnishd -s malloc" and memcached are not too different. Also, I am curious about why your pound server hashes on the host name only, instead of the whole URL. See http://www.igvita.com/2008/02/11/nginx-and-memcached-a-400-boost/ Thanks, Brian > > I took some graphs from munin and have made them available to look at if > you are at all curious to look. > > http://blog.apokalyptik.com/wp-content/uploads/2008/05/mem.png > http://blog.apokalyptik.com/wp-content/uploads/2008/05/load.png > http://blog.apokalyptik.com/wp-content/uploads/2008/05/cpu.png From phk at phk.freebsd.dk Wed May 14 14:31:59 2008 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Wed, 14 May 2008 14:31:59 +0000 Subject: Varnish statistics In-Reply-To: Your message of "Tue, 13 May 2008 14:47:26 +0200." <48298DDE.7080600@vg.no> Message-ID: <3111.1210775519@critter.freebsd.dk> In message <48298DDE.7080600 at vg.no>, Audun Ytterdal writes: >Here is a thought. > >We like varnish, we like munin, we like statistics... > >Right now it's hard to get information about which backend get what kind >of traffic, how much of your traffic is hindered by cookies and so forth > if (!req.url ~ "^\/tabkonk/" && !req.url ~ "^\/live\/") { > inc varcount.tabkonkcookieremove; You can actually simulate this already, by enabling the vcl_trace parameter and run varnishlog -i vcl_trace and see where things go in the VCL code. Doing dynamic counters is probably not a bad idea, but realistically you would only be able to read them through the CLI, unless we predefine a fixed number of "vcl_counters". Anyway, this should be added to the "post 2.0 ideas" page on the wiki. -- 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 armdan20 at gmail.com Thu May 22 09:28:07 2008 From: armdan20 at gmail.com (andan andan) Date: Thu, 22 May 2008 11:28:07 +0200 Subject: Fetch called after pass Message-ID: Hi all. Whats happened with the possible bug related in http://projects.linpro.no/pipermail/varnish-misc/2007-July/000626.html: In our tests (varnish trunk rev 2635), vcl_fetch is still inserting the request in cache even though it got a "pass" in vcl_recv. Varnishlog attached. Thanks. Best regards. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: varnishlog.txt URL: From phk at phk.freebsd.dk Thu May 22 20:20:53 2008 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Thu, 22 May 2008 20:20:53 +0000 Subject: Fetch called after pass In-Reply-To: Your message of "Thu, 22 May 2008 11:28:07 +0200." Message-ID: <935.1211487653@critter.freebsd.dk> In message , "anda n andan" writes: >In our tests (varnish trunk rev 2635), vcl_fetch is still inserting >the request in cache even though it got a "pass" in vcl_recv. This is a case where the varnishlog output is a bit confusing: When you mark the request for pass in vcl_recv, it goes to vcl_pass, from there til vcl_fetch and despite the action from there being "insert", it just means "deliver" since the request was a pass. I'll make a mental note to make the varnishlog read "pass" in that case. -- 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 Fri May 23 14:34:17 2008 From: duja at torlen.net (duja at torlen.net) Date: Fri, 23 May 2008 16:34:17 +0200 Subject: Strange Opera error in POST Message-ID: <3ncizfw40ga7izx.230520081634@torlen.net> Hi, Im wondering if anyone have seen some strange behaviour from Opera (9.27) when doing a POST through varnish? >From my debugging: Opera doesn't send any POST data when doing it through varnish . Opera sends a Cookie2 header - Cookie2: $version=1 In this moment I dont have so much info from the debugging. I will reply as soon as I have some more to share. From armdan20 at gmail.com Mon May 26 11:20:51 2008 From: armdan20 at gmail.com (andan andan) Date: Mon, 26 May 2008 13:20:51 +0200 Subject: Pass and pipe in trunk version Message-ID: Hi. According to: http://varnish.projects.linpro.no/wiki/FAQ#ShouldIusepipeorpassinmyVCLcode pipe must be used to handle POST requests, but according to: http://varnish.projects.linpro.no/wiki/VCLExampleDefault POST requests are handled with pass. if (req.request != "GET" && req.request != "HEAD") { /* We only deal with GET and HEAD by default */ pass; } What document is wrong ? Thanks in advance. Best regards. From phk at phk.freebsd.dk Mon May 26 11:42:17 2008 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 26 May 2008 11:42:17 +0000 Subject: Pass and pipe in trunk version In-Reply-To: Your message of "Mon, 26 May 2008 13:20:51 +0200." Message-ID: <40526.1211802137@critter.freebsd.dk> In message , "anda n andan" writes: >Hi. > >According to: http://varnish.projects.linpro.no/wiki/FAQ#ShouldIusepipeorpassinmyVCLcode > >pipe must be used to handle POST requests, but according to: > >http://varnish.projects.linpro.no/wiki/VCLExampleDefault > >POST requests are handled with pass. > > if (req.request != "GET" && req.request != "HEAD") { > /* We only deal with GET and HEAD by default */ > pass; > } > > >What document is wrong ? Depends which varnish version you use. -trunk can PASS requests with content, so that is how it should be in the future. Older versions can not, and need to use PIPE. The default VCL built into varnish always gets this right. -- 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 cherife at dotimes.com Tue May 27 12:52:57 2008 From: cherife at dotimes.com (Cherife Li) Date: Tue, 27 May 2008 20:52:57 +0800 Subject: firefox always miss Message-ID: <483C0429.5090307@dotimes.com> Hi all, I'm using v1.1.2. Given a .gif file(I'm just testing), IE and curl could hit from cache, but firefox never hits. I through it was the "argued" Accept-Encoding issue, but things are not this simple. I've read http://varnish.projects.linpro.no/wiki/FAQ/Compression, and tried the example there. And I've tried to change the headers for firefox, even if left only the User-Agent and Accept: */*, emptied any header else. Varnishstat shows firefox never hits or misses, varnishlog shows firefox pass but fetch when I Ctrl+F5. Could anybody guide me through? Thanks. -- Rgds, Cherife. From phk at phk.freebsd.dk Tue May 27 13:42:42 2008 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Tue, 27 May 2008 13:42:42 +0000 Subject: firefox always miss In-Reply-To: Your message of "Tue, 27 May 2008 20:52:57 +0800." <483C0429.5090307@dotimes.com> Message-ID: <53191.1211895762@critter.freebsd.dk> In message <483C0429.5090307 at dotimes.com>, Cherife Li writes: >Hi all, > >I'm using v1.1.2. > >Given a .gif file(I'm just testing), IE and curl could hit from cache, >but firefox never hits. Use the varnishlog to find out how/why. Possibly enable the vcl_trace paramter if need be. My guess: A cookie ? -- 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 cherife at dotimes.com Tue May 27 15:12:54 2008 From: cherife at dotimes.com (Cherife Li) Date: Tue, 27 May 2008 23:12:54 +0800 Subject: firefox always miss In-Reply-To: <53191.1211895762@critter.freebsd.dk> References: <53191.1211895762@critter.freebsd.dk> Message-ID: <483C24F6.3090504@dotimes.com> On 05/27/08 21:42, Poul-Henning Kamp wrote: > In message <483C0429.5090307 at dotimes.com>, Cherife Li writes: >> Hi all, >> >> I'm using v1.1.2. >> >> Given a .gif file(I'm just testing), IE and curl could hit from cache, >> but firefox never hits. > > Use the varnishlog to find out how/why. Possibly enable the > vcl_trace paramter if need be. > > My guess: A cookie ? > Ooh, yeah, that's the point. Thanks for guiding me out, you saved my life. I should be more careful as I did see the "pass" in the varnishlog. And one more question, with remove req.http.cookie; (or Cookie) remove req.http.Accept-Encoding; (or with low case a and e), the varnishlog still shows Cookie and Accept-Encoding headers. Does this mean the original headers varnish received? If not, varnish didn't remove these headers, did it? Thanks. -- Rgds, Cherife. From phk at phk.freebsd.dk Tue May 27 15:21:06 2008 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Tue, 27 May 2008 15:21:06 +0000 Subject: firefox always miss In-Reply-To: Your message of "Tue, 27 May 2008 23:12:54 +0800." <483C24F6.3090504@dotimes.com> Message-ID: <53514.1211901666@critter.freebsd.dk> In message <483C24F6.3090504 at dotimes.com>, Cherife Li writes: >On 05/27/08 21:42, Poul-Henning Kamp wrote: >> In message <483C0429.5090307 at dotimes.com>, Cherife Li writes: >>> Hi all, >>> >>> I'm using v1.1.2. >>> >>> Given a .gif file(I'm just testing), IE and curl could hit from cache, >>> but firefox never hits. >> >> Use the varnishlog to find out how/why. Possibly enable the >> vcl_trace paramter if need be. >> >> My guess: A cookie ? >> >Ooh, yeah, that's the point. >Thanks for guiding me out, you saved my life. >I should be more careful as I did see the "pass" in the varnishlog. > >And one more question, with > remove req.http.cookie; (or Cookie) > remove req.http.Accept-Encoding; (or with low case a and e), >the varnishlog still shows Cookie and Accept-Encoding headers. >Does this mean the original headers varnish received? >If not, varnish didn't remove these headers, did it? RxHeaders is exactly what was received from the client or backend. TxHeaders are exactly what we send to the backend/client. -- 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 cherife at dotimes.com Tue May 27 16:43:52 2008 From: cherife at dotimes.com (Cherife Li) Date: Wed, 28 May 2008 00:43:52 +0800 Subject: firefox always miss In-Reply-To: <53514.1211901666@critter.freebsd.dk> References: <53514.1211901666@critter.freebsd.dk> Message-ID: <483C3A48.1040909@dotimes.com> On 05/27/08 23:21, Poul-Henning Kamp wrote: > In message <483C24F6.3090504 at dotimes.com>, Cherife Li writes: >> On 05/27/08 21:42, Poul-Henning Kamp wrote: >>> In message <483C0429.5090307 at dotimes.com>, Cherife Li writes: >>>> Hi all, >>>> >>>> I'm using v1.1.2. >>>> >>>> Given a .gif file(I'm just testing), IE and curl could hit from cache, >>>> but firefox never hits. >>> Use the varnishlog to find out how/why. Possibly enable the >>> vcl_trace paramter if need be. >>> >>> My guess: A cookie ? >>> >> Ooh, yeah, that's the point. >> Thanks for guiding me out, you saved my life. >> I should be more careful as I did see the "pass" in the varnishlog. >> >> And one more question, with >> remove req.http.cookie; (or Cookie) >> remove req.http.Accept-Encoding; (or with low case a and e), >> the varnishlog still shows Cookie and Accept-Encoding headers. >> Does this mean the original headers varnish received? >> If not, varnish didn't remove these headers, did it? > > RxHeaders is exactly what was received from the client or backend. > TxHeaders are exactly what we send to the backend/client. > Got it. I tested and saw the difference. Thanks again for your time. -- Rgds, Cherife. From torstein at escenic.com Wed May 28 12:10:08 2008 From: torstein at escenic.com (Torstein Krause Johansen) Date: Wed, 28 May 2008 14:10:08 +0200 Subject: Tomcat, Session objects and caching (most) URIs Message-ID: <483D4BA0.7070608@escenic.com> Hi all, I'm using Varnish 1.1.2 together with Tomcat 5.5.x as backend and I've got some questions regarding caching and the Java Session object. When receiving a request, Tomcat always sets a Cookie for storing the Java Session object (JSESSIONID). Because of this, no pages returned from Tomcat are cached in Varnish with the default configuration. I do understand the rationale behind this, but since Tomcat _always_ sets the cookie in order to supply the Session object (a part of the J2EE spec I believe), I have to find a way to cache (most of) these requests. One workaround is to remove the Set-Cookie header in the Tomcat reply before Varnish treats it: vcl_fetch() { ... if (obj.http.Set-Cookie) { remove obj.http.Set-Cookie; } ... } Now, as long as noone in any Java application running in the servlet container uses the Java Session object, this works fine. However, what's the prefered way of doing this, /if/ we want to use the Session object for /some/ URIs? Is it possible to add an additional test to the vcl_fetch block above to not remofve the header, if the URI is either starting with e.g. "/login" or "/register" ? Another workaround I can think of would be to insert all requests with Cookies in their headers. What is the preferred way of solving this problem? Cheers, -Torstein -- Torstein Krause Johansen Senior consultant mobile: +47 97 01 76 04 web: http://www.escenic.com/ Escenic - platform for innovation From cherife at dotimes.com Thu May 29 06:29:14 2008 From: cherife at dotimes.com (Cherife Li) Date: Thu, 29 May 2008 14:29:14 +0800 Subject: Directors user sessions In-Reply-To: <47F938D5.3060706@torlen.net> References: <47ECDA29.1060709@dotimes.com> <47F938D5.3060706@torlen.net> Message-ID: Sorry for this *late* response. Noticed this mail while searching the ML archive just now. I missed it. :-( On Mon, Apr 7, 2008 at 4:55 AM, Erik Torlen wrote: > But the loadbalancing is already implenteed. I dont see why it shouldn't be > used as loadbalancer if the functionality exists? load-balance != session-sticky, is it? At least it depends on the mechanism of LBer. > > I don't want to use one place for all sessions, like a file share or > something in that direction. Im thinking about creating > a Header that is called X-Backend: (a|b|c|d). This could be used to check > what backend the user should use. Its really not > a nice way to do it but its a way of doing it. IIRC, HAproxy use Cookie insertion just like what you said to do Cookie-based LB. > > Is there any idea that I could create a ticket for a feature like this? > Maybe? And, have you got any solution? Maybe, you could try nginx or haproxy. Good luck. > > / Erik > > Cherife Li skrev: > > On 2008-3-28 19:05, duja at torlen.net wrote: >> >>> Hi, >>> >>> I got a question regarding the Directors in varnish vcl. If user A is >>> logging in to http://mywebsite.com and the website is using varnish >>> (with directors) in front of 4 backend servers. The 4 backend servers is >>> identical. >>> >>> User A is logging in and hits server 1. He then goes to his profile and >>> hits server 2. The server 2 doesn't know that user A is logged >>> and redirect him to some "Not logged in"-page. >>> >>> Is there any way for varnish to lookup which server that user A should be >>> directed to? Some kind of Sticky Session function? >>> >>> IMHO, Varnish is for caching, rather than for redirecting. >> Maybe you could consider HAProxy, or pound, or IPVS, or >> similar implementation. >> Besides, I know that sessions can be shared. >> >> / Erik >>> >>> _______________________________________________ >>> varnish-misc mailing list >>> varnish-misc at projects.linpro.no >>> http://projects.linpro.no/mailman/listinfo/varnish-misc >>> >> >> >> > -- Rgds, Cherife. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ottolski at web.de Thu May 29 15:06:41 2008 From: ottolski at web.de (Sascha Ottolski) Date: Thu, 29 May 2008 17:06:41 +0200 Subject: please help on compiling nagios plugin Message-ID: <200805291706.41613.ottolski@web.de> Hi, asked it some weeks ago, but got no answer :-( when running configure, I see this error: ./configure: line 19292: syntax error near unexpected token `VARNISHAPI,' ./configure: line 19292: `PKG_CHECK_MODULES(VARNISHAPI, varnishapi)' the line is # Checks for libraries. PKG_CHECK_MODULES(VARNISHAPI, varnishapi) any help appreciated. Thanks, Sascha From ottolski at web.de Thu May 29 16:51:45 2008 From: ottolski at web.de (Sascha Ottolski) Date: Thu, 29 May 2008 18:51:45 +0200 Subject: please help on compiling nagios plugin In-Reply-To: <200805291706.41613.ottolski@web.de> References: <200805291706.41613.ottolski@web.de> Message-ID: <200805291851.45756.ottolski@web.de> Am Donnerstag 29 Mai 2008 17:06:41 schrieb Sascha Ottolski: > Hi, > > asked it some weeks ago, but got no answer :-( > > when running configure, I see this error: > > ./configure: line 19292: syntax error near unexpected token > `VARNISHAPI,' > ./configure: line 19292: `PKG_CHECK_MODULES(VARNISHAPI, varnishapi)' > > the line is > > # Checks for libraries. > PKG_CHECK_MODULES(VARNISHAPI, varnishapi) finally managed to compile the nagios plugin that comes with the svn checkout, may be this helps someone else. apparently, the debian packages I created and installed before using the debian/ directory that comes with the checkout does not install the pkg-config file, and is missing a link. apt-get install pkg-config cd /root/varnish-svn-trunk/varnish-tools/nagios/ cp /root/varnish-svn-trunk/varnish-cache/varnishapi.pc /usr/lib/pkgconfig/ cd /usr/lib/ ln -s libvarnishapi.so.0 libvarnishapi.so ./autogen.sh ./configure make make install this will create the plugin as /usr/local/libexec/check_varnish Cheers, Sascha From ay at vg.no Fri May 30 12:01:35 2008 From: ay at vg.no (Audun Ytterdal) Date: Fri, 30 May 2008 14:01:35 +0200 Subject: Performance options for trunk Message-ID: <483FEC9F.30107@vg.no> I run trunk in front of a site. I have 3 varnishservers, all with 32GB of ram serving only small pictures, thumbnails and profile pictures. The cacheset is pretty large (1.5 TB) and changing much over time. And before you all ask why I don't just server partitioned data from several apache/nginx/lighttpd servers It's because we're not there yet. The varnishes all fetch their content from one lighttpd server . I run into the Thread pileup-problem I've set threadlimit to 1500 and it usually lies between 80 and 700. While restarting it hits the 1500 limit and stays there for a few minutes. Then it gradualy manages to controll traffic and ends up around 80 threads. It usually grows a bit. But not over 700-1000 ish. But suddenly, under high traffic it goes up to the limit beeing 1500 or 4000 or whatever i set it to. Then it stays there and usualy never recovers without a restart. I guess it's because the backend at some point answers slowly. But is there a way to easier get out of this situation. Running varnish like this: (redhat 4.6 32 GB RAM) /usr/sbin/varnishd -a :80 -f /etc/varnish/nettby.vcl -T 127.0.0.1:82 -t 120 -w 2,2000,30 -u varnish -g varnish -p client_http11 on -p thread_pools 4 -p thread_pool_max 4000 -p listen_depth 4096 -p lru_interval 3600 -h classic,500009 -s file,/var/varnish/varnish_storage.bin,30G -P /var/run/varnish.pid and for testing purposes (redhat 5.1 32 GB RAM) varnish 22959 17.1 45.2 20187068 14938024 ? Sl May29 160:40 /usr/sbin/varnishd -a :80 -f /etc/varnish/nettby.vcl -T 127.0.0.1:82 -t 120 -u varnish -g varnish -p thread_pools 4 -p thread_pool_max 2000 -p client_http11 on -p listen_depth 4096 -p lru_interval 3600 -h classic,500009 -s malloc,60G -P /var/run/varnish.pid Each varnish handles about 3000 req/s before it caves in. Any suggestions? Are the parameters sane? -- Audun ***************************************************************** Denne fotnoten bekrefter at denne e-postmeldingen ble skannet av MailSweeper og funnet fri for virus. ***************************************************************** This footnote confirms that this email message has been swept by MailSweeper for the presence of computer viruses. ***************************************************************** From ottolski at web.de Fri May 30 13:54:36 2008 From: ottolski at web.de (Sascha Ottolski) Date: Fri, 30 May 2008 15:54:36 +0200 Subject: Performance options for trunk In-Reply-To: <483FEC9F.30107@vg.no> References: <483FEC9F.30107@vg.no> Message-ID: <200805301554.36292.ottolski@web.de> Am Freitag 30 Mai 2008 14:01:35 schrieb Audun Ytterdal: > I run trunk in front of a site. I have 3 varnishservers, all with > 32GB > > of ram serving only small pictures, thumbnails and profile pictures. > The cacheset is pretty large (1.5 TB) and changing much over time. > And before you all ask why I don't just server partitioned data from > several apache/nginx/lighttpd servers It's because we're not there > yet. The varnishes all fetch their content from one lighttpd server . > > I run into the Thread pileup-problem > > I've set threadlimit to 1500 and it usually lies between 80 and 700. > While restarting it hits the 1500 limit and stays there for a few > minutes. Then it gradualy manages to controll traffic and ends up > around 80 threads. It usually grows a bit. But not over 700-1000 ish. > But suddenly, under high traffic it goes up to the limit beeing 1500 > or 4000 or whatever i set it to. Then it stays there and usualy never > recovers without a restart. > I guess it's because the backend at some point answers slowly. But is > there a way to easier get out of this situation. > > Running varnish like this: > > (redhat 4.6 32 GB RAM) > > /usr/sbin/varnishd -a :80 -f /etc/varnish/nettby.vcl -T 127.0.0.1:82 > -t 120 -w 2,2000,30 -u varnish -g varnish -p client_http11 on -p > thread_pools 4 -p thread_pool_max 4000 -p listen_depth 4096 -p > lru_interval 3600 -h classic,500009 -s > file,/var/varnish/varnish_storage.bin,30G -P /var/run/varnish.pid > > and for testing purposes > > (redhat 5.1 32 GB RAM) > > varnish 22959 17.1 45.2 20187068 14938024 ? Sl May29 160:40 > /usr/sbin/varnishd -a :80 -f /etc/varnish/nettby.vcl -T 127.0.0.1:82 > -t 120 -u varnish -g varnish -p thread_pools 4 -p thread_pool_max > 2000 -p client_http11 on -p listen_depth 4096 -p lru_interval 3600 -h > classic,500009 -s malloc,60G -P /var/run/varnish.pid > > Each varnish handles about 3000 req/s before it caves in. > > Any suggestions? not really sure if I can help, but at least I can tell you that we run a similar setup. however, our images are never changed, only get deleted, and if it happens, a PURGE request clears them off the proxies. Therefore, we go a little different route: huge file based cache (over 500 GB), and huge default_ttl (one year, only 404 errors have a smaller ttl of 3 hours). we also have 32 GB installed, and set thread_pool_max to 8000, and -h classic,2500009 according to a hint in the wiki. I did not look at the thread count for a longer time, and don't really know if 8000 is any good or bad. since everything works nice, I just keep it as it is. having said all this, the request pattern is not really like yours. the cache file is only used by ~60 % after 50 days, and peak traffic for each out of three proxies is only about 300 req/s. one would probably cope well with our traffic, we run three as a simple HA measure. Cheers, Sascha > > Are the parameters sane? > > -- > Audun > > > > ***************************************************************** > Denne fotnoten bekrefter at denne e-postmeldingen ble > skannet av MailSweeper og funnet fri for virus. > ***************************************************************** > This footnote confirms that this email message has been > swept by MailSweeper for the presence of computer viruses. > ***************************************************************** > > _______________________________________________ > varnish-misc mailing list > varnish-misc at projects.linpro.no > http://projects.linpro.no/mailman/listinfo/varnish-misc From fairwinds at eastlink.ca Sat May 31 15:51:36 2008 From: fairwinds at eastlink.ca (David Pratt) Date: Sat, 31 May 2008 12:51:36 -0300 Subject: Conditional caching question In-Reply-To: <4841723E.2020109@eastlink.ca> References: <4841723E.2020109@eastlink.ca> Message-ID: <48417408.3070705@eastlink.ca> Sorry wanted to clarify that I wanted varnish checked first before going to backend. If object is frequently requested, add to cache. David Pratt wrote: > Hi. In most cases, I want a request to be passed to a backend where it > will be handled by server. If frequency is high, however; I want to add > the object to varnish cache and have varnish handle it. I am not worried > about a mechanism to keeping track of frequency of requests. Question is > what is available to me to add an object/path to the varnish cache if it > was originally passed? Many thanks. > > Regards, > David > From fairwinds at eastlink.ca Sat May 31 15:43:58 2008 From: fairwinds at eastlink.ca (David Pratt) Date: Sat, 31 May 2008 12:43:58 -0300 Subject: Conditional caching question Message-ID: <4841723E.2020109@eastlink.ca> Hi. In most cases, I want a request to be passed to a backend where it will be handled by server. If frequency is high, however; I want to add the object to varnish cache and have varnish handle it. I am not worried about a mechanism to keeping track of frequency of requests. Question is what is available to me to add an object/path to the varnish cache if it was originally passed? Many thanks. Regards, David From phk at phk.freebsd.dk Sat May 31 21:48:19 2008 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Sat, 31 May 2008 21:48:19 +0000 Subject: Aiming for Varnish 2.0 Message-ID: <12466.1212270499@critter.freebsd.dk> We are putting Varnish 2.0 right in the cross-hairs now, and that means that I'll be trying to close as many outstanding issues and tickets as possible. I will strongly urge you all to run -trunk and help flush out the remaining bugs. Please also help go through the tickets and tell me if there are tickets that should be closed. I have made a number of changes in the last couple of days that warrant a comment here: regsuball() in VCL ------------------ Just like regsub, but replaces all occurances of the regexp. The manual page was wrong about regsub() previously; it only replaces the first match. Backend connect timeout ----------------------- We now have a timeout for how long time it may take to open the TCP session to the backend. This should reduce the amount of havoc caused by network hiccups. Please understand that this is only the timeout to open the TCP connection, not the timeout to perform the HTTP transaction. The default is 400 msec and you can change the default as a parameter ("connect_timeout"), or set a specific timeout for each backend in VCL: backend b1 { .host = "hex"; .port = "80"; .connect_timeout = 500 ms; } Let me know if 400 msec is a bad default. CLI code cleanup ---------------- The CLI code has been cleaned up and given a "quit" command. This should eliminate some crashes seen in relation to heavy CLI traffic via the TELNET interface. CLI commands and sessions are now logged in syslog(3). PURGE code cleanup ------------------ I have renamed the CLI commands: from url.purge to purge.url and from hash.purge to purge.hash for consistency. I have no idea how I got it wrong in the first place. The old commands will work in all 2.x releases. In version 1.x purges based on regexps were expected to be very infrequent manual operations, so we didn't clean them up, but after my work on them tonight, they should be ready for heavy-duty traffic. Be aware though, that they _are_ based on regular expressions. If you have to purge 10000 objects, you should try to express that as a (few) regular expression. If you do 10000 individual purges, it means that all cached objects will be tested against 10000 regexps next time they are hit. -- 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.