teo
January 27, 2013 12:17PM
Валентин Бартенев Wrote:
-------------------------------------------------------
>
> Вы его выключили указав ip_hash.

Кто бы мог подумать! Тогда в моем случае получалось, что все 1200 соединений пришло из одной сети класса С.
Впрочем спасибо, без этого параметра действительно пока все работает - посмотрим как долго он продержится.

> nginx тоже не срубят, если файл действительно будет "вытаскиваться", а
> не 10 минут висеть. Обратите внимание, многие таймауты задаются на
> интервалы
> между двумя последовательными операциями, а не на весь ответ целиком.

ну да, вы правы. Чтение документации уточняет этот момент

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

Согласен, но это не нужно, если есть "другие" ответы от сервера.
Но просто равномерное распределение запросов по бекендам тоже не спасает - никто не гарантирует, что все "тяжелые" запросы не скопятся на одном.
Идеально было бы иметь размер "очереди" доступный в любой момент - впрочем это видимо у nginx-а есть, по крайней мере как число собственных соединений.
Альтернатива - измерение среднего времени ответа бекенда за последние n-секунд или запросов - следующий отдавать тому, у кого он меньше.
Впрочем асинхронная природа weblogic видимо противоречит природе nginx - weblogic легко принимает входящие запросы, укладываясь в отведенные таймауты. Только обработка их откладывается взависимости от наличия свободного обработчика. nginx же думает раз его запросы "приняты", значит можно туда же кидать следующие. Но надо было бы измерять не кол-во отданных запросов, а кол-во полученных ответов.
Думается в этом случае помог бы параметр максимального кол-ва соединений, ожидающих ответа в описании бекенда.
Если его выставить равное кол-ву обработчиков у бекенда - то проблемы бы не возникло.

> Это другой метод балансировки, который на данный момент не доступен в
> бесплатной
> версии nginx.

Платная версия ссылается на доку в бесплатной (вроде), может можете привести ссылку на доку где описаны и такие методы?

> Nginx поддерживает keepalive начиная с версии 1.1.4.
>
> http://nginx.org/r/keepalive/ru
>

Вот только название не соответствует назначению.
Я бы назвал это connection_pool.
В моем понимании поддержка keep_alive должна была бы учитывать значения, возвращаемые в ответе бекендом, чтобы не закрывая конект пихнуть в него еще один запрос, если его время еще не истекло.
И обычно задается не кол-во соединений, а время, в течении которого клиент еще может пихать запросы. Т.е. сервер соглашается не закрывать на это время свое соединение, если клиент сказал что "он умеет так". Тогда на бекенде ставится самое большое keep_alive, а на посреднике чуть меньшее - с тем, чтобы уложиться в него с учетом своего оверхеда. Можно конечно и сложнее организовать - если клиент не умеет, то это не мешает посреднику самому использовать одно соединение с бекендом для разных клиентов. Или даже если keep_alive бекенда уже истек - то для новых запросов использовать новые/другие соединения с бекендом. Т.е. полностью развязать keep_alive бекенда и свой собственный.

А держать открытыми некоторое кол-во соединений? Почему только такое кол-во? Это с учетом того, что бекенд это поддерживает?
Или клиент иногда будет получать "ваш запрос не обработан, потому что nginx попытался пихнуть его в открытый конект из этого пула, но бекенд уже решил, что время keep_alive истекло и в ответ закрыл этот конект"?
Дока как-то этот момент опускает.
И не потому ли она советует не увлекаться и в примерах стоит всего 32? Это притом, что дефолтно в настройках стоит 1024 возможных конекта и один обработчик? Как вы думаете - какой будет middle water mark при этих параметрах? 100?
А как будет себя вести сервер, если я сконфигурил 10 обработчиков по 1024 конекта? Т.е. мне надо поставить что-то около 2048 в keepalive?
А в случае простоя, каждые 60 сек (keep_alive бекенда) у меня будут открываться и закрываться 2048 соединений? Вообщем-то не велика беда. Только зачем?
А на остальных 8192 соединениях - там не будет поддерживаться keep_alive?

Вобщем это какой-то стрёмный параметр на мой взгляд. В этом виде.
Subject Author Posted

nginx as reverse proxy for weblogic

teo January 27, 2013 02:45AM

Re: nginx as reverse proxy for weblogic

Илья Шипицин January 27, 2013 05:10AM

Re: nginx as reverse proxy for weblogic

teo January 27, 2013 08:38AM

Re: nginx as reverse proxy for weblogic

Роман Москвитин January 27, 2013 09:40AM

Re: nginx as reverse proxy for weblogic

teo January 27, 2013 10:03AM

Re: nginx as reverse proxy for weblogic

Vadim Lazovskiy January 27, 2013 11:32AM

Re: nginx as reverse proxy for weblogic

Роман Москвитин January 27, 2013 02:18PM

Re: nginx as reverse proxy for weblogic

Валентин Бартенев January 27, 2013 09:00AM

Re: nginx as reverse proxy for weblogic

teo January 27, 2013 12:17PM

Re: nginx as reverse proxy for weblogic

Илья Шипицин January 27, 2013 01:20PM

Re: nginx as reverse proxy for weblogic

teo January 27, 2013 04:54PM

Re: nginx as reverse proxy for weblogic

Andrey Repin January 27, 2013 08:06PM

Re: nginx as reverse proxy for weblogic

Илья Шипицин January 27, 2013 11:16PM

Re: nginx as reverse proxy for weblogic

teo April 23, 2013 02:12PM



Sorry, only registered users may post in this forum.

Click here to login

Online Users

Guests: 60
Record Number of Users: 6 on February 13, 2018
Record Number of Guests: 421 on December 02, 2018
Powered by nginx      Powered by FreeBSD      PHP Powered      Powered by MariaDB      ipv6 ready