Запрет лака остается в банлисте навсегда

Question

У меня есть набор лаков (Varnish 3), работающий на сервере разработки, и такая же установка на рабочем сервере. Сервер разработки не получает никакого трафика, если я не тестирую его. Производственный сервер получает большой трафик около 80 веб-сайтов, проходящих через этот экземпляр. Веб-сайты одинаковы, поэтому один VCL для всех подойдет.

В настоящее время я тестирую с помощью smart-банов URL и ban_lurker.

Я ожидаю, что когда я добавлю бан, даже если бан не будет работать по какой-то причине, он должен остаться там в банлисте только для самого большого TTL в моем кэше + backend-response-grace-period.

Эта проблема

Проблема в том, что на моем производственном сервере вместо этого бан остается в банлисте вечно (или, по крайней мере, в течение 24 часов, так как это время, которое я дал, чтобы его убрали).

Поэтому я настроил свой VCL так, чтобы ожидать, что ни один объект кеша не сможет оставаться в кеше дольше, чем 20 минут, так как я устанавливаю эти 20 минут из моего vcl_fetch и принудительно устанавливаю beresp.grace в 0.

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

Я что-то там пропускаю??

VCL

Может кто-нибудь взглянуть на мой VCL и сказать, что я делаю не так? Обратите внимание, что я пропустил некоторые вещи, такие как конфигурация бэкэнда и конфигурация очистки / запрета, потому что я думаю, что это сейчас не имеет значения. Поправьте меня если я ошибаюсь:)

import std;

# Define backends
include "backends.vcl";

# Define recv basics
sub vcl_recv {
    if (req.request != "GET" &&
      req.request != "HEAD" &&
      req.request != "PUT" &&
      req.request != "POST" &&
      req.request != "TRACE" &&
      req.request != "OPTIONS" &&
      req.request != "DELETE" &&
      req.request != "PURGE" &&
      req.request != "BAN") {
        /* Non-RFC2616 or CONNECT which is weird. */
        return (pipe);
    }
}

# Define purging and banning rules
include "purging-banning.vcl";

# Appart from PURGE and BAN requests, we only handle GET and HEAD requests
sub vcl_recv {
    if (req.request != "GET" && req.request != "HEAD") {
        /* We only deal with GET and HEAD by default */
        return (pass);
    }

    # Never cache monitor.php
    if (req.url ~ "^/monitor.php") {
         return (pass);
    }

    # in case of down backends serve content up to 30 minutes old
    if (req.backend.healthy) {
        set req.grace = 2m;
    } else {
        set req.grace = 30m;
    }
}

# Define purging and banning rules
include "recv-url-rules.vcl";

# If the URL's hasn't been caught by recv-url-rules.vcl, continue with common rules
sub vcl_recv {   
    # Don't cache AJAX requests
    if (req.http.X-Requested-With == "XMLHttpRequest") {
        return(pass);
    }
}

sub vcl_fetch {
    # Set default TTL of 20 minutes
    set beresp.ttl = 20m;

    # Keep objects in cache beyond their lifetime
    set beresp.grace = 0s; # for testing purposes

    # Don't cache if requested so by the server
    if (beresp.http.X-NoCache  == "no-cache" || beresp.http.cache-control ~ "private") {
        set beresp.ttl = 0s;
        set beresp.http.Cache-Control = "max-age = 0";
        return ( hit_for_pass );
    }

    # Pass (don't cache) big files (limit is just under 1MB)
    if ( beresp.http.Content-Length ~ "[0-9]{6,}" ) {
        set beresp.ttl = 0s;
        return ( hit_for_pass );
    }

    # Remember URL and HOST for the ban-lurker
    set beresp.http.x-url = req.url;
    set beresp.http.x-host = req.http.host;
}

sub vcl_deliver{
    # These were set for the ban-lurker, but don't have to be send to the client
    unset resp.http.x-url;
    unset resp.http.x-host;

    # Add a header to the request so that we can see wether or not the object came from cache
    if (obj.hits > 0) {
        set resp.http.X-Cache = "HIT";
    } else {
        set resp.http.X-Cache = "MISS";
    }
}

sub vcl_pipe {
    # http://www.varnish-cache.org/ticket/451
    # This forces every pipe request to be the first one.
    set bereq.http.connection = "close";
}

Лаковая документация

Документация о лаке гласит следующее:

Прежде чем Varnish запустит vcl_fetch, переменная beresp.ttl уже имеет значение. > Он будет использовать первое найденное значение среди:

Переменная s-maxage в заголовке ответа Cache-Control Переменная max-age в заголовке ответа Cache-Control Заголовок ответа Expires Параметр default_ttl.

Так возможно ли, что TTL все еще перезаписывается в некоторых случаях ответом сервера? Даже если я заставлю его в vcl_fetch?

Answer 1

Запрет будет сохраняться в списке запретов до тех пор, пока все объекты в кеше старше, чем он был проверен. Если вы обслуживаете длиннохвостый контент с длинными TTL, банлист будет очень длинным.

Тем не менее, поскольку запреты оцениваются только один раз для каждого объекта, в этом нет никаких недостатков (кроме эстетики). Не беспокойся об этом.