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
Тук няма достатъчно информация. Необходим е запис в varnishlog за такава бавна заявка. Като цяло, освен ако заявката не е предадена/подадена, 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

Кеширане на частични обекти с varnish 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/Споделяне на статии. Благодаря много! - person mgo; 11.02.2021