Conference vaxuum::document_ft

    I've got Document running on a VS II, VS 2000 (both standalone) 
    as well as LAVC with 750 and 6xVS2000. (VS2000 with LN03 and DOCUMENT
    makes a great machine to take to shows/conferences for last minute
    presentation overheads!)

    In all cases I'm running with large quotas for eash account in the
    SYSUAF.DAT file and large working sets etc. I've been pretty successful
    at using VPA (VAX Performance Advisor) to help tune these systems.
    At least it seems so... One suggestion I have (haven't had time
    to implement myself due to small event called DECworld)) is to use
    DFS (distrib File System) to keep only one copy of the DOC files
    -- can't see any problems with this and makes system management
    much easier, also cuts down disk space req.
    
    Michael  

Tara,
	Here, in Maynard, we insist on our writers using the BATDOC command.  
This submits a batch job to a que that has a lower priority than interactive 
jobs.  We also limit the number of jobs to two. (One on each of our 11/785's.)
We have 25 to 30 people using DOCUMENT but I've never seen the batch que with
more than one or two jobs pending.  (Except one time when one 11/785 was down.)

	Wayne

    If you have more than 1 or 2 jobs at a time, my main suggestion 
    is to insist that your users use the /BATCH qualifier. In fact, 
    I recommend you create a queue at base priority 2 or 3 (not 4) 
    specifically for DOCUMENT use.
    
    To make it easier to use, I also recommend you create a command
    file and define a foreign symbol to replace the DOCUMENT command
    with DOCUMENT/BATCH and the appropriate attributes. Otherwise users 
    find it too difficult to use batch mode. For example:
    
    	$ DOCUMENT/BATCH=(QUE=sdml_batch, notify, noprint)

    --Andrew

    We upgraded from a 785 to an 8700. DOCUMENT is CPU-hungry, so the
    only real way to improve performance is to get a more powerful CPU.
    We hope to upgrade to an 8800 when VMS V5 is available. 
    
    Marty
    

    THere is not much tuning that can be done, because DOCUMENT
    is asking for the cpu most of the time.  It's I/O is minimal.
    It basically just wants to have the resources to "think."
    
    We have an item called performance improvement on the wish list.
    THe main thrust of that improvement will be to make DOCUMENT
    think faster.
    
    Putting DOCUMENT at a lower priority by running it in a lower
    priority batch queue doesn't make it run any faster, but it does
    let the rest of the users run at the normal priority of 4 without
    too much interference.
    
    bill
    

    Re Document on dual processor machines.
    
    In some very rough monitoring I looked at of Document
    running on an 8300, I found that it performed almost
    ideally - using the attached processor most of the
    time. This was on V4.x of VMS.
    
    So you do not have to wait for V5 and SMP.

    I was under the impression that in order to wring the promised MIPS
    out of a dual processor machine you had to have synchnronous 
    multiprocessing. But it's good news if you can get significant 
    performance improvement even without SMP.
    
    Marty

    >out of a dual processor machine you had to have synchnronous 
    >multiprocessing. 

    A nit- SMP stands for SYMMETRIC MULTIPROCESS and not SYNCHRONOUS
    multiprocessing