Conference iosg::all-in-1_v30

    Try looking in: SAGE::ISA-PERFORMANCE-GROUP
     Moderator:     MRKTNG::SLATER    
    
    They produce a lovely document that details everything we know about
    ALL-IN-1 performance, how it is measured, and how we size systems to
    run ALL-IN-1.
    
    This document is also orderable from VTX - Corporate, Marketing, BOSS.

    Hello,
    
    The ALL-IN-1 performance guide is excellent, but be carefull.
    
    The tables specifying the number of user per system are related to a
    mix of activities. 
    
    In Holland we ran into big problems when we (DEC) sold a system with a
    garanteed number of users, as specified in the Guide. At the end we had
    to give them a 6000 CPU for free....
    
    This customer used ALL-IN-1 with SFCP for heavy WPS-PLUS wordprocessing
    (more than 100 character per minute), they had large file cabinets
    (thousands of documents) and they did a lot of shared folder copies.
    
    The actual number of users was half of what the guide specified.
    
    Regards,
    
    Jan
    
    

Please review the Performance and Configuration Guide.  It will help
you set up the terminology and process.  We've got lots of data
to back this up, but as Jan pointed out in .-1, these tests are done
in a "clean" laboratory environment, and can't be used as anything
more than a starting point.  We're always looking to improve the
workloads we use, and input from the field is essential.  

I think that in the future (now?) Digital will begin to guarantee
performance, as long as we can set the terms and conditions.  For instance, 
since we bear the risk, the customer will have to pay more than list price.
Also, a comprehensive performance management and capacity planning service
will be a prerequisite.  These ideas are seriously being considered, and 
approached cautiously.

As far as tools go, there are several tools that can be used to monitor
and track performance.  I recommend that you look at the ALL-IN-1 Performance
Reports product currently in field test.  This product uses the DECtrace
extentions to Meters to capture performance statistics.  While it does
not capture response time directly, and though there are a few holes
in the strategy, it does releate elapsed time to specific ALL-IN-1
functions.  I'll move the field test announcement into this conference 
directly.

Consider also DECps and DECcp as tools to collect response time.  There are 
also third party tools that can be used to track interactive response time.
However, none of these tools allow you to relate response time back to specific 
functions in ALL-IN-1.

The key to reducing risk in selling this, or any solution, is detailed workload
characterization up front, clearly stated service level objectives, and
rigorous performance management during the early stages of implementation.
Of course, all of this is easier said than done.

Jan, can you provide more detail on how the system sizing was carried out
(what info was available, what assumptions made, what service level objectives,
what services proposed)?  What was the size of the sale?  Was the 6000 give
away a single board (not bad), or a complete system (not good)?

Regards,

Marc

                <<< IOSG::LIB0:[NOTES$LIBRARY]ALL-IN-1.NOTE;2 >>>
                     -< ALL-IN-1 (tm) Support Conference >-
================================================================================
Note 113.0           Performance Guarantees and Remedies ...          No replies
CAADC::RASLAWSKI "W. Jon Raslawski @CPO, Chicago"    26 lines  27-FEB-1992 01:59
--------------------------------------------------------------------------------
    I've just been assigned a "show stopper" item as part of a contract with a
    local school district.  The consultant working for the customer would like
    us to provide some level of Performance Guarantee for the ALL-IN-1 product.

    Before I continue, the following is my configuration:

    	DUAL HOST VAX 4000 Model 300 rack-mounted
    	64Kb ISDN Extended LAT links to other locations (11)
    	64MB of memory for each CPU
    	1 - RF72
    	4 - RF35E

    The latest copy of the performance guide lists a dual-host 4000-300 with
    96MB memory each and 8 RF72's can handle about 248 interactive users.

    The customer for said us 200 users as a worst case scenerio figure.  He has 
    since revised his number down to between 70 - 120.

    What type of performance metrics should I recommend and can I "guarantee"
    this performance ???

    Additionally, when can Digital give them is we do not meet this performance 
    metric ???  (assuming $ALLIN1/NOCUSTOM)

    Thanks,
    Jon ...
    

    Tony, I apologize for all this confusion.  I really am a better Notes
    users then it appears; this is what I get for trying to use PAVN.
    
    Marc, thank you for your response.  I agree with what you have stated. 
    I told the account manager that if this customer wants performance
    guarantees they are going to have to pay !!!!  (eg: Performance and
    Capacity Planning Services or OUTSOURCING whatever ...)
    
    Thank you all again for your ideas.
    Jon ...
    
    PS: A special thanks to Russ Rogers for providing me with additional info

    I have been asked by my customer to evaluate the usage of standard
    ALL-IN-1 (no Rdb/SRA) can handle the following files:
    	850K records 150 bytes each.
    	2M records, 150 bytes each.
    The files will be loaded contigously on the file (on 2GB disks).
    
    The data would be static after being loaded from an i*m mainframe. 
    Printing/reading individual records and finding the records to print
    would be all they'd be doing.  We're talking 10 users doing this.
    
    The current system is loaded (user-wise), VAX 4000-300 with 96 MB memory.
    170 users doing mostly ALL-IN-1, Lotus, etc really bog this one down at
    times.  So they plan to upgrade and add 80 more users (doing mail, etc).
    
    They plan to add another VAX 4000-300, but are considering making it a
    3 node VAX 4000-500 system, with 256MB on each node.
    
    I think the additional load on the system would be minimal, but I am
    unsure of the capability of using ALL-IN-1/RMS to handle the lookups.
    Will keyed lookups take minutes, seconds, be relatively unnoticed?
    
    Thanks in advance...
