Return-Path: Delivered-To: apmail-httpd-dev-archive@www.apache.org Received: (qmail 88537 invoked from network); 6 Sep 2010 19:10:56 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 6 Sep 2010 19:10:56 -0000 Received: (qmail 76420 invoked by uid 500); 6 Sep 2010 19:10:55 -0000 Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 76360 invoked by uid 500); 6 Sep 2010 19:10:54 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 76352 invoked by uid 99); 6 Sep 2010 19:10:54 -0000 Received: from Unknown (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 06 Sep 2010 19:10:54 +0000 X-ASF-Spam-Status: No, hits=-2.3 required=10.0 tests=RCVD_IN_DNSWL_MED,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [188.40.99.202] (HELO eru.sfritsch.de) (188.40.99.202) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 06 Sep 2010 19:10:31 +0000 Received: from [10.1.1.6] (helo=k.localnet) by eru.sfritsch.de with esmtp (Exim 4.69) (envelope-from ) id 1Osh50-00052c-G9 for dev@httpd.apache.org; Mon, 06 Sep 2010 21:10:10 +0200 From: Stefan Fritsch To: dev@httpd.apache.org Subject: Re: mod_cache: store_body() bites off more than it can chew Date: Mon, 6 Sep 2010 21:10:10 +0200 User-Agent: KMail/1.13.5 (Linux/2.6.32-5-amd64; KDE/4.4.5; x86_64; ; ) References: <68B35D56-BB55-458F-A7BB-E225AFEB8544@sharp.fm> <4160A015-8461-4D3C-9FB0-DDA6FE797105@sharp.fm> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201009062110.10771.sf@sfritsch.de> X-Virus-Checked: Checked by ClamAV on apache.org On Monday 06 September 2010, Paul Fee wrote: > Currently headers and data are in separate files. If they were in > a single file, the operating system is given more indication that > these two items are tightly coupled. For example, when the > headers are read in, the O/S can readahead and buffer part of the > body. I think it would be better to use posix_fadvise() to give the OS hints to improve read-ahead. But this probably needs some profiling, it could have a negative effect on memory constrained systems.