nginx as reverse proxy for weblogic

[teo]

Валентин Бартенев 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?

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

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,235603,235618#msg-235618