Return-Path: Delivered-To: apmail-httpd-dev-archive@www.apache.org Received: (qmail 67531 invoked from network); 2 Aug 2004 18:17:52 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 2 Aug 2004 18:17:52 -0000 Received: (qmail 94323 invoked by uid 500); 2 Aug 2004 18:17:44 -0000 Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 94270 invoked by uid 500); 2 Aug 2004 18:17:44 -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: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 94254 invoked by uid 99); 2 Aug 2004 18:17:43 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received: from [64.236.240.190] (HELO web.turner.com) (64.236.240.190) by apache.org (qpsmtpd/0.27.1) with ESMTP; Mon, 02 Aug 2004 11:17:40 -0700 Received: from [192.168.1.100] (atl-vpn-124-47.turner.com [10.188.124.47]) by web.turner.com (8.12.9/8.12.9) with ESMTP id i72IHWg0002477 for ; Mon, 2 Aug 2004 14:17:32 -0400 (EDT) Message-ID: <410E853F.5000502@web.turner.com> Date: Mon, 02 Aug 2004 14:17:35 -0400 From: Brian Akins User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.1) Gecko/20040715 Debian/1.7.1-1 X-Accept-Language: en MIME-Version: 1.0 To: dev@httpd.apache.org Subject: Re: [PATCH] mod_cache fixes: #8 References: <40B25DBF8F84D316162D79F8@[10.0.1.74]> <410D0B83.9040100@wstoddard.com> <413520F52887259736D5D43B@[10.0.1.76]> <410E378F.1020305@web.turner.com> <25519DCD4B349C6434F21FBB@[10.0.1.77]> In-Reply-To: <25519DCD4B349C6434F21FBB@[10.0.1.77]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N Justin Erenkrantz wrote: > > post_config's not a bad place for that. But, I've yet to get a good > handle on my thoughts for the storage mechanism that mod_disk_cache is > using. My hunch so far is that it's really inefficient. (The reading > of the headers one-byte at a time with the brain-dead apr_file_gets() > just *killed* performance.) Could do something like reading the struct first. Then just read the rest of the headers into memoyr and parse them there. Also having an array of headers and just saving the index to the file is more effecient: psuedo code: headers = { "Cache-Control", "Expires", .... } then while caching them, to store the Expires header, for example, just write 1 (the index of the expires header) and then the value to the headers file. Then parsing is much faster as well. > And, there might be a way to also save the entire response headers and > body and allow a straight sendfile from that. Don't know if that will work. Also, you still have to store and parse meta data as well. > Sort of dislike the fact that you must pre-create the dirs. Yet, I > understand the point here. The extra stat calls might end up being > harmful. Will chew on this and see if the dirs become a bottleneck or > not. -- justin > It is a bottle neck on very busy server when the directories do not exist. Once the server has ran for a while, it doesn't matter as the majority of the directories have been made... Also, is it necessary to try to remove the file even when we are not sure it exists? -- Brian Akins Senior Systems Engineer CNN Internet Technologies