From: Brian Pane <brianp@apache.org>
Date: Wed, 31 Jul 2002 05:30:12 +0000 (+0000)
Subject: Document the content-length filter performance problems
X-Git-Tag: 2.0.40~70
X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=8720431357a1609d419e38321f72b2212c6fb4df;p=thirdparty%2Fapache%2Fhttpd.git

Document the content-length filter performance problems


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@96249 13f79535-47bb-0310-9956-ffa450edef68
---

diff --git a/STATUS b/STATUS
index 98cf2e08681..5c0c95942fa 100644
--- a/STATUS
+++ b/STATUS
@@ -1,5 +1,5 @@
 APACHE 2.0 STATUS:                                              -*-text-*-
-Last modified at [$Date: 2002/07/24 16:55:45 $]
+Last modified at [$Date: 2002/07/31 05:30:12 $]
 
 Release:
 
@@ -109,6 +109,13 @@ CURRENT VOTES:
 
 RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP:
 
+    * Performance problems in the content-length filter:
+      - In many situations, the C-L filter sets aside buckets
+        until it sees EOS.  Setting aside file buckets is bad
+        because it requires an mmap+memcpy+munmap.
+      - In addition, the C-L filter reads and buffers all the
+        content from a pipe bucket.
+
     * All handlers should always send content down even if r->header_only
       is set.  If not, it means that the HEAD requests don't generate the
       same headers as a GET which is wrong.