Вот только название не соответствует назначению.
Я бы назвал это 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?
Вобщем это какой-то стрёмный параметр на мой взгляд. В этом виде.