Conference iosg::all-in-1_v30

738.0. "DECtrace requests for ALL-IN-1 instrumentation" by DATABS::HEATH () Thu May 21 1992 15:09

Hi,

    I've compiled this list of 'requirements' for ALL-IN-1 with respect to 
    the ALL-IN-1 DECtrace instrumentation.  DECtrace is an event based 
    logging facility that is used by ALL-IN-1 to log meter events.  This list 
    is a compilation of a number of requests DECtrace has received from the 
    field.  I wanted to put the list here so that any ALL-IN-1 users that 
    have used DECtrace may add comments as well.  

Thanks
Dave Heath

-------------------------------------------------------------------------------
	1) Check the DECtrace event collection flags prior to logging an event.
	   If the flag is not set, then ALL-IN-1 does not need to log the 
	   event as DECtrace will ignore it anyway.  This will both save the
	   overhead costs of making an unnecessary call to an EXEC mode 
	   routine as well as it should allow ALL-IN-1 to do away with the 
	   OA$MET_METER_SWITCH logical test for DECtrace collections. 
           (See Number 3 below)

	2) Do not log a message to the user if any unexpected status is 
	   returned from DECtrace.  If the status is an unexpected DECtrace
	   error it will be logged by DECtrace to the DECtrace history database.
	   Currently if the OA$MET_METER_SWITCH is set to 4 but the user is 
	   unable to log data because no collection is active, no access 
	   privilege to the data file, etc. then a 'DECtrace is Disabled'
	   error message is displayed.  This particular case is solved by 
	   requirment #1, but the general case of not logging DECtrace status 
	   codes to the user is also prefered.  This way if we add a new
	   status code, it will not effect ALL-IN-1 unless you needed to
	   check for it explicitly.

	3) Do not require the OA$MET_METER_SWITCH logical to be set to 4 
	   in order for a process to register (make the EPC$INIT call.)  This
	   way if logging is enabled later on, then a process that has already
	   registered ALL-IN-1 will be able to log the data.  Again, this may
	   go away if requirement #1 is implemented.  Another advantage to 
           this is that both DECtrace meter logging and other ALL-IN-1 logging 
           mechanisms may be used concurrently.

        4) Fill in all remaining non logged code paths.  Customers do not get 
	   a full picture of the ALL-IN-1 usage as much of it is not logged so 
	   they are unable to determine the full resource consumption of 
	   ALL-IN-1 processes at their site.  It might be sufficient to start 
	   with a generic ALL-IN-1 overhead event that the currently non-logged
	   data can be logged as.  Then in future versions add lower levels of
	   granularity based on customer feedback.

	5) The current instrumentation logs a start event at the beginning of an
	   ALL-IN-1 function and an end event at the end.  In cases where user's
	   input is required, the elapsed time for the event includes the user's
	   think time. We have customers that have requested that the events
	   do not include the user's input time as it makes the elapsed time 
	   meaningless.  This is particularly important in making capacity planning
	   decisions.	   
	   Below is some feedback DECtrace received from an ALL-IN-1 site:

   What we're doing right now is boiling down data collected from the
   OALOGGER. We have a little fortran program that sifts through the 
   OALOGGER data and it uses everything *Without* the message id of 11F8343'X.
   That gives us function data with start and stop times. 

   Essentially, if ALL-IN-1 can log it, it then it should be logged to 
   DECtrace as well.

   What we're looking at for response time is, the time from hitting the 
   <return> at any edit function to the time they we can hit the first editor 
   keystroke (more or less). The time from the hitting the <return> on an RN 
   function to the time the first page of the document is displayed, The time 
   it takes any following pages to display after hitting the <return> or 
   <next_screen> keys. The time to get back to any menu or form after hitting 
   a <KP0>. We need some instrumentation in the US and TM menu areas. Having 
   the DT functions instrumented wouldn't hurt either.  

   Basically, what we need is response times on "transactions" where , when
   ALL-IN-1 is loaded, a user selects a menu option and ends up perceiving a
   "wait" period before they can hit another *Keystroke*, whether it is
   entering/exiting the editor or entering/exiting a form. What happens while
   they are in the editor or filling out a form is not that important.
   Can you put DECtrace metering around the code that reads in FMS forms and 
   presents them?  What the client here is more concerned with is not "How is 
   ALL-IN-1 performing internally", but how is it perceived to be performing 
   by the user. After all they're the ones who count because it's their 
   department footing the bill. 

	5) Modify the ALL-IN-1 installation procedure to call the DECtrace
	   insert definition kitinstal compliant callback 
	   EPC$VMSINSTAL_CALLBACK to store the ALL-IN-1 facility definition.
	   This will insert the ALL-IN-1 facility definition into the 
	   DECtrace library of facility definitions (SYS$SHARE:EPC$FACILITY.TLB)
	   and also insert it into the DECtrace administration database for 
	   immediate use if DECtrace and Rdb are both installed and running on 
	   the system ALL-IN-1 is being installed on.  I think this might be
	   done for version 3.0 already.

        6) Utilize a new DECtrace V1.2 feature which allows ALL-IN-1 events to
	   be 'tagged' in other events logged by other facilities.  Basically
	   a special CROSS_FACILITY item can be set by ALL-IN-1 and this item
	   value will then automatically be logged by other facilities as
	   well.  End users can then determine in a hierarchical fashion which
	   events were generated by other facilities from within a specific 
	   ALL-IN-1 event.
    
               

    
    
       Perhaps noters could reply here with any comments on the adequacy of 
       the way ALL-IN-1 collects performance metrics - either through DECtrace 
       or Metering.
    
       Does anyone use Metering/DECtrace. Does it provide them with what they 
       want. Where is it found to be most inadequate and what would most 
       improve it.
    
       Many of the resources used within ALL-IN-1 are not attributed to 
       particular events but disappear within the cracks. Has anyone found 
       this to be a particular problem.
    
       			Mark