[RFC] remove documentation for client_*_buffer_size knobs

[RFC] remove documentation for client_*_buffer_size knobs

[Eric Wong]

Memory management is tricky when dealing with thousands of connected
clients and various malloc implementations.  Any thoughts on this
greatly appreciated, thanks.

In the future, we may remove these options entirely.  For now,
having too much documentation and tuning options may confuse new
users and minimize the importance/visibility of other options,
so remove documentation for this.

I'm not convinced user-space buffer size tuning has a place in
an application server written in a high-level language.  Heck,
many servers written in C do not have this.
---
 Documentation/yahns_config.txt | 18 ------------------
 1 file changed, 18 deletions(-)

diff --git a/Documentation/yahns_config.txt b/Documentation/yahns_config.txt
index d18263d..7a507a4 100644
--- a/Documentation/yahns_config.txt
+++ b/Documentation/yahns_config.txt
@@ -201,24 +201,6 @@ Ruby it is running under.
 
     Default: false
 
-* client_body_buffer_size INTEGER
-
-    This controls the maximum size of a request body before it is
-    buffered to the filesystem (instead of memory).  This has no effect
-    if input_buffering is false.  This also governs the size of an
-    individual read(2) system call when reading a request body.
-
-    Default: 8192 bytes (8 kilobytes)
-
-* client_header_buffer_size INTEGER
-
-    This controls the size of a single read(2) syscall for reading
-    client request headers.  Increase this as needed if your application
-    uses large cookies or long URLs.  Lowering this may reduce GC and
-    memory allocator overhead.
-
-    Default 4000 bytes
-
 * client_max_body_size {INTEGER|nil}
 
     This controls the maximum request body size before a client is
-- 
EW

Re: [RFC] remove documentation for client_*_buffer_size knobs

[Lin Jen-Shin (godfat)]

On Tue, Mar 17, 2015 at 5:15 AM, Eric Wong <e@80x24.org> wrote:
[...]
> In the future, we may remove these options entirely.  For now,
> having too much documentation and tuning options may confuse new
> users and minimize the importance/visibility of other options,
> so remove documentation for this.
>
> I'm not convinced user-space buffer size tuning has a place in
> an application server written in a high-level language.  Heck,
> many servers written in C do not have this.

Personally I do like various options even if I won't touch them,
since maybe I'll on some day. We could put more advanced
options in advanced configuration page to avoid confusion.
Or a warning like "Don't touch them unless you really know
what you're doing" should be good (scary) enough.

However, I don't know if it makes sense to configure
client_header_buffer_size and client_max_body_size.
(nginx has them, I think?) If not, I guess it's really fine to
remove them, and we're free to change them or stop
providing those options in the future. That's also good, I guess.

Re: [RFC] remove documentation for client_*_buffer_size knobs

[Eric Wong]

"Lin Jen-Shin (godfat)" <godfat@godfat.org> wrote:
> On Tue, Mar 17, 2015 at 5:15 AM, Eric Wong <e@80x24.org> wrote:
> [...]
> > In the future, we may remove these options entirely.  For now,
> > having too much documentation and tuning options may confuse new
> > users and minimize the importance/visibility of other options,
> > so remove documentation for this.
> >
> > I'm not convinced user-space buffer size tuning has a place in
> > an application server written in a high-level language.  Heck,
> > many servers written in C do not have this.
> 
> Personally I do like various options even if I won't touch them,
> since maybe I'll on some day. We could put more advanced
> options in advanced configuration page to avoid confusion.
> Or a warning like "Don't touch them unless you really know
> what you're doing" should be good (scary) enough.

Probably a warning is enough.  Patch below for client_body_buffer_size

> However, I don't know if it makes sense to configure
> client_header_buffer_size and client_max_body_size.

I think you meant client_body_buffer_size (not max_body), which is one
I'm least enthusiastic about tuning.

client_max_body_size needs to stay, major DoS potential there.

> (nginx has them, I think?) If not, I guess it's really fine to
> remove them, and we're free to change them or stop
> providing those options in the future. That's also good, I guess.

nginx documentation is a forest nowadays and I'm trying to avoid
going down that path.

I've also been thinking about auto-tuning/variable header buffer sizes.
Some apps rely on giant URLs and cookies while others do not.  But maybe
the apps with giant URLs/cookies are screwed anyways performance-wise
and yahns shouldn't try too hard to optimize for them.

-------------------------------8<---------------------------
Subject: [PATCH] doc: note possible removal of client_body_buffer_size

This is probably the least useful tuning knob and may be removed
in the future; so at least warn users about it.

ref: <CAA2_N1t_UJZO9Vu9vx3NxysCx+okip8_pM+NpwhHrExM+f1e+Q@mail.gmail.com>
---
 Documentation/yahns_config.txt | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/yahns_config.txt b/Documentation/yahns_config.txt
index d18263d..3683298 100644
--- a/Documentation/yahns_config.txt
+++ b/Documentation/yahns_config.txt
@@ -208,6 +208,9 @@ Ruby it is running under.
     if input_buffering is false.  This also governs the size of an
     individual read(2) system call when reading a request body.
 
+    There is generally no need to change this value and this directive
+    may be removed in the future.
+
     Default: 8192 bytes (8 kilobytes)
 
 * client_header_buffer_size INTEGER
-- 
EW