X-Envelope-to: CDROMLAN@IDBSU.IDBSU.EDU
MIME-version: 1.0
Content-type: TEXT/PLAIN
Content-transfer-encoding: 7BIT
Posting-date: 25 Jan 1993 15:38:00 -0500 (EST)
Importance: normal
Priority: non-urgent
X-Hop-count: 2
A1-type: MAIL
Newsgroups: bit.listserv.cdromlan
Date:         Mon, 25 Jan 1993 15:08:00 -0500
              <CDROMLAN@IDBSU.BITNET>
From:         Linda.Newman@UC.EDU
Subject:      Re: Proquest 4.0 Searchware

We have conducted some concurrent user tests on our network (CBIS/Novell)
of the 4.0 Proquest Searchware, and have experienced some problems.
I'd like to hear if anyone else has done a deliberate concurrent user
test, what your results were like, and what your network is like.

Our tests have been with ABI/Inform, installed on a CBIS 386 Server with
8 mb of RAM.   Our workstations vary.  I have noticed an improvement in
performance on a 386 with DOS 5.0 and about 590K of application RAM
available, versus a 386/SX with DOS 4.0 (and no other memory manager
like QEMM) and 509K available.  However, the application still runs on
that lower-powered machine.  We haven't tried to run it on a networked
XT or 286 yet.

However, our real problem occurs with concurrent use.  In our test,
when we increased to 5 or 6 users, searches which would otherwise
work with acceptable response time, no matter how ridiculously general
(ex. 'quality circles and management') started taking 8 to 10 minutes.
In at least two instances, several workstations received 'file error'
messages generated by the ProQuest interface, and at that point, the
CBIS file server had to be re-booted, because users of non-UMI products on our
network started experiencing problems, and it appeared that something
(cache memory?) on the CBIS server had become trashed, as a result
of our user test with the UMI software.   Oddly, the file error
messages from the UMI software implied that the workstations had run
out of room on the local C drive, which was where the temporary files
were being routed, but 30 to 40 mb of space was available on all 6
workstations being used for the test.  It appeared that about 15 users
had active connections to that CBIS server the second time it was trashed.

In our test, we were cueing the testers so that all 5 or 6 hit the
enter key at the same time, with the same search.  When we use
the previous version of the ProQuest software, having users do the same
search speeds up results, whereas we see significant slow-downs when
we get up to 6 users doing different searches, all general.
Admittedly, our tests placed more demand on the product than one would
expect with a typical 6 to 8 concurrent users, who would not really be
entering their searches at the same time, but we are still concerned.

We have not yet made this software available to the public, but will
be doing so soon, and I'll be watching to see if we have to start
re-booting our CBIS servers much more frequently when users are using
UMI products.

We have plans within the next month to upgrade all workstations which
are 386/SX or better to DOS 5.0 or QEMM, but we don't have control
over remote users on campus Novell LANS not in our Libraries.  We also
have plans to upgrade our two CBIS servers to 486's with 16mb of RAM.
I will post a message to this list with the results, if, after making
those upgrades, we do another concurrent use test of the ProQuest 4.0
software, or if actual production use of the new software yields
different results than our tests.

I'd be very interested in hearing about other sites' experiences.

  +------------------------------------------------------------------+
  | Linda Newman               |    BITNET: LNEWMAN@UCBEH            |
  | University of Cincinnati   |  INTERNET: LNEWMAN@UCBEH.SAN.UC.EDU |
  | Library Systems Office     |       FAX: (513)556-2161            |
  | Cincinnati, OH 45221-0033  |     VOICE: (513)556-1441            |
  +------------------------------------------------------------------+
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU