Домены 3-го уровня - best practices

2019-05-24 Thread vitcool 
Добрый день.

Есть ли какие-либо примеры лучших практик на тему "как лучше организовать
обслуживание доменов 3-го уровня" при условии, что их количество будет не
более 20..30, максимум 40, включая основной www. ?

По факту все они должны вести на 1 апстрим, но в случае домена 3-го уровня,
нужно будет установить кастомный заголовок со значением равным этому домену
и подменить заголовок Host на основной. 

Доступ к коду бекенда есть, но весьма ограниченный. Эти 2 хидера бы спасли
ситуацию.

Что посоветуете? Пиковая нагрузка  порядка 50..75 RPS , ожидается рост до
100. С if-ми я так понимаю, нам не выжить.

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

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

Re: Влияние на производительность проверок на существоание файла (-f) в rewrite модуле

2019-05-24 Thread Dmitry Sergeev 
Спасибо за ответ. К сожалению на выкатку без простоя я повлиять не могу. 
Флаг тех. работ во время деплоя всех устраивает, а вот поддержка в коде 
двух структур данных в бд (до миграции и после) не очень устраивает. 
Поэтому так живем.


Также в редких случаях, при авариях, требуется закрывать сервис на тех. 
работы.
В целом, много вызовов stat не очень страшно, но только ради редких тех. 
работ так делать все таки не буду.


Еще раз спасибо.

On 23/05/2019 17:43, Maxim Dounin wrote:

Hello!

On Thu, May 23, 2019 at 03:10:28PM +0500, Dmitry Sergeev wrote:


При такой конфигурации на каждый запрос[*] будет делаться
системный вызов stat().  Скорее всего необходимые данные будут в
кэше операционной системы, и этот системный вызов будет быстрым,
так что на производительности это скажется минимально.

Так что если речь не идёт о борьбе за каждый процент - про
производительность подобной конструкции можно не переживать.
Другой вопрос, что сама по себе конструкция не очень, выкатку
нужно уметь делать без перерывов в обслуживании.

[*] Вообще-то в можно ещё и настроить кэширование внутри nginx'а,
чтобы сэкономить системные вызовы (http://nginx.org/r/open_file_cache).
Но практика показывает, что на производительность это влияет
минимально, а вот выстрелить себе в ногу неатомарным изменением
файлов станет легко.


--
Kind regards
Dmitry Sergeev
Tel: +7 (951) 129-75-72

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

Re: proxy_pass to variable and upstream server temporarily disabled variable

2019-05-24 Thread Sergey Kandaurov 

> On 24 May 2019, at 16:19, kron  wrote:
> 
> Доброго дня!
> 
> nginx: 1.15.8
> 
> Конфигурация простая (конечно она сильно шире, но в качестве бэкенда сейчас
> действительно один сервер задается через переменную):
> 
> split_clients "${remote_addr}${cookie_uid}" $backend {
>  * "backend1.eu-central-1.elb.amazonaws.com";
> }
> 
> 
> server {
>  listen 80;
> 
>  location / {
>   proxy_pass http://$backend;
>  }
> }
> 
> Столкнулся с интересной проблемой. В один момент у меня перестали идти
> запросы на бэкенд, но быстро запросы восстановились. Поискал в логах, в
> итоге нашел такие ошибки:
> 
> 2019/05/24 08:40:26 [warn] 308#308: *1978088914 upstream server temporarily
> disabled while reading response header from upstream, client: x.x.x.x,
> server: , request: "GET / HTTP/1.1", upstream: "http://x.x.x.x:80/";,
> host: ""
> 

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

> Честно говоря я предполагал такое поведение при исользовании группы
> серверов, но тут такого нет, а апстрим все-равно был забанен из-за ошибок.

В случае если адрес сервера в proxy_pass с переменными определяется
с помощью resolver'а, то на каждый запрос создаётся новый апстрим.
Это может быть не так e.g. в случае алиасинга с неявным апстримом;
я бы проверил это в первую очередь.

-- 
Sergey Kandaurov

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

proxy_pass to variable and upstream server temporarily disabled variable

2019-05-24 Thread kron 
Доброго дня!

nginx: 1.15.8

Конфигурация простая (конечно она сильно шире, но в качестве бэкенда сейчас
действительно один сервер задается через переменную):

split_clients "${remote_addr}${cookie_uid}" $backend {
  * "backend1.eu-central-1.elb.amazonaws.com";
}


server {
  listen 80;

  location / {
proxy_pass http://$backend;
  }
}

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

2019/05/24 08:40:26 [warn] 308#308: *1978088914 upstream server temporarily
disabled while reading response header from upstream, client: x.x.x.x,
server: , request: "GET / HTTP/1.1", upstream: "http://x.x.x.x:80/";,
host: ""

Честно говоря я предполагал такое поведение при исользовании группы
серверов, но тут такого нет, а апстрим все-равно был забанен из-за ошибок.
В документации ничего интересного на эту тему не нашел.

Есть какая то неявная логика в такой обработке?

Благодарю!

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

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

Re: Влияние на производительность проверок на существоание файла (-f) в rewrite модуле

2019-05-24 Thread Dmitriy Lyalyuev 
В этом случае код ответа будет 200, а не 503, как в условии.

> 24 мая 2019 г., в 09:42, Vladimir Getmanshchuk  написал(а):
> 
> Кстати конструкцию можно сильно упростить через try_files 
> /maintenance_on.html ... ;
> 
> On Thu, May 23, 2019 at 3:44 PM Maxim Dounin  > wrote:
> Hello!
> 
> On Thu, May 23, 2019 at 03:10:28PM +0500, Dmitry Sergeev wrote:
> 
> > Всем привет. Не поделится ли кто-нибудь опытом, сильно ли может повлиять 
> > на произовдительность конструкция:
> > 
> > >  location / {
> > >  if (-f /var/www/maintenance_on.html) {
> > >  return 503;
> > >  }
> > >
> > >
> > >  ...
> > >  }
> > >
> > >
> > >  # Error pages.
> > >  error_page 503 /maintenance_on.html;
> > >  location = /maintenance_on.html {
> > >  root /var/www;
> > >  }
> > Например 7-10 location  с такими проверками на хосте 4K запросов в секунду?
> > На каждый запрос он будет проверять существование файла? Или как-то это 
> > делает по таймауту, который можно настроить?
> 
> При такой конфигурации на каждый запрос[*] будет делаться 
> системный вызов stat().  Скорее всего необходимые данные будут в 
> кэше операционной системы, и этот системный вызов будет быстрым, 
> так что на производительности это скажется минимально.
> 
> Так что если речь не идёт о борьбе за каждый процент - про 
> производительность подобной конструкции можно не переживать.  
> Другой вопрос, что сама по себе конструкция не очень, выкатку 
> нужно уметь делать без перерывов в обслуживании.
> 
> [*] Вообще-то в можно ещё и настроить кэширование внутри nginx'а, 
> чтобы сэкономить системные вызовы (http://nginx.org/r/open_file_cache 
> ). 
> Но практика показывает, что на производительность это влияет 
> минимально, а вот выстрелить себе в ногу неатомарным изменением 
> файлов станет легко.
> 
> -- 
> Maxim Dounin
> http://mdounin.ru/ 
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org 
> http://mailman.nginx.org/mailman/listinfo/nginx-ru 
> 
> 
> -- 
> Yours sincerely,
> Vladimir Getmanshchuk
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru



smime.p7s
Description: S/MIME cryptographic signature
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru