Re: proxy_cache_purge

2018-08-01 Thread Yury Lyakh 
Звучит как-то необычно, есть пример рабочего конфига? хотя бы этого самого 
специального локейшна?…
что-то не придумывается конфиг который позволит внутри nginx принудительно 
обновить элемент в кеше

> On 31 Jul 2018, at 13:54, Igor A. Ippolitov  wrote:
> 
> On 31.07.2018 00:24, j...@jdwuzhere.ru  wrote:
>> 
>>> On 30 Jul 2018, at 19:59, Igor A. Ippolitov  wrote:
>>> 
 On 30.07.2018 14:29, Gena Makhomed wrote:
> On 30.07.2018 14:06, Igor A. Ippolitov wrote:
> 
> Мне кажется, что proxy_cache_bypass легко позволяет замещать контент в 
> кэше (что и делает purge, в широком смысле).
 Замещать существующий контент или добавлять новый - да.
 Но удалять не позволяет, в этом и состоит (небольшое) отличие.
>>> Но ведь какой-то ответ на запрос "пурженного" контента всё равно придёт 
>>> клиенту? Почему бы не закэшить сразу его.
>>> Или условную болванку с max-age:0, которая будет обновлена по первому же 
>>> запросу от клиента
>> Погодите, я что-то потерялся. Есть профиль игрока, который не меняется 
>> неделями. Nginx всю неделю (TTL кэша) радостно отдаёт страницу профиля из 
>> этого кэша. Но однажды, игрок начинает играть в новое и профиль необходимо 
>> обновить. Как без purge сообщить nginx, что информация обновилась и надо 
>> сходить в backend за новой страницей, чтобы положить её в кэш до следующего 
>> прихода?
> Как бы вы делали PURGE для профиля игрока? URL профиля вы знаете.
> 
> Для PURGE вы бы "дёрнули" запрос, который удалит ненужный элемент и в 
> следующий раз nginx перезапросит контент с апстрима.
> Этот запрос, обычно, приходит в отдельный location с нужными настройками: 
> ключ кэша, права доступа, всякое такое.
> 
> В моём подходе вы "дёргаете" такой же запрос в специальный location, который 
> ходит в апстрим мимо кэша (proxy_cache_bypass).
> В разных вариациях, апстримом будет:
> либо сам nginx, который отдаёт HTTP 200 и Cache-Control: max-age=0;
> либо реальный апстрим, который отдаст актуальную копию данных
> 
> В первом случае контент сразу "протухает" и его актуализируют на первом же 
> запросе.
> Во-втором - сразу актуальный.
> 
> В следущий раз, когда запросят профиль пользователя, nginx либо пойдёт в 
> апстрим, либо отдаст актуальную кэшированную версию.
> 
>> 
>>> На первый взгляд, PURGE не кажется необходимым средством. Хотя, вероятно. 
>>> может упростить жизнь в каких-то конфигурациях.
 Вот поэтому и не понятно, почему нельзя сделать директиву
 proxy_cache_purge доступной в open source версии nginx?
 
 Могу ошибаться, но коммерческую версию nginx покупают скорее всего
 не из-за директивы proxy_cache_purge, а ради других возможностей.
 
