Re: conflict of interest

--MimeMultipartBoundary
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit

miguel a.l. paraz wrote:

> > Maybe we should keep URLs, but not keep them in memory. We could
save
> > everything to disk, but keep only things needed for HIT/IMS/MISS in
> > memory. When and if we should need URL or anything else that is not
> > used all the time we would still have them...
>
> How about putting the URL as a pseudo-MIME header. My assumption is
> that initially at least, the servers that request for hit metering
> are few and far between, and it won't hurt to visit the store for
> that.
>
> Which reminds me -- remember that proposal to store the MIME headers
> and the object content separately? With this method, it will be
> easier to read the headers, and, we could use the headers to store
> arbitrary info about the object that we do not want to put in
> memory.

The third option is to upgrade main index (log) into fast database. We
could then keep all data, statistics, urls, and maybe even mime headers
in this database.

We should keep everything that is needed for ICP reply in ram (or
else the disks i/o would choke system).

When we get http request (HIT), we must read the file, so this is the
best place for mime headers. (If we separate header from data, we must
make two reads.)

In the database (index) we could keep all counters, url, statistics...
We could even write some items as headers... (so, we would have to make
only one read)

Maximum size of cache is directly linked to RAM (15 MB ram ~= 1 GB
cache), so less things we have in ram, bigger cache we can build (we
can always add more disks).. If we have 10M items in cache, then every
byte saved means 10 MB of RAM..

--MimeMultipartBoundary--
Received on Tue Jul 29 2003 - 13:15:44 MDT