From:	CSBVAX::MRGATE!nagy%warner.hepnet@LBL.Gov@SMTP 14-MAY-1988 20:28
To:	ARISIA::EVERHART
Subj:	RE: RMS info regarding multibuffer count requested


Received: from LBL.Gov by KL.SRI.COM with TCP; Sat 7 May 88 07:03:50-PDT
Received: from warner.hepnet by LBL.Gov with VMSmail ;
	Sat, 7 May 88 07:03:04 PDT
Date:    Sat, 7 May 88 07:03:04 PDT
From:     nagy%warner.hepnet@LBL.Gov (Frank J. Nagy, VAX Wizard & Guru)
Message-Id: <880507070304.20806595@LBL.Gov>
Subject: RE: RMS info regarding multibuffer count requested
To:       Info-VAX@kl.sri.com
X-ST-Vmsmail-To: INFO_VAX

> Although I have read the "Guide to VAX/VMS File Applications" manual, I am
> still unclear about the use of the multibuffer count.
> I shall pose my questions below, but any general comments on this topic,
> helpful hints etc. are greatly appreciated.
> My application may or may not open several indexed (or positional) files
> at execution time.  Should I specify the number of buffers at this time,
> or use the value which can be set from DCL with the command
>     $ set rms/indexed/buffers=n
> Furthermore, does the above cause n more buffers to be allocated for
> each file I open (this seems like a Bad Thing in an arbitrary multi-user
> environment).
     
Normal buffers are allocated in your process virtual address space.  To be
effective, they should be in your working set.  In general, increasing the
number of buffers is not a "Bad Thing" since:
	- the increase in memory requirements is usually quite modest
	  (on the order of 20-100 pages usually).
	- going from 1 buffer to 2 buffers for sequential file access will
	  usually result in a substantial performance improvement for any
	  applications which do even a modest amount of disk I/O since now
	  the read-ahead and write-behind algorithms can overlap processing
	  and disk I/O.
on any normal (i.e., not memory starved) system, the "disadvantages" are
heavily outweighed by the performance improvements.  On the other hand,
going from 2 buffers to 3 or 4 has little extra benefit for sequential
files under normal (almost always) conditions.

In the above, I'm speaking about sequential files mostly (that's what I have
most experience using).  Indexed files do not use buffers in quite the same
way.  I seem to remember a Digital talk at a DECUS Symposium which mentioned
that indexed file performance can be improved by more than 2 buffers if
a large portion of the key index buckets can be held in the buffers with
only 1 or 2 buffers used for data buckets.  This reduces indexed lookups
to memory operations (instead of disk I/Os) which is what improves the
performance.

So, I guess that for indexed files it sort of depends on your application,
its environment and the file.  On extra note is that if you are sharing
access to the indexed file, then global buffers (which count against the
pagefile space) can help things along.

> Alternatively, if I specify this number in the RAB, is it cumulative? That is,
> does the number of buffers continue to mount as more files are opened.
     
What you specify in your RAB overrides what you specify with SET RMS
which overrides the system defaults (set via SYSGEN parameters or
SET RMS/SYSTEM).  So you can tune this on a fileopen-by-fileopen basis.
But in general, the answer to your question is YES.

> Should I have some upper limit for each user coded into my program?
     
Depends upon your application.

BTW: The system's I help manage are setup with a system default of 2
buffers for all  sequential file types AND a multiblock count (number
of disk blocks/buffer) of 32.  We have lots of memory on our MicroVAXes
and so we tuned for more performance at the expense of using more memory.

= Frank J. Nagy   "VAX Guru & Wizard"
= Fermilab Research Division EED/Controls
= HEPNET: WARNER::NAGY (43198::NAGY) or FNAL::NAGY (43009::NAGY)
= BitNet: NAGY@FNAL
= USnail: Fermilab POB 500 MS/220 Batavia, IL 60510