Use of upstream keepalive_time

Vishwas Bm bmvishwas at gmail.com
Thu Feb 2 07:33:13 UTC 2023


Thanks for the reply.

Can this keepalive_time be made infinite ?
So that connection is not broken after default 1hr


Regards,
Vishwas


On Sat, Jan 21, 2023, 05:32 Maxim Dounin <mdounin at mdounin.ru> wrote:

> Hello!
>
> On Fri, Jan 20, 2023 at 11:37:15AM +0530, Vishwas Bm wrote:
>
> > I see that from 1.19.10 keepalive_time has been added.
> >
> http://nginx.org/en/docs/http/ngx_http_upstream_module.html#keepalive_time
> >
> > Also keepalive_timeout is present for idle connection
> >
> http://nginx.org/en/docs/http/ngx_http_upstream_module.html#keepalive_timeout
> >
> > On checking the behaviour between these two, I see that keepalive_time is
> > having higher precedence over keepalive_timeout.
> > Even if connection is not idle based on keepqlive_timeout, connection is
> > still  getting closed because of keepalive_time.
> >
> > Is this expected behaviour?
> > Also can I set keepalive_time to higher value say 24hours ? Any drawbacks
> > with this ?
> > Can this keepalive_time be disabled and priority given only to
> > keepalive_timeout ?
>
> The "keepalive_time" is a directive to limit total lifetime of the
> connection, making it possible to free any resources associated
> with the connection, notably allocated memory.  Further, in some
> setups it might be important to periodically redo connection
> authentication, notably re-validate peer certificates.
>
> The "keepalive_time" directive is mostly equivalent to
> keepalive_requests, which is documented as follows:
>
> : Closing connections periodically is necessary to free
> : per-connection memory allocations. Therefore, using too high
> : maximum number of requests could result in excessive memory usage
> : and not recommended.
>
> Note though that keepalive_time is 1 hour by default, and reopening
> connections once per hour is not expected to have any performance
> impact.  Rather, it is expected to be a hard limit on the total
> connection lifetime on connections which are mostly idle and
> therefore do not reach the "keepalive_requests" limit in a
> reasonable time.
>
> --
> Maxim Dounin
> http://mdounin.ru/
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20230202/088ac339/attachment.htm>


More information about the nginx mailing list