I don't see why we would want the upstream default be the same as the
downstream.
Upstream and downstream have different characteristics, as explained in
this post http://mailman.nginx.org/pipermail/nginx/2015-December/049445.html
why
HTTP2 is supported in downstream but not in upstream. Upstream (your own
backend)
will most likely have configured super long keepalive since the connection
is only
from trusted client (nginx proxy) and not directly open to the Internet.
With the new default,
the connection has to be torn down and reestablished every second for a
100TPS link.
In old behavior we only need to configure backend to control how long the
connection to
stay up. Now we have to change both nginx and backend.

Thanks!
Frank


On Sun, Aug 12, 2018 at 5:42 AM Maxim Dounin <mdounin@mdounin.ru> wrote:

> Hello!
>
> On Fri, Aug 10, 2018 at 01:50:04PM -0700, Robert Paprocki wrote:
>
> > Quite the patch. I recall this behavior being discussed a number of times
> > in the past.
> >
> > Question: why the default of 100? This feels like a significantly
> breaking
> > change wrt. the previous behavior. Are there any plans for advanced
> > communication regarding this change, outside of a nominal changelog entry
> > (e.g., "introduced 'keepalive_requests' directive")?
>
> The default is 100 to match the same default of the client-side
> keepalive_requests, see http://nginx.org/r/keepalive_requests.
> Also, it is believed that 100 is a good enough number for most
> setups. While it may be somewhat low for some extreme
> configurations, it can be easily adjusted using the directive.
>
> I don't think that your concerns about "breaking change" are
> relevant, especially keeping in mind that a) upstream keepalive is
> off by default and b) event with upstream keepalive configured,
> requests can easily re-open or close connections for various other
> reasons, in particular - due to limited number of connections
> which are kept in the cache. Even assuming ideal conditions,
> this change can only affect 1 percent of requests.
>
> --
> Maxim Dounin
> http://mdounin.ru/
> _______________________________________________
> nginx-devel mailing list
> nginx-devel@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-devel
>
_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel