I think that conditional GETs could be really useful here. I just don't know how varnish works in this scenario. Maybe someone from the varnish development team can shed some light here :)<br><br><div class="gmail_quote">
On Fri, Dec 17, 2010 at 12:42 PM, James A. Robinson <span dir="ltr"><<a href="mailto:jim.robinson@stanford.edu">jim.robinson@stanford.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">On Thu, Dec 16, 2010 at 12:31, Paulo Paracatu <<a href="mailto:paulo@aliancaproject.com">paulo@aliancaproject.com</a>> wrote:<br>
> If I understood it, the purging method isn't automatic, right? I'd need to<br>
> purge the content everytime it is modified.<br>
> This is kinda stupid... I host more than 10k sites, modifying files<br>
> everytime. If I set a high TTL, the backend will be happy and the webmaster<br>
> will be angry. If I set a low TTL, the webmaster will be happy, but the<br>
> backend will die. Plus, there is no point using a cache if the TTL is low.<br>
<br>
</div>In a later post you ask about whether or not varnish could be<br>
configured to send a conditional GET on every request<br>
<br>
Basically varnish would be looking up an item in its own cache, seeing<br>
if it had a Last-Modified or ETag header from the backend, and sending<br>
a conditional GET -- if it got an entity back it'd store that entity<br>
as the new version, otherwise serve the old.  I'd be curious if<br>
anyone's put together VCL logic that is capable of that.  It'd be good<br>
to know how to do it.<br>
<br>
If it's possible to due, this technique might work well when you are<br>
fronting a backend that is very fast at computing conditional GETs,<br>
e.g., static files that can be examined to see if its inode, size, or<br>
last modified time has changed.  I imagine most people using varnish<br>
have slower backend servers, ones that build dynamic content and<br>
aren't able to respond to conditional GETs any more efficiently than<br>
they could respond to an unqualified GET.<br>
<br>
One of the places we use varnish at my dept is fronting a large (half<br>
terabyte of about six million files) static file server.  Instead of<br>
using some form of conditional GET, what we use are cache channels.<br>
<br>
  <a href="http://tools.ietf.org/id/draft-nottingham-http-cache-channels-01.txt" target="_blank">http://tools.ietf.org/id/draft-nottingham-http-cache-channels-01.txt</a><br>
<br>
When various programs are updating the backend server static files<br>
they POST the filepath to our cache channel server.  We have another<br>
program running that monitors the cache channel once a minute for<br>
updates, and when it sees a new entry show up it turns around and<br>
sends a PURGE request to varnish.<br>
<br>
Jim<br>
<br>
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -<br>
<font color="#888888">James A. Robinson                       <a href="mailto:jim.robinson@stanford.edu">jim.robinson@stanford.edu</a><br>
Stanford University HighWire Press      <a href="http://highwire.stanford.edu/" target="_blank">http://highwire.stanford.edu/</a><br>
+1 650 7237294 (Work)                   +1 650 7259335 (Fax)<br>
</font><div><div></div><div class="h5"><br>
_______________________________________________<br>
varnish-misc mailing list<br>
<a href="mailto:varnish-misc@varnish-cache.org">varnish-misc@varnish-cache.org</a><br>
<a href="http://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc" target="_blank">http://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc</a><br>
</div></div></blockquote></div><br>