Re: Slice cache

2016-04-18 Пенетрантность Maxim Dounin 
Hello!

On Mon, Apr 18, 2016 at 04:37:52PM -0400, S.A.N wrote:

> Я хотел бы узнать, Nginx умеет отдавать клиентам из своего кеша, ответы
> частями?

Да.

> Корректный заголовок Range: bytes... клиент отправляет, но Nginx из кеша
> отдает весь ответ статус - 200, вместо частичного ответа со статусом 206.

По умолчанию range-запросы из кеша работают только в том случае, 
если в ответе бекенда был заголовок Accept-Ranges и должна быть 
явно указана длина ответа.

Если заголовка Accept-Ranges нет - можно форсировать поддержку 
range-запросов с помощью директивы proxy_force_ranges 
(http://nginx.org/r/proxy_force_ranges/ru), но лучше его просто 
добавить в ответ бекенда.

-- 
Maxim Dounin
http://nginx.org/

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

Slice cache

2016-04-18 Пенетрантность S.A.N 
Здравствуйте.

Я хотел бы узнать, Nginx умеет отдавать клиентам из своего кеша, ответы
частями?
Корректный заголовок Range: bytes... клиент отправляет, но Nginx из кеша
отдает весь ответ статус - 200, вместо частичного ответа со статусом 206.

По сути нужен функционал обратный модулю Slice.

Наш use case:
Бекенд отдает, большой ресурсоемкий ответ (аналитик отчет - это результат
многих сложных SQL) разным клиентам в разное время нужны только части этого
отчета и иногда весь целиком. Модуль Slice только усложнит ситуацию, потому
что он сгенерирует много подзапросов на бекенд, вот именно этого и нужно
избежать, чтобы бекенд не генерировал куски отчета много раз, а один раз
сделал полный отчет и отдал в кеш Nginx.

Надеюсь это можно сделать.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,266232,266232#msg-266232

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

Re: Инвалидация кэша

2016-04-18 Пенетрантность vitcool 
Спасибо за ответы, буду разбираться

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,266217,266229#msg-266229

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

Re: nginx reload & restart

2016-04-18 Пенетрантность Maxim Dounin 
Hello!

On Mon, Apr 18, 2016 at 06:50:27PM +0300, Анатолий Коростелев wrote:

> Здравствуйте!
> 
> Подскажите, пожалуйста, есть ли список параметров в конфигурационном файле
> nginx, при изменении/добавлении/удаления которых достаточно и беспроблемно
> использовать nginx reload, а не nginx restart/upgrade? В моей конфигурации
> на множество серверов прилетают обновления конфигурационных файлов nginx и
> хотелось бы минимизировать использовать restart/upgrade.

Проблемы с reload'ом могут быть в случаях, когда затрагиваются 
параметры, разделяемые между многими процессами.  В частности:

- При изменениях зон разделяемой памяти - нельзя менять размеры 
  существующих зон и/или их использование (скажем, в limit_req 
  нельзя поменять одну переменную на другую).  При этом можно 
  создать новую зону с произвольными параметрами - при этом в старых 
  рабочих процессах останется старая зона, а в новых - будет 
  использоваться уже новая.

- На Linux'е могут быть проблемы с изменением слушающих сокетов, 
  т.к. скажем слушать на *:80 и 127.0.0.1:80 одновременно Linux не 
  разрешает.  Соответственно, при замене в конфигах одного на 
  другое reload будет невозможен, т.к. Linux не разрешит сделать 
  bind() для сокета из новой конфигурации

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

> В основном, мой вопрос касается в случае обновления файлов ssl-сертификата и
> ключа, достаточно будет в этом случае reload или будут подводные камни?

Каких-либо специфических проблем при обновлении сертификатов - 
быть не должно.  Однако в любом случае могут возникнуть 
непредвиденные проблемы - e.g., может банально кончится память.  
Т.е. в любом случае - стоит смотреть в логи.  Использовать 
restart/upgrade для обновления сертификатов - однозначно не надо.

-- 
Maxim Dounin
http://nginx.org/

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

Re: nginx reload & restart

2016-04-18 Пенетрантность Иван 
В письме от 18 апреля 2016 18:50:27 пользователь Анатолий Коростелев 
написал:
> Здравствуйте!
> 
> Подскажите, пожалуйста, есть ли список параметров в конфигурационном
> файле nginx, при изменении/добавлении/удаления которых достаточно и
> беспроблемно использовать nginx reload, а не nginx restart/upgrade? В
> моей конфигурации на множество серверов прилетают обновления
> конфигурационных файлов nginx и хотелось бы минимизировать 
использовать
> restart/upgrade.
> 
> В основном, мой вопрос касается в случае обновления файлов
> ssl-сертификата и ключа, достаточно будет в этом случае reload или будут
> подводные камни?
> 
> P.S. Версия nginx/1.9.13

Здравствуйте!

> SIGHUP   Reload configuration, start the new worker process with a
> new configuration, and gracefully shut down old worker pro‐> 
>   cesses.

Так что можете использовать reload при любом обновлении конфигурации. 
Касательно обновления сертификатов у меня по крону обновляются 
сертификаты от letsencrypt с дальнейшим nginx reload. Подводных камней не 
заметил.

Только не забывайте проверять файлы конфигурации на ошибки. nginx, 
получивший SIGHUP промолчит при ошибках в конфиге. Поэтому перед этим 
надо делать nginx -t.

С уважением, Иван.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Инвалидация кэша

2016-04-18 Пенетрантность Валентин Бартенев 
On Monday 18 April 2016 11:56:33 vitcool wrote:
> я считал что proxy_cache_bypass не приводит к инвалидации кэша, а просто
> отправляет запрос к бекенду напрямую
> 
[..]

Но соответствующая запись кэша может быть при этом обновлена.

--
Валентин Бартенев
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Инвалидация кэша

2016-04-18 Пенетрантность vitcool 
я считал что proxy_cache_bypass не приводит к инвалидации кэша, а просто
отправляет запрос к бекенду напрямую

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,266217,266223#msg-266223

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

nginx reload & restart

2016-04-18 Пенетрантность Анатолий Коростелев 

Здравствуйте!

Подскажите, пожалуйста, есть ли список параметров в конфигурационном 
файле nginx, при изменении/добавлении/удаления которых достаточно и 
беспроблемно использовать nginx reload, а не nginx restart/upgrade? В 
моей конфигурации на множество серверов прилетают обновления 
конфигурационных файлов nginx и хотелось бы минимизировать использовать 
restart/upgrade.


В основном, мой вопрос касается в случае обновления файлов 
ssl-сертификата и ключа, достаточно будет в этом случае reload или будут 
подводные камни?


P.S. Версия nginx/1.9.13

--
С уважением,
Коростелев Анатолий

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

Re: Инвалидация кэша

2016-04-18 Пенетрантность Валентин Бартенев 
On Monday 18 April 2016 06:50:51 vitcool wrote:
> Добрый день!
> 
> Правильно ли я понимаю, что инвалидировать кэш заголовком в запросе можно
> только в "платной" версии nginx?
> 

Если речь идет про директиву "proxy_cache_purge" )и подобные в scgi, fastcgi,
uwsgi модулях), то правильно.

http://nginx.org/r/proxy_cache_purge/ru

Если про "proxy_cache_bypass", то она доступна бесплатно.

http://nginx.org/r/proxy_cache_bypass/ru

--
Валентин Бартенев
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Инвалидация кэша

2016-04-18 Пенетрантность vitcool 
Добрый день!

Правильно ли я понимаю, что инвалидировать кэш заголовком в запросе можно
только в "платной" версии nginx?

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,266217,266217#msg-266217

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

Re: Redirect в случае если файл присутствует

2016-04-18 Пенетрантность siroco 
Спасибо!

Сделал так, все работает как надо:

  location /some-location {

# where we store sha256 sums
root /var/www/sha256sums;

# we are checking files plus ".sha256" extentions
set $filetocheck $uri.sha256;

set $cdn_server_name   our-cdn.domain.com;

if (!-f $document_root$filetocheck) { return 404; break; }

return  302 http://$cdn_server_name$request_uri;

}

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,266212,266215#msg-266215

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

Re: Redirect в случае если файл присутствует

2016-04-18 Пенетрантность Илья Шипицин 
если файлы уникальные, то может быть вам подойдет
http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_store

18 апреля 2016 г., 14:09 пользователь siroco 
написал:

> Привет!
>
> Хочется сделать такую вещь - проверять наличие файла (это файл с
> контрольной
> суммой, например, "/myfile.txt.sha256") и в случае наличия файла делать
> редирект на CDN на "/myfile.txt". А в случае отсутствия файла - просто
> выдавать 404.
>
> Поскольку "if"(ы) это плохо, то напрашивается решение с try_files.
>
> Однако вот такой вот конфиг редиректит на CDN только в случае отсутствия
> файла с контрольной суммой:
>
> # if file with checksum exists then redirect to CDN
> location / {
> root /var/www/myfiles;
> try_files $uri.sha256 @redirect_to_cdn;
> }
>
> location @redirect_to_cdn {
> return 302 http://mycdn.domain.com$request_uri;
> }
>
>
> Возможно ли как-то инвертировать условие try_files?
>
> --
> S.
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,266212,266212#msg-266212
>
> ___
> 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

Re: Redirect в случае если файл присутствует

2016-04-18 Пенетрантность Igor Sysoev 
On 18 Apr 2016, at 12:09, siroco  wrote:

> Привет!
> 
> Хочется сделать такую вещь - проверять наличие файла (это файл с контрольной
> суммой, например, "/myfile.txt.sha256") и в случае наличия файла делать
> редирект на CDN на "/myfile.txt". А в случае отсутствия файла - просто
> выдавать 404.
> 
> Поскольку "if"(ы) это плохо, то напрашивается решение с try_files.
> 
> Однако вот такой вот конфиг редиректит на CDN только в случае отсутствия
> файла с контрольной суммой:
> 
># if file with checksum exists then redirect to CDN
>location / {
>root /var/www/myfiles;
>try_files $uri.sha256 @redirect_to_cdn;
>}
> 
>location @redirect_to_cdn {
>return 302 http://mycdn.domain.com$request_uri;
>}
> 
> 
> Возможно ли как-то инвертировать условие try_files?

if это, конечно, плохо, но в сочетании с return не имеет побочных эффектов.
Можно использовать.


-- 
Igor Sysoev
http://nginx.com

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

Redirect в случае если файл присутствует

2016-04-18 Пенетрантность siroco 
Привет!

Хочется сделать такую вещь - проверять наличие файла (это файл с контрольной
суммой, например, "/myfile.txt.sha256") и в случае наличия файла делать
редирект на CDN на "/myfile.txt". А в случае отсутствия файла - просто
выдавать 404.

Поскольку "if"(ы) это плохо, то напрашивается решение с try_files.

Однако вот такой вот конфиг редиректит на CDN только в случае отсутствия
файла с контрольной суммой:

# if file with checksum exists then redirect to CDN
location / {
root /var/www/myfiles;
try_files $uri.sha256 @redirect_to_cdn;
}

location @redirect_to_cdn {
return 302 http://mycdn.domain.com$request_uri;
}


Возможно ли как-то инвертировать условие try_files?

--
S.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,266212,266212#msg-266212

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