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
