nging прокси

[Dmitry]

Добрый день!
Возникла аздача проксировать https на два сервера, но со следующими 
условиями, если один севрвер ответит определенными запросом (не абонента 
в биллинге), то проксировать на второй сервер, пример так вот:



https://1.1.1.1:1443/osmp-s.php?command=check=1104492_id=201604290950=20.00 
 




This XML file does not appear to have any style information associated 
with it. The document tree is shown below.


201604290950
5
User not found


То есть если User not found или result 5, отправлять на другой сервер.
Подскажите в каком направление двигаться, спасибо!


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

Re: Подмена бинарника в докере

[Igor Sysoev]

On 05 May 2016, at 18:55, Anton Bessonov  wrote:

> On 26.04.2016 22:19, Igor Sysoev wrote:
>> On 26 Apr 2016, at 19:27, Anton Bessonov  wrote:
>> 
>>> Спасибо большое, работает. И с демонизацией тоже.
>>> 
>>> Но наблюдаю эффект, что если убить мастера, то воркер остаётся один. И 
>>> только после убивания воркера ломается контейнер. Можно сделать как-то 
>>> (trap?), что бы контейнер или воркер с мастером ломались? А то состояние 
>>> странное.
>> Убить как - kill -9 или просто kill ? Во втором случае воркеры должны 
>> выходить.
>> 
> Как kill -9. С просто kill воркер выходит.

По kill -9 мастер уже ничего не может сделать.


-- 
Igor Sysoev
http://nginx.com

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

Re: Подмена бинарника в докере

[Anton Bessonov]

On 26.04.2016 22:19, Igor Sysoev wrote:

On 26 Apr 2016, at 19:27, Anton Bessonov  wrote:


Спасибо большое, работает. И с демонизацией тоже.

Но наблюдаю эффект, что если убить мастера, то воркер остаётся один. И только 
после убивания воркера ломается контейнер. Можно сделать как-то (trap?), что бы 
контейнер или воркер с мастером ломались? А то состояние странное.

Убить как - kill -9 или просто kill ? Во втором случае воркеры должны выходить.




Как kill -9. С просто kill воркер выходит.

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

Re: Часть запросов с анамольно большим $request time

[Maxim Dounin]

Hello!

On Thu, May 05, 2016 at 08:19:17AM -0400, malaf wrote:

> > > Влияние "медленных клиентов" на значение $request_time вроде отсёк,
> > проверив
> > > лог после обращения к странице в кеше с помощью curl --limit-rate
> > 20K
> > > example.com > /dev/null, время ответа было 4 секунды, в лог
> > request_time
> > > записался со значение 0.
> > 
> > Использование "curl --limit-rate" для эмуляции медленных клиентов - 
> > более или менее работает только в том случае, если размер ответа 
> > превышает суммарный размер всех буферов в цепочке.  Если в 
> > $request_time записалось значение 0 - это хороший признак, что 
> > ответ полностью влез в буфера, и с точки зрения nginx'а клиент - 
> > быстрее не бывает.
> А с каких точно буферов может состоять цепочка?

Как минимум - из буфера на отправку в сокете со стороны сервера, 
буфера на приём сокета со стороны клиента.  В зависимости от 
реализации "curl --limit-rate" - может быть ещё что-то внутри 
curl'а.  Ну и если используются туннели или прокси-сервера - к 
этому всему добавляются буфера в них.

> Пробовал ещё играться с настройками отключая совсем fastcgi_buffering off
> или уменьшая fastcgi_buffers 2 1k при размере ответа в 100КБ, чтобы было
> нехватка выделяемого буфера, но всё равно даже близко эмулировать проблемную
> ситуацию не удается.

Всё это не имеет отношения к вопросу.

> Хочется понять какие настройки ещё попробовать донастроить, чтобы избежать
> таких задержек.

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

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

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

Re: Часть запросов с анамольно большим $request time

[malaf]

> > Влияние "медленных клиентов" на значение $request_time вроде отсёк,
> проверив
> > лог после обращения к странице в кеше с помощью curl --limit-rate
> 20K
> > example.com > /dev/null, время ответа было 4 секунды, в лог
> request_time
> > записался со значение 0.
> 
> Использование "curl --limit-rate" для эмуляции медленных клиентов - 
> более или менее работает только в том случае, если размер ответа 
> превышает суммарный размер всех буферов в цепочке.  Если в 
> $request_time записалось значение 0 - это хороший признак, что 
> ответ полностью влез в буфера, и с точки зрения nginx'а клиент - 
> быстрее не бывает.
А с каких точно буферов может состоять цепочка?

Пробовал ещё играться с настройками отключая совсем fastcgi_buffering off
или уменьшая fastcgi_buffers 2 1k при размере ответа в 100КБ, чтобы было
нехватка выделяемого буфера, но всё равно даже близко эмулировать проблемную
ситуацию не удается.

Хочется понять какие настройки ещё попробовать донастроить, чтобы избежать
таких задержек.

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

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