Return-Path: Delivered-To: apmail-httpd-dev-archive@www.apache.org Received: (qmail 94121 invoked from network); 27 Oct 2006 19:35:13 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 27 Oct 2006 19:35:13 -0000 Received: (qmail 58642 invoked by uid 500); 27 Oct 2006 19:35:17 -0000 Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 58596 invoked by uid 500); 27 Oct 2006 19:35:17 -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 58578 invoked by uid 99); 27 Oct 2006 19:35:17 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 27 Oct 2006 12:35:17 -0700 X-ASF-Spam-Status: No, hits=0.7 required=10.0 tests=SUBJ_HAS_SPACES X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: local policy) Received: from [65.99.219.155] (HELO haxent.com) (65.99.219.155) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 27 Oct 2006 12:35:05 -0700 Received: from [192.168.200.205] (unknown [201.21.190.61]) by haxent.com (Postfix) with ESMTP id A314330953 for ; Fri, 27 Oct 2006 16:34:44 -0300 (BRT) Message-ID: <45425F53.7020002@haxent.com.br> Date: Fri, 27 Oct 2006 16:34:43 -0300 From: Davi Arnaut MIME-Version: 1.0 To: dev@httpd.apache.org Subject: Re: svn commit: r468373 - in /httpd/httpd/trunk: CHANGES modules/cache/mod_cache.c modules/cache/mod_cache.h modules/cache/mod_disk_cache.c modules/cache/mod_disk_cache.h modules/cache/mod_mem_cache.c References: <20061027132858.5098B1A9846@eris.apache.org> <454219CA.8090607@haxent.com.br> <20061027160024.GA18791@redhat.com> <41388.196.8.104.27.1161966137.squirrel@www.sharp.fm> <454244BE.2070904@haxent.com.br> <6.2.5.6.2.20061027144301.0266bb70@alum.wpi.edu> <45425A93.5080805@haxent.com.br> In-Reply-To: <45425A93.5080805@haxent.com.br> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Davi Arnaut wrote: > Greg Marr wrote: >> At 01:41 PM 10/27/2006, Davi Arnaut wrote: >>> Niklas Edmundsson wrote: >>>> And when you have a file backend, you want to hit your disk cache >>> and >>>> not the backend when delivering data to a client. People might >>> think >>>> that this doesn't matter, but for large files, especially larger >>> than >>>> RAM in your machine, you usually go disk-bound without much help >>> from >>>> the OS disk cache. >>> But that's a corner case. There is no reason in doing this for small >>> files (common case). For example, in a enterprise grade server >>> memory is >>> cheap and permanent storage is slow and expensive. >> So why would this server be using mod_disk_cache in that >> case? Shouldn't this server be using mod_mem_cache? Selecting >> mod_disk_cache over mod_mem_cache means it's better to serve the >> cache from disk rather than from memory. If serving from the disk on >> the original request is too slow, then wouldn't serving from the disk >> on the subsequent requests be too slow as well? >> > > Because the data is already in memory. Why should I write something to > disk, erase it from memory, and read it again shortly ? Why should I > take care of something that is the job of the OS ? Why should I trash > the VM constantly ? I should note that if there is enough memory those reads will be served by the page cache. Later we could think about reading directly to mmapable files, changing it's protection (from rw to ro) as soon as we are done writing to. -- Davi Arnaut