Return-Path: Delivered-To: new-httpd-archive@hyperreal.org Received: (qmail 944 invoked by uid 6000); 16 Apr 1999 08:57:52 -0000 Received: (qmail 933 invoked from network); 16 Apr 1999 08:57:50 -0000 Received: from penguin-ext.wise.edt.ericsson.se (HELO penguin.wise.edt.ericsson.se) (194.237.142.5) by taz.hyperreal.org with SMTP; 16 Apr 1999 08:57:50 -0000 Received: from dsnstar.dsn.ericsson.se (dsnstar.dsn.ericsson.se [164.48.68.130]) by penguin.wise.edt.ericsson.se (8.9.0/8.9.0/WIREfire-1.2) with ESMTP id KAA15474 for ; Fri, 16 Apr 1999 10:57:47 +0200 (MET DST) Received: from dsn.ericsson.se (root@[164.48.68.24]) by dsnstar.dsn.ericsson.se (8.8.5/8.8.5) with ESMTP id KAA19262 for ; Fri, 16 Apr 1999 10:57:46 +0200 (MET DST) Message-ID: <3716FB49.290F5C09@dsn.ericsson.se> Date: Fri, 16 Apr 1999 08:56:42 +0000 From: Graham Leggett Organization: Ericsson X-Mailer: Mozilla 4.51 [en] (X11; U; Linux 2.0.36 i586) X-Accept-Language: en MIME-Version: 1.0 To: new-httpd@apache.org Subject: Re: CacheSize default - is this correct? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: new-httpd-owner@apache.org Precedence: bulk Reply-To: new-httpd@apache.org Marc Slemko wrote: > > According to the documentation, the "CacheSize" parameter specifies the > > size of the disk cache measured in kilobytes (1024 byte units). The > > default for the option however is 5. > > That is, AFAIK, correct. > > > > > 5 kilobytes? Isn't this a bit small for a cache? Is this not perhaps > > meant to be megabytes? > > No. The default is correct. Ok, thanks for the clarification. > Completely nonsensical? Yes. But still "correct". There are certainly > arguments for changing it, but it is only one of a number of... > questionable things in the proxy. Is it not possible to get this default changed? The reason I asked was because I wasn't 100% sure if Apache treated it as kB or MB - I didn't want to set the parameter to 2000000 (2GB) and then find by mistake I had configured 2 terrabyes instead. I think the proxy code has remained untouched for a while because of the existance of dedicated forward proxies such as Squid and others which are highly tuned for their intended purpose - forward caching. However for reverse caching it makes more sense to deploy a webserver with reverse caching capabilities than a proxy server with reverse capabilities, which we discovered when we tried to convince Netscape Proxy server to support virtual hosts, multiple websites behind a single host, redirects and split logfiles, most of which Netscape Proxy couldn't easily do but all of which Apache handles very nicely. The only problem with Apache we found was with reverse proxy and caching, however delving into the source has uncovered a bug and a workaround, so it's fixed in the shortterm. When I find the solution I'll post a patch... Regards, Graham --