Звучит как-то необычно, есть пример рабочего конфига? хотя бы этого самого
специального локейшна?…
что-то не придумывается конфиг который позволит внутри nginx принудительно
обновить элемент в кеше
> On 31 Jul 2018, at 13:54, Igor A. Ippolitov wrote:
>
> On 31.07.2018 00:24, j...@jdwuzhere.ru
Господа, подскажите пожалуйста,
В документации сказано что max_fais=0 отключает попадание апстрима в блэклист
на время из-за проблем с ним.
То есть, как я понимаю постучались на бэкенд, получили 502 или еще что, отдали
клиенту. И дальше стучимся на бэкенд, а не замораживаем его с сообщением в
забыл добавить главное, версия nginx самая распоследняя 1.13.9
> On 26 Feb 2018, at 16:46, Yury Lyakh <yor...@ya.ru> wrote:
>
>
> День добрый всем,
>
> не подскажет ли сообщество, в каких случаях nginx может писать в лог GET с
> таким раскладом:
> $response_code
День добрый всем,
не подскажет ли сообщество, в каких случаях nginx может писать в лог GET с
таким раскладом:
$response_code == 200
$body_bytes_sent == 0
$bytes_sent != 0
выдача из кеша (впрочем такая же картина и при MISS с хождением в бэкенд, есть
ощущение что это связано с поведением
День добрый,
Хочется странного, ограничить размер ответа от бэкенда.
Например, по заголовку Content-Length в ответе
1) пропускать ответы не более заданного размера (допустим 10M)
2) eсли заголовка в ответе нет или размер превышает заданный - дропать
обработку запроса.
Необходимо для борьбы с
День добрый, может кто сталкивался с проблемой закачки файлов с бэкенда
параллельно в несколько потоков.
Есть мелкий конфиг ниже.
Клиенты приходят с запросами ренжовыми и обычными, если файл отсутствует в кеше
он начинает качаться с бэкенда, но качается во столько нитей сколько клиентов
День добрый,
Возможно кто-то сталкивался с подобной ситуацией и подскажет что я пропустил...
Разбираясь с мониторингом вокруг nginx, столкнулись с тем что manager процесс,
который должен вычищать кеши до размера max_size, не делает этого. Не соблюдает
строго max_size размер.
CentOS 7, ext4,