From:	SMTP%"vandenheuvel@eps.enet.dec.com"  7-NOV-1994 09:44:20.61
To:	EVERHART
CC:	
Subj:	Re: Cache the whole thing (was Re: Compressing sysuaf and rightslist)

From: vandenheuvel@eps.enet.dec.com (Hein RMS van den Heuvel)
X-Newsgroups: comp.os.vms
Subject: Re: Cache the whole thing (was Re: Compressing sysuaf and rightslist)
Date: 6 NOV 94 23:39:36
Organization: Digital Equipment Corporation
Lines: 46
Message-Id: <39kbso$s71@jac.zko.dec.com>
Nntp-Posting-Host: AMUZED
To: Info-VAX@Mvb.Saic.Com
X-Gateway-Source-Info: USENET


In article <1994Nov7.112255.134225@praxa.com.au>, krj@praxa.com.au writes...
>In article <38qvlc$cn8@jac.zko.dec.com>, vandenheuvel@eps.enet.dec.com (Hein RMS van den Heuvel) writes:
> 
 :
> 
>I've run sucessfuly for donkey's years in a commercial shop with
>$converted SYSUAF's with all compressions turned on via FDL. 
> 
>As an interesting aside, I had a saturated system disk 7*24*365 on a
>moderate/large NICI cluster, double digit disk queues due to large
>SYSUAF hit from VMS mail & 4GL subprocess creates -- 'twas the stuff of
>horror.  Took a hint from Keith Walls waaay back at DECUS Hobart
>(Tasmania, not Ohio for all you northerners:-) and cached the entire
>SYSUAF, RIGHTSLIST via $set file/globa=<n>, where n = file size in
>blocks/max bucket size from $dir/full.  Took our IO's down to cluster
>aggregate of 7 IO/sec during peaks 8-) .  Took a bit of tuning for the
>vaxstations in re: gblpages, gblpagfil but it was very much worth it. 
>Users were rapt. 

Preaching to to converted [sic!]. I've been trying to convince folks
for years now to use global buffers. The most common reply is 
'we need a meeting to determine to optimal number of buffers'
my answer: 'the only wrong number is 0. Try anything first, and then
worry about optimal if you _have_ to'. The next most common reply
is 'but those files are updated all the time'. My answer: 'so what!?
an indexed file update write as often preceded by root-read, index-read,
data-read. All those reads could easily be from a global buffer cache.'
While the update write IO obviously has to take place, it would also
have to take place from a local buffer. When done from a global buffer 
there is at least some chance that an other process needs the buffer 
for a next update and can avoid the read!'

Data compression and Key compression are _always_ goodness and more
often than not _save_ CPU time because there are less bytes to read
in, less bytes to skip over. Low or Negative compressions are the
exceptions but those are rare. Index compression stops RMS from being
able to binary search index buckets and thus is a tougher choice.
IMHO smallish keys ( < 20 chars ) should have index compression disabled.
Big keys ( > 50 chars ) may well need the compression to avoid
excessive bucket sizes and/or deep indeces.

Thanks for bringing this up,   +--------------------------------------+
                               | All opinions expressed are mine, and |
Hein van den Heuvel,  Digital  | may not reflect those of my employer |
vandenheuvel@eps.enet.dec.com  +--------------------------------------+