>>> Если не прояснится - попробовать воспроизвести как минимум без
>>> "--add-module=../ngx_cache_purge-2.3" (не понимаю, как люди
>>> отваживаются использовать эту поделку, она при любых внутренних
>>> изменениях в nginx'е разносит всё же)
>> Если не использовать этот кривой сторонний модуль ngx_cache_purge,
>> то какие у пользователей open source версии nginx есть альтернативы?
>> Директиву proxy_cache_purge
>> можете сделать доступной в open source версии nginx?
 P.S.
 
 Please do not top-post.
 
 Answer: Because it turns the discussion up-side-down.
 
 Question: Why should I not top-post?
 
>>> ___
>>> nginx-ru mailing list
>>> nginx-ru@nginx.org
>>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>> ___
>> nginx-ru mailing list
>> nginx-ru@nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
> 
> 
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org 
> http://mailman.nginx.org/mailman/listinfo/nginx-ru 
> 
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

max_fails=0 и no live upstreams while connecting to upstream

2018-04-11 Thread Yury Lyakh 
Господа, подскажите пожалуйста,

В документации сказано что max_fais=0 отключает попадание апстрима в блэклист 
на время из-за проблем с ним.

То есть, как я понимаю постучались на бэкенд, получили 502 или еще что, отдали 
клиенту. И дальше стучимся на бэкенд, а не замораживаем его с сообщением в лог 
"no live upstreams while connecting to upstream".


upstream games-storage-ru {
  zone games-storage-ru 64k;
  server games.syd.origin.ru  max_fails=0;
  keepalive 4;
}


"46.116.106.159" "-" "-" "[11/Apr/2018:16:37:29 +]" "HEAD /Logo.png 
HTTP/1.1" "502" "0" "-" "curl/7.54.0" "169" "-" "http" "games-storage.ru 
" "0.000" "0.000" "99" "-" "[fr5]" "MISS" "0" 
"games-storage-ru" "2052" "4468" "-" "-"

2018/04/11 16:37:29 [error] 34796#34796: *672751767 no live upstreams while 
connecting to upstream, client: 46.116.106.159, server: games-storage.ru 
, request: "HEAD /Logo.png HTTP/1.1", upstream: 
"http://games-storage-ru/Logo.png ", host: 
"games-storage.ru "

Или я что-то упустил?
Или при max_fails=0 это сообщение чисто информационное и данный server в 
апстрим не блэклистится на самом деле?___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: GET запрос, 200 код и body_bytes_sent==0 при непустом объекте выдачи, как?

2018-02-26 Thread Yury Lyakh 
забыл добавить главное, версия nginx самая распоследняя 1.13.9

> On 26 Feb 2018, at 16:46, Yury Lyakh <yor...@ya.ru> wrote:
> 
> 
> День добрый всем,
> 
> не подскажет ли сообщество, в каких случаях nginx может писать в лог GET с 
> таким раскладом:
> $response_code == 200
> $body_bytes_sent == 0
> $bytes_sent != 0
> 
> выдача из кеша (впрочем такая же картина и при MISS с хождением в бэкенд, 
> есть ощущение что это связано с поведением пользователя в первую очередь):
> 
> "83.6.141.89" "-" "-" "[15/Feb/2018:14:37:24 +]" "GET 
> /hls-vod/mjxCYlUG8gQh4WApAv94JA/1518726762/120/0x53970b782deb/e58180d4dc134dd8a440d56214dbf890.mp4Frag6Num5.ts
>  HTTP/2.0" "200" "0" "https://rube.ru/play/embed/10936010 
> <http://rube.ru/play/embed/10936010>" "Mozilla/5.0 (iPhone; CPU iPhone OS 
> 11_2_2 like Mac OS X) AppleWebKit/604.4.7 (KHTML, like Gecko) Version/11.0 
> Mobile/15C202 Safari/604.1" "257" "-" "https" "c.rube.ru <http://c.rube.ru/>" 
> "60.000" "-" "95" "-" "HIT" "-" "-" "645" "2038"
> 
> "85.172.79.11" "-" "-" "[26/Feb/2018:15:01:22 +]" "GET 
> /hls-vod/idSHrOHQR97_xWvsyJve1g/1519677788/119/0x53970b8815d3/cead5d5a8e6a4e0bb99c5ea4244bc4b6.mp4Frag158Num158.ts
>  HTTP/2.0" "200" "0" 
> "https://rube.ru/play/embed/10878914?wmode=opaque=1=1 
> <https://rube.ru/play/embed/10878914?wmode=opaque=1=1>"
>  "Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like 
> Gecko) Chrome/64.0.3282.167 Safari/537.36" "235" "-" "https" "c.rube.ru 
> <http://c.rube.ru/>" "19.907" "-" "98" "-" "HIT" "-" "-" "645" "2038"
> 
> здесь построчно соответственно поля равны:
> 200, 0, 257
> 200, 0, 235
> 
> То есть соединение корректно закрылось сразу после получения заголовков, от 
> body клиент отмахался, не стал принимать?
> Если бы был HEAD запрос я бы еще понял что происходит, но тут GET.
> 
> Сами объекты не пустые, то есть в логе присутствует их выдача ненулевого 
> body, да и в кеше посмотрел, вполне себе нормальные файлы.
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

GET запрос, 200 код и body_bytes_sent==0 при непустом объекте выдачи, как?

2018-02-26 Thread Yury Lyakh 

День добрый всем,

не подскажет ли сообщество, в каких случаях nginx может писать в лог GET с 
таким раскладом:
$response_code == 200
$body_bytes_sent == 0
$bytes_sent != 0

