Пытаюсь расшифровать этот блок лака vcl (относящийся к изяществу)

Итак, в моем vcl_recv у меня установлен этот заголовок

set req.http.Grace = "NONE";

и когда бэкэнд работает, все имеет установленный заголовок Grace: NONE, что здорово... и тогда у нас есть

sub vcl_hit {

    # Called when a cache lookup is successful.
      if (obj.ttl >= 0s) {
        # A pure unadultered hit, deliver it
        return (deliver);
      }

     if (std.healthy(req.backend_hint)) {
        # Backend is healthy. Limit age to 10s.
            if (obj.ttl + 10s > 0s) {
                set req.http.Grace = "normal(limited)";
                return (deliver);
                            } else {
                            # No candidate for grace. Fetch a fresh object.
                            return(fetch);
                            }
      } else {
        # backend is sick - use full grace
            if (obj.ttl + obj.grace > 0s) {
                set req.http.Grace = "full";
                            return (deliver);
                            } else {
                            # no graced object.
                            return (fetch);
        }
      }

      # fetch & deliver once we get the result
      return (fetch); # Dead code, keep as a safeguard

    }

Итак, я понимаю, что, по-видимому, полная льгота наступает, когда серверная часть не работает, и я понимаю, что если серверная часть не работает, мы не настраиваем льготу, но когда именно этот нормальный (ограниченный) блок сработает? Похоже, что когда бэкэнд работает, он обслуживает все с Grace: NONE, и если я останавливаю nginx, он переходит прямо к Grace: FULL. я просто не знаю когда

    if (obj.ttl + 10s > 0s) {
        set req.http.Grace = "normal(limited)";

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

Мой vcl_backend_response имеет эти значения (для тестирования, но да)

# A TTL of 24h
set beresp.ttl = 60s;
# Define the default grace period to serve cached content
set beresp.grace = 6h;

varnish varnish-vcl
person alturic    schedule 18.02.2015    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Рассматриваемый блок сработает для первого запроса объекта с истекшим сроком действия в течение 10 секунд после его истечения.

Например, вы запрашиваете объект в 00:00:00, он извлекается из серверной части и сохраняется с TTL 60 секунд. Если вы запросите тот же объект в 00:01:07, вы должны получить кешированный объект (срок действия которого уже истек) и увидеть заголовок «нормальный (ограниченный)».

Предполагая, что этот VCL работает на Varnish 4.x, обращение к объекту с истекшим сроком действия в отсрочке должно вызвать фоновое обновление, поэтому любые последующие запросы должны получать только что кэшированный объект.

В двух словах это правило гласит:

  1. Храните все предметы в течение 6 часов и 1 минуты.
  2. Подавать объекты моложе 60 секунд из кеша
  3. Подавать объекты возрастом от 60 до 70 секунд из кеша, но обновлять кешированный объект в фоновом режиме.
  4. Обслуживать объекты старше 70 секунд из кеша только в том случае, если внутренняя проверка работоспособности не удалась.

ОБНОВИТЬ:

Вы в значительной степени поняли это. Объекты хранятся — хранятся в памяти — на сумму TTL и отсрочки. Вот как мы получаем максимальную продолжительность хранения 6 часов и 1 минуту - 6 часов отсрочки и 1 минуту TTL.

TTL — это то, как долго вы считаете объект «свежим», что означает, что его можно обслуживать из кеша, не проверяя, мог ли он измениться на исходном сервере. Грейс, с другой стороны, срабатывает, когда объект уже не «свежий», но вы все равно хотите его обслужить — обычно по одной из двух причин:

  1. Ваш бэкенд дает сбой, и лучше обслуживать «устаревший» объект с истекшим сроком действия, чем обслуживать ошибку.

Например, подумайте о CMS, которая показывает статьи и комментарии. Обычно желательно, чтобы значение TTL было коротким, чтобы новые комментарии отображались своевременно. Однако, если ваша CMS выйдет из строя, вы предпочтете разместить статью со старыми комментариями, а не со страницей «Ой, сервер мертв».

  1. Срок действия объекта истек недавно, поэтому обслуживать объект с истекшим сроком действия не так уж сложно, и предпочтительнее обслуживать слегка устаревший объект немедленно, а не ждать, пока серверное приложение вернет ответ.

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

person lexnihilo    schedule 18.02.2015
comment
Если beresp.grace означает хранить объекты в течение 6 часов, почему ваш № 4 говорит, что обслуживать только объекты старше 70 секунд, если серверная часть не работает? Или beresp.grace вообще не используется, ЕСЛИ И ДО ТОГО, как серверная проверка не выйдет из строя? Ваш № 3 сбивает меня с толку, поскольку он противоречит вашему № 1. Я думаю, это может сбить меня с толку, потому что, когда я вижу сохранение, я думаю, что хранить до устаревания, а затем обновлять, когда я ДУМАЮ, что мне следует думать о сохранении до обновления, НА СЛУЧАЙ, если нам нужно обслуживать это устаревание из-за проблем с серверной частью, верно? - person alturic; 19.02.2015