Re: Best practice for caching scenario with different backend servers but same content
On Sat, Aug 14, 2021 at 10:54 AM Hamidreza Hosseini
wrote:
>
> Hi,
> Thanks to you and all varnish team for such answers that helped me alot,
> I read the default varnish cache configuration again:
> https://github.com/varnishcache/varnish-cache/blob/6.0/bin/varnishd/builtin.vcl
> and find out vcl_hash as follow:
>
> ```
> sub vcl_hash {
> hash_data(req.url);
> if (req.http.host) {
> hash_data(req.http.host);
> } else {
> hash_data(server.ip);
> }
> return (lookup);
> }
>
> ```
> So, if I change vcl_hash like following , would it be enough for my
> purpose?(I mean caching the same object from different backends just once
> with roundrobin directive !:)
>
> ```
>
> sub vcl_hash {
> hash_data(req.url);
> return (lookup);
> }
>
> ```
>
> By this config I told varnish just cache the content based on the 'req.url'
> not 'req.http.host' therefore with the same content but different backend
> varnish would cache once(If I want to use round robin directive instead of
> shard directive ), Is this true? what bad consequences may it cause in the
> future by this configuration?
In this case req.http.host usually refers to the the domain end users
resolve to find your varnish server (or other hops in front of it). It
is usually the same for every client, let's take www.myapp.com as an
example. If your varnish server is in front of multiple services, you
should be handling the different host headers explicitly. For exampe
if you have exactly two domains you should normalize them to some
canonical form. Using the same example domain that could be
www.myapp.com and static.myapp.com for instance.
In that case hashing the URL only would prevent you from adding new
domains through your Varnish server. It won't hurt if you know you
will only ever have one domain to deal with, but hashing the host will
also not hurt as long as you normalize it to a unique value.
You are correct that by default hashing the request appropriately will
help the shard director do the right thing out of the box. I remember
however that you only wanted to hash a subset of the URL for video
segments, so hashing the URL as-is won't provide the behavior you are
looking for.
Dridi
___
varnish-misc mailing list
varnish-misc@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
Re: Docker images: Alpine and new architecture support
Replying to all this time On Fri, Aug 13, 2021, 08:48 Guillaume Quintard wrote: > > On Fri, Aug 13, 2021 at 3:31 AM Geoff Simmons wrote: > >> Can you (or anyone) share some info about how well Varnish performs with >> musl libc? >> > > Good question, and unfortunately, I don't have a good answer in return as > I haven't benchmarked it, so feedback is more than welcome. > > What I can comment on is that musl is quite adamant about being standard > and pure, so it will hopefully be more portable and will let compilers do > more work. As you mentioned, we've had issues in the past compiling and > testing with it, but it should be all behind us now: > - there were some header issues that prevented us from compiling, but we > fixed that a couple of years ago > - libbacktrace isn't available on Alpine, which prompted the move to > libunwind (can we make it the default now?) > - it has help fix a few compiler warning issues lately > > Cheers, > > -- > Guillaume Quintard > > ___ varnish-misc mailing list varnish-misc@varnish-cache.org https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