выдача из кеша (впрочем такая же картина и при MISS с хождением в бэкенд, есть 
ощущение что это связано с поведением пользователя в первую очередь):

"83.6.141.89" "-" "-" "[15/Feb/2018:14:37:24 +]" "GET 
/hls-vod/mjxCYlUG8gQh4WApAv94JA/1518726762/120/0x53970b782deb/e58180d4dc134dd8a440d56214dbf890.mp4Frag6Num5.ts
 HTTP/2.0" "200" "0" "https://rube.ru/play/embed/10936010 
" "Mozilla/5.0 (iPhone; CPU iPhone OS 
11_2_2 like Mac OS X) AppleWebKit/604.4.7 (KHTML, like Gecko) Version/11.0 
Mobile/15C202 Safari/604.1" "257" "-" "https" "c.rube.ru " 
"60.000" "-" "95" "-" "HIT" "-" "-" "645" "2038"

"85.172.79.11" "-" "-" "[26/Feb/2018:15:01:22 +]" "GET 
/hls-vod/idSHrOHQR97_xWvsyJve1g/1519677788/119/0x53970b8815d3/cead5d5a8e6a4e0bb99c5ea4244bc4b6.mp4Frag158Num158.ts
 HTTP/2.0" "200" "0" 
"https://rube.ru/play/embed/10878914?wmode=opaque=1=1 
" 
"Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like 
Gecko) Chrome/64.0.3282.167 Safari/537.36" "235" "-" "https" "c.rube.ru 
" "19.907" "-" "98" "-" "HIT" "-" "-" "645" "2038"

здесь построчно соответственно поля равны:
200, 0, 257
200, 0, 235

То есть соединение корректно закрылось сразу после получения заголовков, от 
body клиент отмахался, не стал принимать?
Если бы был HEAD запрос я бы еще понял что происходит, но тут GET.

Сами объекты не пустые, то есть в логе присутствует их выдача ненулевого body, 
да и в кеше посмотрел, вполне себе нормальные файлы.___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

ограничение размера ответа с бэкенда по Content-Length в ответе

2017-08-09 Thread Yury Lyakh 
День добрый,

Хочется странного, ограничить размер ответа от бэкенда.

Например, по заголовку Content-Length в ответе
1) пропускать ответы не более заданного размера (допустим 10M)
2) eсли заголовка в ответе нет или размер превышает заданный - дропать 
обработку запроса.

Необходимо для борьбы с бесконечными видео ответами (заголовка нет, размер не 
известен, качаем гигабайты).

Просмотрел документацию, похоже ничего подобного нет.

Или пропустил? Может кто-то рассматривал подобную задачу?
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

nginx качает один и тот же файл в несколько коннектов с бэкенда

2017-06-06 Thread Yury Lyakh 
День добрый, может кто сталкивался с проблемой закачки файлов с бэкенда 
параллельно в несколько потоков.

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

применили:
proxy_cache_lock on;
и
proxy_cache_use_stale updating;
но ситуация не изменилась, все равно качается в множество нитей

Почистили полностью машину от временных файлов (temp файлы закачки находятся в 
кеше use_temp_path=off).
Запустили трафик, буквально через 10 секунд прошелся по кешу в поиске временных 
файлов, чтобы посмотреть их KEY в заголовке, видим что одновременно создались и 
качаются 177 временных файлов для одного по сути файла:

[root@upload-3 cache]# find -L ./ -type f -iname '*\.[0-9]*' | xargs head -n2 | 
grep -a ^KEY | sort | uniq -c
177 KEY: /ct/patches/wop_1.9.77.310044_ct/wop.ct_1.9.77.310044.pkg.001

самы файлы выглядят как:
...
-rw--- 1 nginx nginx  205168640 Jun  6 13:15 
./wop/1f/51/006afe023b4083e96128680af13b511f.000253
-rw--- 1 nginx nginx  209281024 Jun  6 13:15 
./wop/1f/51/006afe023b4083e96128680af13b511f.000254
-rw--- 1 nginx nginx  286048256 Jun  6 13:15 
./wop/1f/51/006afe023b4083e96128680af13b511f.000255
-rw--- 1 nginx nginx  671723520 Jun  6 13:15 
./wop/1f/51/006afe023b4083e96128680af13b511f.000257
-rw--- 1 nginx nginx  217743360 Jun  6 13:15 
./wop/1f/51/006afe023b4083e96128680af13b511f.000258
-rw--- 1 nginx nginx  239915008 Jun  6 13:15 
./wop/1f/51/006afe023b4083e96128680af13b511f.000259
-rw--- 1 nginx nginx  635768832 Jun  6 13:15 
./wop/1f/51/006afe023b4083e96128680af13b511f.000261



