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

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

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

Заранее спасибо!

5
nl ja de

3 ответы

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

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

Например, рассмотрим следующий VCL:

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

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

Now if a backend is healthy (see backend polling) and a request results in a MISS, the first request is sent to a backend. If another request comes for the same content, but there is an item in the cache with age MISS gets a response from the backend (and the cache is fresh again) or the age of the item becomes greater than TTL+req.grace.

If the backend was down (req.backend.healthy == FALSE), stale content would be served as long as age

You might also want to check out the Saving a request section of the Varnish book for a more thorough example and an exercise.

Fixed: unescaped < character.

Fixed more: There was another unescaped < character...

2
добавлено
Я заметил, что в моем ответе у меня был непередаваемый символ. Исправлено. Раньше не было смысла. знак равно
добавлено автор Ketola, источник
Если вы хотите расширить свой вопрос, пожалуйста, рассмотрите либо редактирование исходного вопроса, либо публикацию нового. Если я правильно понял ваш комментарий, вы спрашиваете, что происходит в течение льготного периода. После истечения срока действия кэшированного объекта (возраст объекта больше, чем TTL) клиент # 1 получает свой запрос, отправленный на сервер, а клиент № 2-n получает кешированную версию. В приведенном выше примере Клиент №1 должен получить свой ответ в течение 5 минут. Если это займет больше времени, вам следует подумать о других способах ускорения ваших страниц.
добавлено автор Ketola, источник
Я считаю, что лак действительно будет стоять в очереди.
добавлено автор laughingbovine, источник
спасибо, я прочитаю больше о графике времени
добавлено автор Pluto1010, источник
Хм еще есть вопрос, что произойдет, если кеш пуст после отключения или краха. наши сайты сильно посещаются, что приводит к многочисленным запросам в секунду. Я думаю, что это может убить наших веб-серверов, если у лака есть пустой кеш. Вот почему я надеюсь, что лак позволит равным запросам ждать и выполнять только один раз. после этого остальные получат ответ от кеша. поэтому серверы будут делать запрос, например, домашнюю страницу только один раз. а не 1000 раз параллельно. любые идеи по этому вопросу?
добавлено автор Pluto1010, источник
Пока я читаю до сих пор, он будет доставлять старый контент в течение целого времени. тогда лак пытается обновить кэш с запросом, сделанным на бэкэнд. при обновлении кеша лак доставляет фактический контент для запроса по новым запросам. поэтому он не ставит их в очередь до тех пор, пока кеш не будет обновлен. после продолжительности жизни плюс время жизни объекта в прошлом лак ничего не доставит из кеша и пытается спросить бэкэнд. ваш бэкэнд должен действительно быть в состоянии доставить запрошенный контент в течение целого времени.
добавлено автор Pluto1010, источник
для лака обновления url не посылает несколько reqs параллельно с backend. что приведет к глупой нагрузке на веб-сервер и замедлит работу. если я ложный, пожалуйста, поправьте меня!
добавлено автор Pluto1010, источник

Я считаю, что ответ Кетолы (принятый) неверен.

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

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

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

0
добавлено

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

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

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

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

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

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

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

0
добавлено