Поведение лака на MISS

Question

Рассмотрите этот сценарий: Кэш Varnish имеет MISS, а сервер backend теперь регенерирует запрошенный контент. Во время генерации приходит второй запрос, а также получает MISS. Лак посылает этот запрос на бэкэнд, пока другой запрос находится на рассмотрении? Что, если между этим временем возникнет тысяча запросов. Сервер сработает правильно? Каждый запрос сделает его медленнее.

Правильно это или является лаком «синхронизация» этих сценариев, чтобы предотвратить такую ​​проблему?

Спасибо заранее!

Answer 1

Лак посылает все запросы на сервер. То есть он не ставит в очередь другие запросы и выдаёт только один запрос на бэкэнд и использует свой ответ для всех.

Однако у Varnish есть grace option, который позволяет хранить старый, истекший контент в кеше для этих типов ситуаций.

Для примера рассмотрим следующую VCL:

sub vcl_recv { 
    if (req.backend.healthy) { 
    set req.grace = 5m; 
    } else { 
    set req.grace = 24h; 
    } 
} 

sub vcl_fetch { 
    set beresp.grace = 24h; 
} 

Теперь, если бэкенд здоров (см backend polling) и запрос приводит к MISS, первый запрос отправляется бекенд. Если другой запрос поступает для одного и того же контента, но в кеше есть элемент с возрастом < TTL + req.grace (в этом случае 5 минут), этот запрос получит вместо этого «устаревшее» содержимое. Это происходит до тех пор, пока либо первый запрос, который привел к MISS, получает ответ от бэкэнд (а кеш снова свежий), или возраст элемента становится больше, чем TTL + req.grace.

Если бэкэнд был опущен (req.backend.healthy == FALSE), то устаревшее содержимое будет обслуживаться до тех пор, пока возраст < TTL + 24h.

Вы также можете ознакомиться с разделом Saving a requestVarnish book для более подробного примера и упражнения.

Исправлено: unescaped < персонаж.

Fixed больше: Был еще один неэкранированный < характер ...

Answer 2

Я считаю (принято) ответ Ketola ошибочна.

Несколько запросов на лак для того же URI будет быть поставлен в очередь.

Тогда это зависит от того, будет ли результат первого запроса кэшироваться или нет. Если это так, он будет использоваться и для других (в очереди) запросов. Если нет, все остальные запросы в очереди будут отправлены на сервер.

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

Answer 3

У меня нет комментариев или нет комментариев для ответа @ max_i, поэтому я отправляю другой ответ, чтобы проверить его.

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

Varnish отправляет все запросы на сервер. То есть он не ставит в очередь другие запросы и выдаёт только один запрос на бэкэнд и использует свой ответ для всех.

После независимо тестирования это сам, используя стандартную установку Varnish 4.1 LTS и Apache 2.4, я создал основной PHP файл, который содержал следующее:

<?php sleep(5); echo 'hello world!'; 

Затем используется ab для проверки цикла запроса HTTP используя 50 запросов при 5 параллелизмах. Результаты показали, что, хотя Ларниш принимал каждое соединение, только один запрос был когда-либо сделан на бэкэнд, который, как и ожидалось, занял примерно 5 секунд для разрешения. Каждое соединение лака впоследствии должно было дождаться этого минимального периода до получения ответа.

Недостатком этого является, конечно, то, что запросы после первого «поставлены в очередь» позади него, но это, конечно, незначительная проблема по сравнению со всеми 50 запросами, которые сразу попадают в бэкэнд (или в случае моего теста , с параллелизмом 5).