[comp.os.vms] IMPROVING RESPONSE TIME ON A MICROVAX II

dfile@ecsvax.UUCP (Dean File) (07/20/87)

Although a VMS neophyte, I have just rewritten an application which I
had developed earlier for a DEC PRO350 (n BASIC-PLUS-2) to be run on
a MicroVAX II (in VAX BASIC).  The application itself is just a user-
friendly shell that collects inputs from the user (via FMS forms) and
executes retrievals of textual data from RMS files (via 'callable'
Datatrieve).  Our 'textual' data files are not large, but the record
sizes are quite large, with fields ranging from 3 to 600 bytes, the
largest record size being 3214 bytes (although there are currently
only 60 records in that file).  The retrievals perform sequential
string-matching searches, and the users cannot alter or add to the
files themselves.

When a user's retrieval criteria result in data being found, that data
is then written to a disk file, then displayed to the user in EDT, also
called from the program.  (This is necessary because, if the data were
displayed using calls to Datatrieve, it would 'scroll past' on the 
screen, and the user could not 'back up' to parts of the data display
that had scrolled off the screen.  The EDT method allows the user full
cursor control when viewing the data.)  The user may also choose to 
print the data display.

One of the chief reasons for moving this application to the VAX hardware
was the desire to improve the response time for individual searches.
What took 30-45 seconds on a PRO350 now takes 5-12 seconds on the MicroVAX.
We feel that this can be improved even more.

Questions:

(1) The MicroVAX we have (actually a VAXstation II/GPX that we are using as
    if it were a MicroVAX II) has the full 16MB of memory.  I have been able
    to determine that most of our present response-time delay is due to
    disk I/O (we have RD series disks) rather than CPU usage.  Can I set up
    a 'virtual disk' in memory to hold a copy of the data file being
    searched, to write the display to, or both.  (It shouldn't take more than
    1MB even for both.)

(2) My current model for getting Datatrieve to do the retrievals is:
    FOR (rse) PRINT (specified fields).  Would the model:
    FIND (rse); FOR ALL CURRENT PRINT (specified fields) be faster?
    (The latter model has other advantages for us, and we will probably use
    it regardless of the speed question.)

(3) Are there VMS utilities, system parameters, etc. that I can use to try
    to decrease the application's response time?  (I've tried changing
    WSDEFAULT, -EXTENT, and -QUOTA, but this doesn't seem to have an
    impact.)

(4) Would using rdb (rather than Datatrieve) be more efficient, assuming
    some of our data fields will still have to be long ones?  (I wish it
    were otherwise, but the data formats are faculty-mandated.)

When implemented, the MicroVAX will need to be able to support 16 users
running this application concurrently (we have the license); however, aside
from my occasional system management tasks, it will be exclusively dedicated
to this application.  Users will access the application via VT220 terminals
or PCs attached to terminal servers on an ethernet.  Thus,

(5) Will there be significant degradation of response time due to increasing
    the number of concurrent users?  (True 'concurrency' will be hard to
    guage, since much of each user's logged-on time will be spent filling
    in the forms, which is neither CPU nor I/O-intensive.)

Since I've been working with VMS less than a month, please don't hesitate
to recommend the obvious if it applies to my concerns.

Thanks in advance for all suggestions.

______________________________________
Dean File
Laboratory for Computing and Cognition
UNC School of Medicine
Chapel Hill, NC
dfile@ecsvax.UUCP

graham@DRCVAX.ARPA (07/21/87)

Probably the greatest item affecting the response time for you is 
Datatrieve itself.  Neither Datatrieve nor Rdb were designed for long text 
record processing.  They do not function optimally in this mode.  Because 
of the string matching you are doing, there is little that can be done to 
change the number of disk I/O.  You might try distributing the data files 
on different disks, thus minimizing the I/O to any one disk.

The real slowdown place is in the activation of Datatrieve.  Because of the 
way Datatrieve works, with several different files being accessed each time
it is activated, it starts slowly, and that's pretty fixed in concrete. 

Good Luck,


Hackito, ergo sum.          

Dan Graham, Dynamics Research Corporation, (617) 475-9090 Ext. 2352
GRAHAM@DRCVAX.ARPA

Hoc est meum hackum.  Ideas and opinions are mine, not my employers.  In
fact, my employer barely claims to know me at all.  I make no claim to
sanity in any form or on any level. 

------