версия nginx-1.13.1

конфиг:
proxy_cache_path /var/lib/nginx/cache/wop  levels=2:2 keys_zone=wop:20m 
inactive=2d use_temp_path=off;

server {
listen 80;
listen [::]:80;
server_name dl-share.wop.net ;

proxy_cache wop;
proxy_ignore_client_abort on;

location / {
proxy_pass http://dl.wop.net ;
proxy_set_header Host   $proxy_host;
proxy_cache_lock on;
proxy_cache_lock_age 1d;
proxy_cache_lock_timeout 1d;
proxy_cache_use_stale error updating;
proxy_cache_key "$uri";
proxy_cache_revalidate on;
proxy_cache_valid 404 10s;
proxy_cache_valid 200 1h;
}
}

запросы с которыми идут пользователи:

"195.242.151.17" "-" "-" "[06/Jun/2017:13:03:28 +]" "GET 
/ct/patches/wop_1.9.77.310044_ct/wop.ct_1.9.77.310044.pkg.001 HTTP/1.1" "206" 
"0" "-" "wdsa::Torrents/1.1 libtorrent/1.1.3.0" "0" "-" "http" 
"dl-share.wop.net " "81.114" "81.114" "235" 
"bytes=1744977920-1745043455" "[gn]" "MISS" "42008576" "91.213.124.60:80" "0" 
"0" "-" "-"
"195.242.151.17" "-" "-" "[06/Jun/2017:13:03:26 +]" "GET 
/ct/patches/wop_1.9.77.310044_ct/wop.ct_1.9.77.310044.pkg.001 HTTP/1.1" "206" 
"0" "-" "wdsa::Torrents/1.1 libtorrent/1.1.3.0" "0" "-" "http" 
"dl-share.wop.net " "121.167" "121.167" "235" 
"bytes=2059403264-2059468799" "[gn]" "MISS" "42008576" "91.213.124.60:80" "0" 
"0" "-" "-"

Ткните пожалуйста в документацию где я не дочитал, что вообще происходит?..
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

nginx cache manager process не соблюдает max_size размера кеша

2017-05-11 Thread Yury Lyakh 

День добрый,

Возможно кто-то сталкивался с подобной ситуацией и подскажет что я пропустил...

Разбираясь с мониторингом вокруг nginx, столкнулись с тем что manager процесс, 
который должен вычищать кеши до размера max_size, не делает этого. Не соблюдает 
строго max_size размер.

CentOS 7, ext4, ssd, nginx-1.11.7 (раннее 1.11.4). Система не нагружена никак, 
диск ssd отдыхает, CPU около 80% *IDLE*, идет поток мелких запросов суммарно до 
300-400 мбайт/сек.

Описание кеша следующее:
proxy_cache_path /var/lib/nginx/cache/cdn-example-com levels=2:2 
keys_zone=cdn-example-com:50m inactive=8h max_size=100g manager_files=1;

[root@dc227 ~]# du -sh -L /var/lib/nginx/cache/cdn-example-com/
142G/var/lib/nginx/cache/cdn-example-com/
[root@dc227 ~]# find /var/lib/nginx/cache/cdn-example-com/*/ -type f | wc -l
145553

И размер кеша и кол-во файлов потихоньку растут или колеблются вокруг этих 
показаний, сложно сказать, очень медленная динамика. Одно ясно точно, 
фактический размер кеша превышает заданный max_size.

Стрейсом по manager процессу, видно что он неторопливо делает unlink, очень 
неторопливо и от цифры в manager_files это никак не меняется.

Изначально, пытаясь решить эту ситуацию, грешили на то что manager_files по 
умолчанию =100, но, и 1000, и 1 никак не влияют на скорость.
Что приходит в голову, видимо manager процесс вычищает ровно столько сколько 
необходимо и все прекрасно успевает при любых значениях manager_files. Просто 
остальные файлы, по каким-то причинам, он считает недостойными очистки во имя 
сохранение max_size кеша.

Какие-то параметры в описании proxy_cache_path имеют приоритет на max_size при 
принятии решения чистить файл или нет?
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru