keepalive_requests default 100

[B.R.]

I suspect nginx' team chose this value for the very reason it was adapted
to the use of Apache (remember that nginx is, since its beginning, largely
used as a reverse Web proxy in front of Apache farms).
I guess the intent here is to probably mimic Apache behavior by default so
adoption of that technology is eased.

In the Apache world, long-lasting connections may result in resource
starvation, since 1 connection = expensive resources allocated. Thus, you
can quickly end-up with a few (relatively and even infrequently) active
clients saturating a Web server machine, leaving no spots free for
newcomers, especially nowadays with multithreaded/processed browsers.
Recycling connections often is an attempt at fighting that.

Unless I am overlooking something, there seems not to have any technical
ground for such a limit to be pertinent with nginx.

As debated in the past on this ML (and at the 1st nginx conference), some
other default values might not be right anymore, but changing default value
might silently break backwards-compatibility with setups which do not
comply with the new defaults. History repeatedly shows that changing old
defaults and even deprecating the use of rotten algorithms is faced with
huge resistance. IE6? SSLv3? RC4?, HTTP/1.0? Amongst many others...
Thus the nginx team position has (so far?) been to never touch the built-in
defaults (and neither maybe the default nginx.conf? I have not checked
that) and let people override them through configuration.
---
*B. R.*

On Wed, Mar 8, 2017 at 2:21 AM, Tolga Ceylan <tolga.ceylan at gmail.com> wrote:

> Does anybody have any history/rationale on why keepalive_requests
> use default of 100 requests in nginx? This same default is also used in
> Apache. But the default seems very small in today's standards.
>
> http://nginx.org/en/docs/http/ngx_http_core_module.html#keepalive_requests
>
> Regards,
> Tolga
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20170308/f0d53ff0/attachment.html>