In message <[EMAIL PROTECTED]>, Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=
writes:
>I assume all the red arrows point to vcl_error()?
Yes, I didn't want to clutter the drawing with them.
>> vcl_hash{}
>> Place holder for the idea that it might be desirable to
>> hash on more or different fields than (URL+Host:).
>>
>> Not fully thought through yet, may or may not happen.
>
>Strictly speaking, you need to hash on every header mentioned in
>Vary:, but you don't even have that information until you've retrieved
>at least one version of the document from the backend - and even then,
>when a new request comes in, you need to identify the requested
>document to know which headers to hash on - so it looks like we need a
>two-level hash.
You can't hash on Vary, it's a response side header. Vary must be
handled by traversing the list of possible objects looking for matches.
>> vcl_hit{}
>> Not really sure what you would do here, but you get
>> the chance if you dream up something.
>>
>> One possible thing would be to react to high hitrates
>> and initiate compression.
>
>...or check the time remaining before expiry and initiate a prefetch?
>You don't mention vcl_timeout, which in any case isn't called until
>after the document has expired.
My plans for vcl_timeout{} are not firm yet, but the idea is to
call vcl_timeout{} before expiry to decide on prefetching and
possibly compression.
The comment above therefore hints at the vcl_hit{} being able
to reduce the timeout for an object, so vcl_timeout{} can get
a shot at compressing it.
But lets concentrate on the "traffic" part for now, vcl_timeout{}
needs a bit more time with the thinking cap.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
_______________________________________________
varnish-misc mailing list
[email protected]
http://projects.linpro.no/mailman/listinfo/varnish-misc
