Re: cache empties itself?
Ricardo Newbery wrote: On Apr 7, 2008, at 10:30 PM, DHF wrote: Ricardo Newbery wrote: On Apr 7, 2008, at 5:22 PM, Michael S. Fischer wrote: Sure, but this is also the sort of content that can be cached back upstream using ordinary HTTP headers. No, it cannot. Again, the use case is dynamically-generated content that is subject to change at unpredictable intervals but which is otherwise fairly static for some length of time, and where serving stale content after a change is unacceptable. Ordinary HTTP headers just don't solve that use case without unnecessary loading of the backend. Isn't this what if-modified-since requests are for? 304 not modified is a pretty small request/response, though I can understand the tendency to want to push it out to the frontend caches. I would think the management overhead of maintaining two seperate expirations wouldn't be worth the extra hassle just to save yourself some ims requests to a backend. Unless of course varnish doesn't support ims requests in a usable way, I haven't actually tested it myself. Unless things have changed recently, Varnish support for IMS is mixed. Varnish supports IMS for cache hits but not for cache misses unless you tweak the vcl to pass them in vcl_miss. Varnish will not generate an IMS to revalidate it's own cache. Good to know. Also it is not necessarily true that generating a 304 response is always light impact. I'm not sure about the Drupal case, but at least for Plone there can be a significant performance hit even when just calculating the Last-Modified date. The hit is usually lighter than that required for generating the full response but for high-traffic sites, it's still a significant consideration. But the most significant issue is that IMS doesn't help in the slightest to lighten the load of *new* requests to your backend. IMS requests are only helpful if you already have the content in your own browser cache -- or in an intermediate proxy cache server (for proxies that support IMS to revalidate their own cache). The intermediate proxy was the case I was thinking about, but you are correct, if there is no intermediate proxy and varnish frontends don't revalidate with ims requests then the whole plan is screwed. Regarding the potential management overhead... this is not relevant to the question of whether this strategy would increase your site's performance. Management overhead is a separate question, and not an easy one to answer in the general case. The overhead might be a problem for some. But I know in my own case, the overhead required to manage this sort of thing is actually pretty trivial. How do you manage the split ttl's? Do you send a purge after a page has changed or have you crafted another way to force a revalidation of cached objects? --Dave Ric ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: cache empties itself?
On Apr 8, 2008, at 8:26 AM, DHF wrote: Ricardo Newbery wrote: Regarding the potential management overhead... this is not relevant to the question of whether this strategy would increase your site's performance. Management overhead is a separate question, and not an easy one to answer in the general case. The overhead might be a problem for some. But I know in my own case, the overhead required to manage this sort of thing is actually pretty trivial. How do you manage the split ttl's? Do you send a purge after a page has changed or have you crafted another way to force a revalidation of cached objects? Yes, a purge is sent after the page has changed. For Plone, all of this is easy to automate with the CacheFu add-on. Although support for adding a Surrogate-Control header (or whatever you use to communicate the local ttl) requires some minor customization (about 5 lines of code). Ric ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: cache empties itself?
On Fri, Apr 4, 2008 at 3:31 PM, Ricardo Newbery [EMAIL PROTECTED] wrote: Again, static content isn't only the stuff that is served from filesystems in the classic static web server scenario. There are plenty of dynamic applications that process content from database -- applying skins and compositing multiple elements into a single page while filtering every element or otherwise applying special processing based on a user's access privileges. An example of this is a dynamic content management system like Plone or Drupal. In many cases, these dynamic responses are fairly static for some period of time but there is still a definite performance hit, especially under load In any case, both of these examples, Plone and Drupal, can indeed cache the output locally but that is still not as fast as placing a dedicated cache server in front. It's almost always faster to have a dedicated single-purpose process do something instead of cranking up the hefty machinery for requests that can be adequately served by the lighter process. Sure, but this is also the sort of content that can be cached back upstream using ordinary HTTP headers. Still waiting for that compelling case that requires independent cache configuration, --Michael ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: cache empties itself?
Ricardo Newbery wrote: On Apr 7, 2008, at 5:22 PM, Michael S. Fischer wrote: Sure, but this is also the sort of content that can be cached back upstream using ordinary HTTP headers. No, it cannot. Again, the use case is dynamically-generated content that is subject to change at unpredictable intervals but which is otherwise fairly static for some length of time, and where serving stale content after a change is unacceptable. Ordinary HTTP headers just don't solve that use case without unnecessary loading of the backend. Isn't this what if-modified-since requests are for? 304 not modified is a pretty small request/response, though I can understand the tendency to want to push it out to the frontend caches. I would think the management overhead of maintaining two seperate expirations wouldn't be worth the extra hassle just to save yourself some ims requests to a backend. Unless of course varnish doesn't support ims requests in a usable way, I haven't actually tested it myself. --Dave ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: cache empties itself?
Am Freitag 04 April 2008 01:32:28 schrieb DHF: Sascha Ottolski wrote: however, my main problem is currently that the varnish childs keep restarting, and that this empties the cache, which effectively renders the whole setup useless for me :-( if the cache has filled up, it works great, if it restarts empty, obviously it doesn't. is there anything I can do to prevent such restarts? Varnish doesn't just restart on its own. Check to make sure you aren't sending a kill signal if you are running logrotate through a cronjob. I'm not sure if a HUP will empty the cache or not. --Dave I definetely did nothing like this, I've observed restarts out of the blue. I'm no giving the trunk a try, hopefully there's an improvement to that matter. what I did once in a while is to vcl.load, vcl.use. will this force a restart of the child, thus flushing the cache? Thanks again, Sascha ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: cache empties itself?
Am Freitag 04 April 2008 04:37:44 schrieb Ricardo Newbery:
sub vcl_fetch {
if (obj.ttl 120s) {
set obj.ttl = 120s;
}
}
Or you can invent your own header... let's call it X-Varnish-1day
sub vcl_fetch {
if (obj.http.X-Varnish-1day) {
set obj.ttl = 86400s;
}
}
so it seems like I'm on the right track, thanks for clarifying. now, is
the ttl a information local to varnish, or will it set headers also (if
I look into the headers of my varnishs' responses, it doesn't appear
so)?
what really confuses me: the man pages state a little different
semantics for default_ttl. in man varnishd:
-t ttl Specifies a hard minimum time to live for cached
documents. This is a shortcut for specifying the
default_ttl run-time parameter.
default_ttl
The default time-to-live assigned to objects if neither
the backend nor the configuration assign one. Note
that changes to this parameter are not applied retroac‐
tively.
The default is 120 seconds.
hard minimum sounds to me as if it would overwrite any setting the
backend has given. however, in man vcl it's explained, that default_ttl
does only affect documents without backend given TTL:
The following snippet demonstrates how to force a minimum TTL
for all documents. Note that this is not the same as setting
the default_ttl run-time parameter, as that only affects doc‐
ument for which the backend did not specify a TTL.
sub vcl_fetch {
if (obj.ttl 120s) {
set obj.ttl = 120s;
}
}
the examples have a unit (s) appended, as in the example of the man
page, that suggests that I could also append things like m, h, d (for
minutes, hours, days)?
BTW, in the trunk version, the examples for a backend definition have
still the old syntax.
backend www {
set backend.host = www.example.com;
set backend.port = 80;
}
instead
backend www {
.host = www.example.com;
.port = 80;
}
Thanks a lot,
Sascha
___
varnish-misc mailing list
varnish-misc@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: cache empties itself?
Am Freitag 04 April 2008 10:11:52 schrieb Stig Sandbeck Mathisen: On Fri, 4 Apr 2008 09:01:57 +0200, Sascha Ottolski [EMAIL PROTECTED] said: I definetely did nothing like this, I've observed restarts out of the blue. I'm no giving the trunk a try, hopefully there's an improvement to that matter. If the varnish caching process dies for some reason, the parent varnish process will start a new one to keep the service running. This new one will not re-use the cache of the previous. With all that said, the varnish caching process should not die in this way, that is undesirable behaviour. If you'd like to help debugging this issue, take a look at http://varnish.projects.linpro.no/wiki/DebuggingVarnish I already started my proxies with the latest trunk and corecumps enabled, and cross my fingers. so far it's running for about 11 hours... BTW, if I have 32 GB of RAM, and 517 GB of cache file, how large will the core dump be? Note that if you run a released version, your issue may have beeen fixed already in a later release, the related branch, or in trunk, what I did once in a while is to vcl.load, vcl.use. will this force a restart of the child, thus flushing the cache? No. The reason Varnish has vcl.load and vcl.use is to make sure you don't have to restart anything, thus losing your cached data. excellent. the numbers that are shown next to the config in vcl.list, is it the number of connections that (still) use it? Thanks again, Sascha ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: cache empties itself?
On Fri, Apr 4, 2008 at 3:20 AM, Sascha Ottolski [EMAIL PROTECTED] wrote: you are right, _if_ the working set is small. in my case, we're talking 20+ mio. small images (5-50 KB each), 400+ GB in total size, and it's growing every day. access is very random, but there still is a good amount of hot objects. and to be ready for a larger set it cannot reside on the webserver, but lives on a central storage. access performance to the (network) storage is relatively slow, and our experiences with mod_cache from apache were bad, that's why I started testing varnish. Ah, I see. The problem is that you're basically trying to compensate for a congenital defect in your design: the network storage (I assume NFS) backend. NFS read requests are not cacheable by the kernel because another client may have altered the file since the last read took place. If your working set is as large as you say it is, eventually you will end up with a low cache hit ratio on your Varnish server(s) and you'll be back to square one again. The way to fix this problem in the long term is to split your file library into shards and put them on local storage. Didn't we discuss this a couple of weeks ago? Best regards, --Michael ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: cache empties itself?
Am Freitag 04 April 2008 18:11:23 schrieb Michael S. Fischer: On Fri, Apr 4, 2008 at 3:20 AM, Sascha Ottolski [EMAIL PROTECTED] wrote: you are right, _if_ the working set is small. in my case, we're talking 20+ mio. small images (5-50 KB each), 400+ GB in total size, and it's growing every day. access is very random, but there still is a good amount of hot objects. and to be ready for a larger set it cannot reside on the webserver, but lives on a central storage. access performance to the (network) storage is relatively slow, and our experiences with mod_cache from apache were bad, that's why I started testing varnish. Ah, I see. The problem is that you're basically trying to compensate for a congenital defect in your design: the network storage (I assume NFS) backend. NFS read requests are not cacheable by the kernel because another client may have altered the file since the last read took place. If your working set is as large as you say it is, eventually you will end up with a low cache hit ratio on your Varnish server(s) and you'll be back to square one again. The way to fix this problem in the long term is to split your file library into shards and put them on local storage. Didn't we discuss this a couple of weeks ago? exactly :-) what can I see, I did analyze the logfiles, and learned that despite the fact that a lot of the access are truly random, there is still a good amount of the request concentrated to a smaller set of the images. of course, the set is changing over time, but thats what a cache can handle perfectly. and my experiences seem to prove my theory: if varnish keeps running like it is now for about 18 hours *knock on wood*, the cache hit rate is close to 80 %! and that takes so much pressure from the backend that the overall performance is just awesome. putting the files on local storage just doesn't scales well. I'm more thinking about splitting the proxies like discussed on the list before: a loadbalancer could distribute the URLs in a way that each cache holds it's own share of the objects. Cheers, Sascha ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: cache empties itself?
On Apr 4, 2008, at 2:50 AM, Michael S. Fischer wrote: On Thu, Apr 3, 2008 at 8:59 PM, Ricardo Newbery [EMAIL PROTECTED] wrote: Well, first of all you're setting up a false dichotomy. Not everything fits neatly into your apparent definitions of dynamic versus static. Your definitions appear to exclude the use case where you have cacheable content that is subject to change at unpredictable intervals but which is otherwise fairly static for some length of time. In my experience, you almost never need a caching proxy for this purpose. Most modern web servers are perfectly capable of serving static content at wire speed. Moreover, if your origin servers have a reasonable amount of RAM and the working set size is relatively small, the static objects are already likely to be in the buffer cache. In a scenario such as this, having caching proxies upstream for these sorts of objects can actually be *worse* in terms of performance -- consider the wasted time processing a cache miss for content that's already cached downstream. Again, static content isn't only the stuff that is served from filesystems in the classic static web server scenario. There are plenty of dynamic applications that process content from database -- applying skins and compositing multiple elements into a single page while filtering every element or otherwise applying special processing based on a user's access privileges. An example of this is a dynamic content management system like Plone or Drupal. In many cases, these dynamic responses are fairly static for some period of time but there is still a definite performance hit, especially under load. Ric ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: cache empties itself?
Sascha Ottolski wrote: Am Freitag 04 April 2008 18:11:23 schrieb Michael S. Fischer: Ah, I see. The problem is that you're basically trying to compensate for a congenital defect in your design: the network storage (I assume NFS) backend. NFS read requests are not cacheable by the kernel because another client may have altered the file since the last read took place. If your working set is as large as you say it is, eventually you will end up with a low cache hit ratio on your Varnish server(s) and you'll be back to square one again. The way to fix this problem in the long term is to split your file library into shards and put them on local storage. Didn't we discuss this a couple of weeks ago? exactly :-) what can I see, I did analyze the logfiles, and learned that despite the fact that a lot of the access are truly random, there is still a good amount of the request concentrated to a smaller set of the images. of course, the set is changing over time, but thats what a cache can handle perfectly. and my experiences seem to prove my theory: if varnish keeps running like it is now for about 18 hours *knock on wood*, the cache hit rate is close to 80 %! and that takes so much pressure from the backend that the overall performance is just awesome. putting the files on local storage just doesn't scales well. I'm more thinking about splitting the proxies like discussed on the list before: a loadbalancer could distribute the URLs in a way that each cache holds it's own share of the objects. By putting intermediate caches between the file storage and the client, you are essentially just spreading the storage locally between cache boxes, so if this method doesn't scale then you are still in need of a design change, and frankly so am I :) What you need to model is the popularity curve for your content, if your images do not fit with an 80/20 rule of popularity, ie. 20% of your images soak up less than 80% or requests, then you will spend more time thrashing the caches than serving the content, and Michael is right, you would be better served to dedicate web servers with local storage and shard your images across them. If 80% of your content is rarely viewed, then using the same amount of hardware defined as caching accelerators, you will see an increase in throughput due to more hardware serving a smaller number of images. It all depends on your content and users viewing habits. --Dave ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: cache empties itself?
On Fri, Apr 4, 2008 at 11:05 AM, Ricardo Newbery [EMAIL PROTECTED] wrote: Again, static content isn't only the stuff that is served from filesystems in the classic static web server scenario. There are plenty of dynamic applications that process content from database -- applying skins and compositing multiple elements into a single page while filtering every element or otherwise applying special processing based on a user's access privileges. An example of this is a dynamic content management system like Plone or Drupal. In many cases, these dynamic responses are fairly static for some period of time but there is still a definite performance hit, especially under load. If that's truly the case, then your CMS should be caching the output locally. --Michael ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: cache empties itself?
On Apr 4, 2008, at 2:04 PM, Michael S. Fischer wrote: On Fri, Apr 4, 2008 at 11:05 AM, Ricardo Newbery [EMAIL PROTECTED] wrote: Again, static content isn't only the stuff that is served from filesystems in the classic static web server scenario. There are plenty of dynamic applications that process content from database -- applying skins and compositing multiple elements into a single page while filtering every element or otherwise applying special processing based on a user's access privileges. An example of this is a dynamic content management system like Plone or Drupal. In many cases, these dynamic responses are fairly static for some period of time but there is still a definite performance hit, especially under load. If that's truly the case, then your CMS should be caching the output locally. Should be? Why? If you can provide this capability via a separate process like Varnish, then why should your CMS do this instead? Am I missing some moral dimension to this issue? ;-) In any case, both of these examples, Plone and Drupal, can indeed cache the output locally but that is still not as fast as placing a dedicated cache server in front. It's almost always faster to have a dedicated single-purpose process do something instead of cranking up the hefty machinery for requests that can be adequately served by the lighter process. Ric ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: cache empties itself?
Sascha Ottolski wrote: how can this be? My varnish runs for about 36 hours now. yesterday evening, the resident memory size was like 10 GB, which is still way below the available 32. later that evening, I stopped letting request to the proxy over night. now I came back, let the request back in, and am wondering that I see a low cacht hit rate. looking a bit closer it appears as if the cache got smaller over night, now the process only consumes less than 1 GB of resident memory, which fits the reported bytes allocated in the stats. can I somehow find out why my cached objects were expired? I have a varnishlog -w running all the time, the the information might there. but, what to look for, and even more important, how can I prevent that expiration? I started the daemon with -p default_ttl=31104000 to make it cache very aggresively... There could be a lot of factors, is apache setting a max-age on the items? As it says in the man page: default_ttl The default time-to-live assigned to objects if neither the backend nor the configuration assign one. Note that changes to this param- eter are not applied retroactively. Is this running on a test machine in a lab where you can control the requests this box gets? If so you should run some tests to make sure that you really are caching objects. Run wireshark on the apache server listening on port 80, and using curl send two requests for the same object, and make sure that only one request hits the apache box. If thats working like you expect, and the Age header is incrementing, then you need to run some tests using a typical workload that your apache server expects to see. Are you setting cookies on this site? I think what is happening is that you are setting a max-age on objects from apache ( which you can verify using curl, netcat, telnet, whatever you like ), and varnish is honoring that setting and expiring items as instructed. I'm not awesome with varnishtop and varnishlog yet, so I'm probably not the one to ask about getting those to show you an objects attributes, anyone care to assist on that front? --Dave ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: cache empties itself?
On Thu, Apr 3, 2008 at 10:26 AM, Sascha Ottolski [EMAIL PROTECTED] wrote: All this with 1.1.2. It's vital to my setup to cache as many objects as possible, for a long time, and that they really stay in the cache. Is there anything I could do to prevent the cache being emptied? May be I've been bitten by a bug and should give the trunk a shot? Just set the Expires: headers on the origin (backend) server responses to now + 10 years or something. --Michael ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: cache empties itself?
Am Donnerstag 03 April 2008 18:07:53 schrieb DHF: Sascha Ottolski wrote: how can this be? My varnish runs for about 36 hours now. yesterday evening, the resident memory size was like 10 GB, which is still way below the available 32. later that evening, I stopped letting request to the proxy over night. now I came back, let the request back in, and am wondering that I see a low cacht hit rate. looking a bit closer it appears as if the cache got smaller over night, now the process only consumes less than 1 GB of resident memory, which fits the reported bytes allocated in the stats. can I somehow find out why my cached objects were expired? I have a varnishlog -w running all the time, the the information might there. but, what to look for, and even more important, how can I prevent that expiration? I started the daemon with -p default_ttl=31104000 to make it cache very aggresively... There could be a lot of factors, is apache setting a max-age on the items? As it says in the man page: default_ttl The default time-to-live assigned to objects if neither the backend nor the configuration assign one. Note that changes to this param- eter are not applied retroactively. Is this running on a test machine in a lab where you can control the requests this box gets? If so you should run some tests to make sure that you really are caching objects. Run wireshark on the apache server listening on port 80, and using curl send two requests for the same object, and make sure that only one request hits the apache box. If thats working like you expect, and the Age header is incrementing, then you need to run some tests using a typical workload that your apache server expects to see. Are you setting cookies on this site? I think what is happening is that you are setting a max-age on objects from apache ( which you can verify using curl, netcat, telnet, whatever you like ), and varnish is honoring that setting and expiring items as instructed. I'm not awesome with varnishtop and varnishlog yet, so I'm probably not the one to ask about getting those to show you an objects attributes, anyone care to assist on that front? --Dave dave, thanks a lot, I may have confused it with varnishd -t, which doesn't seem to be the same as -p default_ttl? hmm, but then again, the manual says it's a shortcut, but the semantic sound different then the above: -t ttl Specifies a hard minimum time to live for cached documents. This is a shortcut for specifying the default_ttl run-time parameter. Cheers, Sascha ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: cache empties itself?
Am Donnerstag 03 April 2008 18:07:53 schrieb DHF: how can this be? My varnish runs for about 36 hours now. yesterday evening, the resident memory size was like 10 GB, which is still way below the available 32. later that evening, I stopped letting request to the proxy over night. now I came back, let the request back in, and am wondering that I see a low cacht hit rate. looking a bit closer it appears as if the cache got smaller over night, now the process only consumes less than 1 GB of resident memory, which fits the reported bytes allocated in the stats. now I just had to learn the hard way... 1. if I stop and start the child via the management port, the cache is empty afterwards I did this, because I couldn't manage to change the config, at least to me it looked that way: vcl.list 200 52 0 boot 44085 default *7735 default2 vcl.discard default 106 37 No configuration named default known. 200 0 vcl.list 200 52 0 boot 44085 default *7750 default2 vcl.show default 106 37 No configuration named default known. 2. but even worse, I've just seen that a new child was born somehow, which also emptied the cache is this some regular behaviour, or was there a crash? All this with 1.1.2. It's vital to my setup to cache as many objects as possible, for a long time, and that they really stay in the cache. Is there anything I could do to prevent the cache being emptied? May be I've been bitten by a bug and should give the trunk a shot? BTW, after starting to play around with varnish, I'm really impressed, it's a bit frustrating sometimes to understand everything, but the outcome is very impreesing. Thanks for such a nice piece of software! Thanks a lot, Sascha ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: cache empties itself?
Michael S. Fischer wrote:
On Thu, Apr 3, 2008 at 10:26 AM, Sascha Ottolski [EMAIL PROTECTED] wrote:
All this with 1.1.2. It's vital to my setup to cache as many objects as
possible, for a long time, and that they really stay in the cache. Is
there anything I could do to prevent the cache being emptied? May be
I've been bitten by a bug and should give the trunk a shot?
Just set the Expires: headers on the origin (backend) server responses
to now + 10 years or something.
If you're not using php or some other cgi app, you can set headers using
mod_headers in apache, if you are running a web app, just set the
headers within the app itself. You can also explicitly set the ttl on
objects in the cache using vcl code, but moving the load off the cache
to the backend makes more sense since you'll be cutting traffic down to
apache and it would free up cycles to modify headers. If you have your
heart set on making varnish do the work you could add something like this:
sub vcl_fetch {
if (!obj.valid) {
error;
}
if (!obj.cacheable ) {
pass;
}
if (obj.http.Set-Cookie) {
pass;
}
if (req.url ~ \.(jpg|jpeg|gif|png)$) {
set obj.ttl = 31449600;
}
insert;
}
But I would first look at getting apache to set the age correctly and
leave varnish to do what its good at.
--Dave
___
varnish-misc mailing list
varnish-misc@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: cache empties itself?
Am Donnerstag 03 April 2008 19:30:25 schrieb Michael S. Fischer: On Thu, Apr 3, 2008 at 10:26 AM, Sascha Ottolski [EMAIL PROTECTED] wrote: All this with 1.1.2. It's vital to my setup to cache as many objects as possible, for a long time, and that they really stay in the cache. Is there anything I could do to prevent the cache being emptied? May be I've been bitten by a bug and should give the trunk a shot? Just set the Expires: headers on the origin (backend) server responses to now + 10 years or something. --Michael thanks for the hint. unfortunately, not quite what I want. I want varnish to keep the objects very long, so that it not has to ask the backend to often. therefore, it's important that the cache keeps growing, instead of vanishing once in a while. and I don't wan't upstream caches or browsers to cache that long, only varnish, so setting headers doesn't seem to fit. Cheers, Sascha ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: cache empties itself?
On Thu, Apr 3, 2008 at 10:58 AM, Sascha Ottolski [EMAIL PROTECTED] wrote: and I don't wan't upstream caches or browsers to cache that long, only varnish, so setting headers doesn't seem to fit. Why not? Just curious. If it's truly cachable content, it seems as though it would make sense (both for your performance and your bandwidth outlays) to let browsers cache. --Michael ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: cache empties itself?
On Apr 3, 2008, at 11:04 AM, Michael S. Fischer wrote: On Thu, Apr 3, 2008 at 10:58 AM, Sascha Ottolski [EMAIL PROTECTED] wrote: and I don't wan't upstream caches or browsers to cache that long, only varnish, so setting headers doesn't seem to fit. Why not? Just curious. If it's truly cachable content, it seems as though it would make sense (both for your performance and your bandwidth outlays) to let browsers cache. --Michael Can't speak for the OP but a common use case is where you want an aggressive cache but still need to retain the ability to purge the cache when content changes. As far as I know, there are only two ways to do this without contaminating downstream caches with potentially stale content... via special treatment in the varnish config (which is what the OP is trying to do) or using a special header that only your varnish instance will recognize (like Surrogate-Control, which as far as I know Varnish does not support out-of-the-box but Squid3 does). Ric ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: cache empties itself?
Sascha Ottolski wrote: however, my main problem is currently that the varnish childs keep restarting, and that this empties the cache, which effectively renders the whole setup useless for me :-( if the cache has filled up, it works great, if it restarts empty, obviously it doesn't. is there anything I can do to prevent such restarts? Varnish doesn't just restart on its own. Check to make sure you aren't sending a kill signal if you are running logrotate through a cronjob. I'm not sure if a HUP will empty the cache or not. --Dave ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: cache empties itself?
On Apr 3, 2008, at 12:45 PM, Michael S. Fischer wrote:
On Thu, Apr 3, 2008 at 11:53 AM, Ricardo Newbery [EMAIL PROTECTED]
wrote:
On Apr 3, 2008, at 11:04 AM, Michael S. Fischer wrote:
On Thu, Apr 3, 2008 at 10:58 AM, Sascha Ottolski [EMAIL PROTECTED]
wrote:
and I don't wan't upstream caches or browsers to cache that long,
only
varnish, so setting headers doesn't seem to fit.
Why not? Just curious. If it's truly cachable content, it seems
as
though it would make sense (both for your performance and your
bandwidth outlays) to let browsers cache.
Can't speak for the OP but a common use case is where you want an
aggressive cache but still need to retain the ability to purge the
cache
when content changes. As far as I know, there are only two ways to
do this
without contaminating downstream caches with potentially stale
content...
via special treatment in the varnish config (which is what the OP
is trying
to do) or using a special header that only your varnish instance will
recognize (like Surrogate-Control, which as far as I know Varnish
does not
support out-of-the-box but Squid3 does).
Seems to me that this is rather brittle and error-prone.
- If a particular resource is truly dynamic, then it should not be
cachable at all.
- If a particular resource can be considered static (i.e. cachable),
yet updateable, then it is *far* safer to version your URLs, as you
have zero control over intermediate proxies.
--Michael
If done correctly, this is neither brittle nor error-prone. This is
the point after all of the Surrogate-Control header -- A way for your
backend to instruct your proxy (or surrogate if you insist) how to
handle your content in a way that is invisible to intermediate proxies
not under your control.
While not as flexible as the Surrogate-Control header, you can do the
same just with special stanzas in your varnish.vcl. In fact, the vcl
man page contains one example of how to do this for all objects to
enforce a minimum ttl:
sub vcl_fetch {
if (obj.ttl 120s) {
set obj.ttl = 120s;
}
}
Or you can invent your own header... let's call it X-Varnish-1day
sub vcl_fetch {
if (obj.http.X-Varnish-1day) {
set obj.ttl = 86400s;
}
}
Neither of these two examples are unsafe and both are invisible to
intermediate proxies.
With regards to URL versioning, this is indeed a powerful strategy --
assuming your backend is capable of doing this. But it's a strategy
generally only appropriate for supporting resources like inline
graphics, css, and javascript. URL versioning is usually not
appropriate for html pages or other primary resources that are
intended to be reached directly by the end user and whose URLs must
not change.
Ric
___
varnish-misc mailing list
varnish-misc@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: cache empties itself?
On Thu, Apr 3, 2008 at 7:37 PM, Ricardo Newbery [EMAIL PROTECTED] wrote: URL versioning is usually not appropriate for html pages or other primary resources that are intended to be reached directly by the end user and whose URLs must not change. Back to square one. Are these latter resources dynamic, or are they static? - If they are dynamic, neither your own proxies nor upstream proxies should be caching the content. - If they are static, then they should be cacheable for the same amount of time all the way upstream (modulo protected URLs). I've haven't yet seen a defensible need for varying cache lifetimes, depending on the proximity of the proxy to the origin server, as this request seems to be. Of course, I'm open to being convinced otherwise :-) --Michael ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: cache empties itself?
On Apr 3, 2008, at 7:46 PM, Michael S. Fischer wrote: On Thu, Apr 3, 2008 at 7:37 PM, Ricardo Newbery [EMAIL PROTECTED] wrote: URL versioning is usually not appropriate for html pages or other primary resources that are intended to be reached directly by the end user and whose URLs must not change. Back to square one. Are these latter resources dynamic, or are they static? - If they are dynamic, neither your own proxies nor upstream proxies should be caching the content. - If they are static, then they should be cacheable for the same amount of time all the way upstream (modulo protected URLs). I've haven't yet seen a defensible need for varying cache lifetimes, depending on the proximity of the proxy to the origin server, as this request seems to be. Of course, I'm open to being convinced otherwise :-) Well, first of all you're setting up a false dichotomy. Not everything fits neatly into your apparent definitions of dynamic versus static. Your definitions appear to exclude the use case where you have cacheable content that is subject to change at unpredictable intervals but which is otherwise fairly static for some length of time. Sometimes, in such a case, serving stale content for some time after an edit is an acceptable compromise between performance and freshness but often it is not. And sometimes, impacting overall performance by hitting the backend for every such request is also undesirable. Thankfully, those are not the only choices. With a combination of PURGE requests and something like Surrogate-Control (or hardcoded behavior in your reverse-proxy config), you can still insure immediate freshness (or whatever level of freshness you require) without forcing your backend to do all the work. Ric ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
