Return-Path: Delivered-To: apmail-httpd-dev-archive@www.apache.org Received: (qmail 24233 invoked from network); 11 Feb 2008 13:39:26 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 11 Feb 2008 13:39:26 -0000 Received: (qmail 6121 invoked by uid 500); 11 Feb 2008 13:39:16 -0000 Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 6061 invoked by uid 500); 11 Feb 2008 13:39:16 -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 6050 invoked by uid 99); 11 Feb 2008 13:39:16 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 11 Feb 2008 05:39:16 -0800 X-ASF-Spam-Status: No, hits=-4.0 required=10.0 tests=RCVD_IN_DNSWL_MED,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [64.236.240.74] (HELO atlmail3.turner.com) (64.236.240.74) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 11 Feb 2008 13:38:46 +0000 X-IronPort-AV: E=Sophos;i="4.25,333,1199682000"; d="scan'208";a="311824470" Received: from atlbh02.turner.com ([10.188.157.232]) by atliport01.turner.com with ESMTP; 11 Feb 2008 08:38:53 -0500 Received: from ATLMSG13.turner.com ([10.188.170.53]) by ATLBH02.turner.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 11 Feb 2008 08:38:52 -0500 Received: from 10.188.174.6 ([10.188.174.6]) by ATLMSG13.turner.com ([10.188.170.53]) via Exchange Front-End Server atlwebaccess.turner.com ([10.188.157.195]) with Microsoft Exchange Server HTTP-DAV ; Mon, 11 Feb 2008 13:38:52 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Mon, 11 Feb 2008 08:38:52 -0500 Subject: Re: cache - cleaning up mod_memcache and making other caches their live easier From: "Akins, Brian" To: "dev@httpd.apache.org" Message-ID: Thread-Topic: cache - cleaning up mod_memcache and making other caches their live easier Thread-Index: AchsRE48iCHzS7MGT7uadd5ZUKHtIwAYK9bQAAOcsXo= In-Reply-To: <99EA83DCDE961346AFA9B5EC33FEC08B464662@VF-MBX11.internal.vodafone.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 11 Feb 2008 13:38:52.0676 (UTC) FILETIME=[70C1E440:01C86CB3] X-Virus-Checked: Checked by ClamAV on apache.org If anyone cares, here's how we do keys and vary in our cache: On store: Generate key: using url and r->args (we can ignore r->args per server, if needed) (http://www.domain.com/index.html?you=me) If(vary) { store the following info in meta file: cache_version_t - ala disk_cache (ours includes expire time) length of key (apr_size_t) including \0 key with \0 length of "array" (apr_size_t) a \0 delimited array of Vary headers regenerate key (basically the original key + vary info: http://www.domain.com/index.html?you=meuser-agentmozillaaccept-encodinggzip ) } Store key in meta file. a normal meta file has this format: cache_version_t (ours includes expire time) length of key (apr_size_t) including \0 key with \0 length of "table" (apr_size_t) a \0 delimited table (key\0value\0key\0value\0....) of response headers Note: the reason we use \0 delimited arrays/tables is we read the entire metafile info into memory on serving and then just apr_table_setn on the values. In theory we could mmap the meta files, but we actually found that to be slower. On serving: Generate key: using url and r->args (we can ignore r->args per server, if needed) (http://www.domain.com/index.html?you=me) Open metafile If(vary) { thaw vary array generate new key (vary values may be overridden by env) open new metafile } Thaw headers, etc. So, we only store the headers that we use in vary key calculation. On my TODO list is to make key generation a hook bcs we have apps that would benefit from that. Of course, we have only one provider (disk) and ignore a lot of RFC stuff (although we have made most of that configurable), but our key/vary handling is pretty fast (I spent a lot of time with profilers when writing it). I'm still working on my side to allow us to actually release the code. -- Brian Akins Chief Operations Engineer Turner Digital Media Technologies