<div dir="ltr"><div>I don't see why we would want the upstream default be the same as the downstream. <br></div><div>Upstream and downstream have different characteristics, as explained in <br></div><div>this post <a href="http://mailman.nginx.org/pipermail/nginx/2015-December/049445.html">http://mailman.nginx.org/pipermail/nginx/2015-December/049445.html</a> why <br></div><div>HTTP2 is supported in downstream but not in upstream. Upstream (your own backend) <br></div><div>will most likely have configured super long keepalive since the connection is only <br></div><div>from trusted client (nginx proxy) and not directly open to the Internet. With the new default, <br></div><div>the connection has to be torn down and reestablished every second for a 100TPS link.</div><div>In old behavior we only need to configure backend to control how long the connection to</div><div>stay up. Now we have to change both nginx and backend.</div><div><br></div><div>Thanks!</div><div>Frank<br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Sun, Aug 12, 2018 at 5:42 AM Maxim Dounin <<a href="mailto:mdounin@mdounin.ru">mdounin@mdounin.ru</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello!<br>
<br>
On Fri, Aug 10, 2018 at 01:50:04PM -0700, Robert Paprocki wrote:<br>
<br>
> Quite the patch. I recall this behavior being discussed a number of times<br>
> in the past.<br>
> <br>
> Question: why the default of 100? This feels like a significantly breaking<br>
> change wrt. the previous behavior. Are there any plans for advanced<br>
> communication regarding this change, outside of a nominal changelog entry<br>
> (e.g., "introduced 'keepalive_requests' directive")?<br>
<br>
The default is 100 to match the same default of the client-side <br>
keepalive_requests, see <a href="http://nginx.org/r/keepalive_requests" rel="noreferrer" target="_blank">http://nginx.org/r/keepalive_requests</a>.  <br>
Also, it is believed that 100 is a good enough number for most <br>
setups.  While it may be somewhat low for some extreme <br>
configurations, it can be easily adjusted using the directive.<br>
<br>
I don't think that your concerns about "breaking change" are <br>
relevant, especially keeping in mind that a) upstream keepalive is <br>
off by default and b) event with upstream keepalive configured, <br>
requests can easily re-open or close connections for various other <br>
reasons, in particular - due to limited number of connections <br>
which are kept in the cache.  Even assuming ideal conditions, <br>
this change can only affect 1 percent of requests.<br>
<br>
-- <br>
Maxim Dounin<br>
<a href="http://mdounin.ru/" rel="noreferrer" target="_blank">http://mdounin.ru/</a><br>
_______________________________________________<br>
nginx-devel mailing list<br>
<a href="mailto:nginx-devel@nginx.org" target="_blank">nginx-devel@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx-devel" rel="noreferrer" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx-devel</a><br>
</blockquote></div>