X-Acknowledge-To: <FCLA@NERVM>
Newsgroups: bit.listserv.notis-l
Date:         Wed, 8 Apr 1992 17:51:57 EST
From:         "Mark Hinnebusch, FCLA" <FCLA@NERVM.BITNET>
Subject:      Re: 5.0 resource consumption

On Wed, 8 Apr 1992 10:55:30 CDT <HSAMUELS@UA1VM> said:
>We are a site that has experienced a 2.5 multiplication factor in resource
>consumption in moving from LMS 4.6.1 and the BRS KWB to LMS 5.0.1 and
>NOTISearch...
>
>If you're not using NOTIS OPAC or NOTISearch then you probably won't see
>any more impact on your resource consumption than you've already experienced.
>
We are running NOTIS 5.0.2 in a pre-production test environment and are
experiencing the same 2.5 multiplication factor in the OPAC.  We are not
running NOTISearch so that is not the cause of the increase, at least at
FCLA.  Also, we already had the MHI index in our 4.6 OPAC so that also
is not a factor in the increase.  We have done some analysis and believe
the following are the areas that need to be addressed:

1. Every VSAM I/O requires an EXEC CICS LINK to LIF900P.  This is one
   of the places where the attempt at structured programming really
   gets in the way of efficiency.  An alternative that we are
   looking at is replacing the subroutine that exists in virtually
   every OPAC program to pass control to LIF900P to a macro that does
   the appropriate EXEC CICS GET, EXEC CICS PUT, etc.  In this way,
   the code remains structured but the LINK is avoided.

2. Heavy I/O on the OPAC LCR records.  While 5.0.2 is a significant
   inmprovement over 5.0.1 in this area, there is still a considerable
   amount of I/O against these records.  We are looking at writing a
   SIT program to load these records into memory above the line and
   to anchor them, perhaps in the CSA or perhaps in a temp storage
   queue.  This avoids the repetitive I/O at the cost of memory.  While
   this is appropriate for our situation, it may not be for the smaller
   system which may be memory constrained.  The optimal situation would
   be to have this configurable.  Even if only the OPAC definition
   record were done this way, at a very small cost in memory, a very
   considerable amount of I/O might be avoidable.

3. Creation of the guide requires two passes through the result set.
   This not only allows generation of the guide but also provides a
   very quick mechanism for moving deeply into the result set.  We are
   looking at a modified algorithm that creates essentially the same
   set of "directory" temp storage items but in only one pass.  The
   code is somewhat complex but I believe it can be done.

4. Building the short display from all records.  This is one area where
   the cost is directly due to increased function.  If you want a brief
   view, then you must read the bibliographic record, the copy holdings
   record, all MFHL records, the order record and all item records in
   order to build that single screen.  This has increased the average
   number of I/Os in a display transaction from one in 4.6 to 8 in 5.0.
   One could argue that the user would have gone on in 4.6 to display
   additional screens and that the aggregate set of transactions in 4.6
   needed to display the same data would be about the same.  As this is
   desirable new function, we do not plan to make any changes in this
   area.

Please note that we are only undertaking this work because we are now
running about 19 million transactions each month and the additional
resources would bring us to our knees.  Figuring out what costs what
in an online system is an inexact science at best.  We have isolated
the above but could be completely wrong, in which case we will have
expendied significant effort for little payback.

Mark Hinnebusch
Assistant Director, Florida Center for Library Automation
Suite 320, 2002 N.W. 13th Street, Gainesville, FL  32609
Voice: (904) 392-9020    FAX: (904) 392-9185
BITNET: FCLMTH@NERVM  INTERNET: FCLMTH@NERVM.NERDC.UFL.EDU
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU