Re: Модуль stream и использование map

[Roman Arutyunyan]

Добрый день,

On Tue, Mar 15, 2016 at 05:22:52PM +0200, Alex Domoradov wrote:
> Привет,
> 
> правильно ли я понимаю, что в модуле stream я не могу использовать
> переменную, которую я объявил через map в http секции?

В модуле stream на текущий момент переменные вообще не поддерживаются.

[..]

-- 
Roman Arutyunyan

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

Re: Модуль stream и использование map

[Alex Domoradov]

Неужели никто не сталкивался?

2016-03-15 17:22 GMT+02:00 Alex Domoradov :

> Привет,
>
> правильно ли я понимаю, что в модуле stream я не могу использовать
> переменную, которую я объявил через map в http секции?
>
> Суть вопроса. данный конфиг нормально работает с http/server
>
> http {
>map $remote_addr $backend {
>   default staging1;
>   192.168.1.127 staging2;
>}
> }
>
> upstream staging1 {
> server 127.0.0.1:8001;
> }
>
> upstream staging2 {
> server 127.0.0.1:8002;
> }
>
> server {
> listen 8000;
>
> location / {
> proxy_pass http://$backend;
> }
> }
>
> но не работает со stream
>
> stream {
>
> upstream staging1 {
> server 127.0.0.1:8001;
> }
>
> upstream staging2 {
> server 127.0.0.1:8002;
> }
>
> server {
> listen 8003;
> proxy_pass http://$backend;
> }
> }
>
> при проверке получаю
>
> # nginx -t
> nginx: [emerg] invalid host in upstream "http://$backend; in
> /etc/nginx/nginx.conf:24
> nginx: configuration file /etc/nginx/nginx.conf test failed
>
> 24 строка это директива proxy_pass. Можно ли как то в stream получить
> поведение, аналогичное первому варианту?
>
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Буферизация fastcgi в файл. Почему?

[Иван]

В письме от 16 марта 2016 02:11:21 пользователь Maxim Dounin написал:
> Hello!
> 
> On Wed, Mar 16, 2016 at 01:10:04AM +0300, Иван wrote:
> > Здравствуйте!
> > 
> > Много про это написано, но, к сожалению, не могу понять следующий момент:
> > В локейшене, которые обрабатывает php есть директива
> > 
> > fastcgi_buffers 32 4k;
> > 
> > Итого ответ до 128к на диск писаться не должен. Тогда как в эррор-логе
> > регулярно проскакивает запись
> > 
> > 2016/03/16 00:07:32 [warn] 6902#6902: *16095817 an upstream response is
> > buffered to a temporary file /var/lib/nginx/fastcgi/8/32/0002018328 while
> > reading upstream, client: 195.211.ХХ.ХХ, server: ХХХ, request: "GET
> > /admin/statistics/users/list/users HTTP/1.1", upstream:
> > "fastcgi://unix:/run/php-fpm.socket:", host: "ХХХ", referrer:
> > "https://ХХХ/admin/statistics/users/detail;
> > 
> > Максимальный размер ответа nginx по запросу
> > /admin/statistics/users/list/users за сегодня был 46968 , судя по
> > access_log. Как такое может быть? Что я не учитываю?
> Размер ответа в access_log - уже после gzip-сжатия, если оно
> включено.  Соответственно реальный размер ответа, возвращённого
> бекендом, может сильно отличаться в большую сторону.

Спасибо.

А есть возможность понять сколько реальный размер ответа? Мне немного претит 
тыкать размеры буфферов наобум.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Acept systemd.socket

[Evgeniy Berdnikov]

On Wed, Mar 16, 2016 at 08:36:50AM +0300, Vasiliy Tolstov wrote:
> 16 марта 2016 г. 2:35 пользователь "S.A.N" 
> написал:
> > Возможно вы правы, но мне как разработчику бекенда, приятней и понятней
> > настраивать директивы systemd.socket.
> >
> > Наши бекенд демоны запускает systemd.socket, он же и следит за ними на
> > протяжении их жизни.
> > Nginx по сути такой же демон, но стартуют при загрузки OS, я замерял время
> > когда доступный systemd.socket и когда Nginx, в результате Nginx готов к
> > принятию конектов на ~700 ms позже, по сравнению с systemd.socket.
> > Это не критично и OS перегружается редко, но зачем терять эти ~700 ms,
> > что-то настраивать в iptables можно, но зачем когда есть systemd.
> >
> > Nginx, станет только лучше если реализует прием сокета от systemd.socket.
> 
> Так а чем плох вариант, дропать при старте системы все,и сделать
> сервис,который после старта nginx откроет порты? Мне кажется это более
> универсальным вариантом.

 И более правильным, потому что независимо от чей-то любви к systemd.socket
 в данном случае он поставленную задачу НЕ решает. Всяко лучше устранить
 проблему полностью, чем уменьшить её вероятность на несколько процентов.
-- 
 Eugene Berdnikov

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