Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!rutgers!ucla-cs!zen!ucbvax!DRCVAX.ARPA!graham
From: graham@DRCVAX.ARPA
Newsgroups: comp.os.vms
Subject: RE: IMPROVING RESPONSE TIME ON A MICROVAX II
Message-ID: <8707221511.AA00852@ucbvax.Berkeley.EDU>
Date: Tue, 21-Jul-87 08:19:00 EDT
Article-I.D.: ucbvax.8707221511.AA00852
Posted: Tue Jul 21 08:19:00 1987
Date-Received: Fri, 24-Jul-87 04:47:47 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: 
Distribution: world
Organization: The ARPA Internet
Lines: 24

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. 

------