From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: X-Spam-Status: No, score=-2.9 required=3.0 tests=ALL_TRUSTED,AWL,BAYES_00, URIBL_BLOCKED shortcircuit=no autolearn=unavailable version=3.3.2 X-Original-To: yahns-public@yhbt.net Received: from localhost (dcvr.yhbt.net [127.0.0.1]) by dcvr.yhbt.net (Postfix) with ESMTP id B0EC5200D7; Wed, 18 Mar 2015 20:00:01 +0000 (UTC) Date: Wed, 18 Mar 2015 20:00:01 +0000 From: Eric Wong To: "Lin Jen-Shin (godfat)" Cc: yahns-public@yhbt.net Subject: Re: [RFC] remove documentation for client_*_buffer_size knobs Message-ID: <20150318200001.GA30020@dcvr.yhbt.net> References: <20150316211532.GA17889@dcvr.yhbt.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: "Lin Jen-Shin (godfat)" wrote: > On Tue, Mar 17, 2015 at 5:15 AM, Eric Wong 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: --- 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