Varnish.4.x не кэширует запросы диапазона

Мы пытаемся заставить Varnish кэшировать запросы диапазона. Мы используем Varnish 4.0.

Мы следующие конфигурации

vcl 4.0;

import std;

# Default backend definition. Set this to point to your content server.
backend default {
    .host = "194.142.x.x";
    .port = "8008";
}

sub vcl_recv {

if (req.url ~ "(?i)\.(png|avi|mkv|mp4)(\?[a-z0-9]+)?$") {
    unset req.http.Cookie;
  }
    # Happens before we check if we have this in cache already.
    #
    # Typically you clean up the request here, removing cookies you don't need,
    # rewriting the request, etc.

  set req.http.host = regsub(req.http.host, "v\.","\rms\.");

  std.log("REWRITED TO"+req.http.host+"  "+req.url);



}

sub vcl_backend_response {
    # Happens after we have read the response headers from the backend.
    #
    # Here you clean the response headers, removing silly Set-Cookie headers
    # and other mistakes your backend does.
}

sub vcl_deliver {
    # Happens when we have all the pieces we need, and are about to send the
    # response to the client.
    #
                                                               vcl 4.0;

import std;

# Default backend definition. Set this to point to your content server.
backend default {
    .host = "194.142.x.x";
    .port = "8008";
}

sub vcl_recv {

if (req.url ~ "(?i)\.(png|avi|mkv|mp4)(\?[a-z0-9]+)?$") {
    unset req.http.Cookie;
  }
    # Happens before we check if we have this in cache already.
    #
    # Typically you clean up the request here, removing cookies you don't need,
    # rewriting the request, etc.

  set req.http.host = regsub(req.http.host, "v\.","\rms\.");

  std.log("REWRITED TO"+req.http.host+"  "+req.url);



}

sub vcl_backend_response {
    # Happens after we have read the response headers from the backend.
    #
    # Here you clean the response headers, removing silly Set-Cookie headers
    # and other mistakes your backend does.
}

sub vcl_deliver {
    # Happens when we have all the pieces we need, and are about to send the
    # response to the client.
    #

как всегда запросы диапазона обслуживаются слишком долго, поэтому мы чувствуем, что они не кэшируются, поскольку исходный сервер поражен.


person I Am Bajpan Gosh    schedule 10.07.2015    source источник
comment
Здесь недостаточно информации. Необходима запись в лакологе о таком медленном запросе. В общем, если запрос не передается/передается по конвейеру, Varnish запросит обычную выборку объекта из бэкенда и начнет обслуживать клиента всякий раз, когда появляется запрошенный диапазон байтов.   -  person lkarsten    schedule 14.07.2015


Ответы (2)


Вы можете решить это...?

Я почти уверен, что конфигурация блока:

if (req.url ~ "(?i)\.(png|avi|mkv|mp4)(\?[a-z0-9]+)?$") {
    unset req.http.Cookie;
  }
    # Happens before we check if we have this in cache already.
    #
    # Typically you clean up the request here, removing cookies you don't need,
    # rewriting the request, etc.

  set req.http.host = regsub(req.http.host, "v\.","\rms\.");
  std.log("REWRITED TO"+req.http.host+"  "+req.url);

Находятся в неправильном положении, должны быть в vcl_backend_response, а не в vcl_recv

person Netlabs    schedule 06.10.2015

Кэширование частичных объектов с помощью лака 4.0

sub vcl_recv {
    if (req.http.Range ~ "bytes=") {
        set req.http.x-range = req.http.Range;
    }
}

sub vcl_hash {
    if (req.http.x-range ~ "bytes=") {
            hash_data(req.http.x-range);
            unset req.http.Range;
    }
}

sub vcl_backend_fetch {
    if (bereq.http.x-range) {
        set bereq.http.Range = bereq.http.x-range;
    }
}

sub vcl_backend_response {
    if (bereq.http.x-range ~ "bytes=" && beresp.status == 206) {
        set beresp.ttl = 10m;
        set beresp.http.CR = beresp.http.content-range;
    }
}

sub vcl_deliver {
    if (resp.http.CR) {
        set resp.http.Content-Range = resp.http.CR;
        unset resp.http.CR;
    }
}
person sajjadG    schedule 02.09.2018
comment
Это работает и исправляет ошибку 416 при совместном использовании LinkedIn Inspector/Article. Большое спасибо! - person mgo; 11.02.2021