Dan

    Not really an ALL-IN-1 question....?
    
    ALL-IN-1 uses RMS to do keyed lookups to Indexed Sequential files. The
    performance of RMS keyed lokups is excellent.
    
    Where ALL-IN-1 comes in is to try to make things a little easier for
    the user... so that instead of specifying the excat key, the user can
    enter just the  first few characters of the  key, and ALL-IN-1 can then
    search for  all records that match the characters  entered....
    If the user enters just one character, then it could take sometime to
    match if there are thousands or even millions of records with the same
    first letter in the key....

    Thanks, Chris, for your quick response... 

    I had a feeling this was more of an RMS tuning question (which is why I
    mentioned Rdb).  The customer is not wanting to buy another software
    product if they can avoid it, but they are very interested in buying more
    CPU, memory, and disk space.  If I were to recommend an upgrade to them
    JUST for these users I'd be all wet!  I personally think the additional 80
    users (who are doing who knows what) will be bogging down the system more
    than these 10.
    	1. What's the CPU and memory requirements for accessign a file like
    	   this via ALL-IN-1?
    	2. How much memory would I need to put these files in global buffers
    	   (too much ;*)?
    	3. The customer is really just interested in making sure they've got a
    	   good (valid) configuration order going.

    The primary key will be 16 characters long:
     	 4 - vendor number
    	10 - invoice number
    	 2 - line item number

    The vendor number will be completely filled in either directly by the user
    or by a lookup on a separate data file (allowing the search to take place
    by vendor name).  All access will be by primary key beginning (or gts) the
    vendor number.

    Bottom line: how much hardware (CPU, memory) do we have to throw at this
    problem to get *decent* performance doing this? I think a response in less
    than 2 minutes would be tolerable to the end-users, with 30-second response
    a feeling like a great success.

    The customer is inquiring what access is like today on the ibm 3090.  I'd
    like to compare numbers when I get them.  Is there some other notes
    conference I should ask these questions (not belittling the responses so
    far)?  

    Thanks in advance (and so far)...
Dan

    If it takes as long as 2 minutes to respond, you've got real problems.
    
    RMS keyed access is pretty fast (given a bit of file tuning, which is
    documented in the VMS manuals), no matter how big the files.
    
    The most important thing is to make sure that your application does do
    keyed access. ALL-IN-1 is very obliging, and will get your record for
    you even if, for some reason, it can't do keyed access. But it would
    take a l-o-n-g time with your file sizes.
    
    There are numerous notes about this in here, the old conference and in
    the ALL-IN-1 application programming books. Basically, you must only
    use the operators EQS (exactly equals) and BEGINNING when looking up
    records; you must (obviously) use a field which is an RMS key, and (if
    the key isn't the primary key) you must specify the key name in exactly
    the same form (including case) that it's specified in the RMS File
    Description Language. Also avoid complex Boolean expressions.
    
    D.

    
    
       You could ask this question in BULOVA::VAX-RMS.
    
       You can use EDIT/FDL to find out how many index levels you will get for 
       your file. For the 2 million record file with a bucket size of 4, there 
       will be 3 index levels so to get a record will take 4 I/Os. With enough 
       buffers this will be reduced further. In other words it should be 
       pretty quick to get a record - providing that is that you are using the 
       primary key and you are not doing sequential searches.
    
       Your memory consumption should not be too heavy either. The usual 
       advice with global buffers is to have enough to hold the index and a 
       few data buckets in memory - and not go over 400. 
    
       				Mark