ADMINISTERING
The Administration Process records statistics to help you monitor the request processing activity of the administration process tasks.
All administration process requests scheduled for processing originate from the Administration Requests database (ADMIN4.NSF). Requests are regularly retrieved from ADMIN4.NSF and temporarily stored in various ID tables, depending on the type and schedule of the request. They remain in the ID table until it is time to process specific requests based on schedule. Statistics are maintained for each of these ID tables to provide feedback on the ID table's usage as well as an indication of the Administration Process workload. All of the ID tables referred to by these statistics contain the NoteID of the administration process request that is to be processed.
Once the administration requests have been properly categorized into the appropriate ID tables, they are available for processing. At the appropriate scheduled time they will be placed onto one of a number of available message queues. Similar to statistics maintained for ID tables, statistics are maintained for each message queue to provide feedback on message queue usage.
A third group of statistics is also provided to provide feedback on request processing times for Administration Process batched requests.
These statistics are separated into the following three areas:
Table 1. Statistics for Administration Process task
These statistics are provided to represent an indication of Administration Process activity. The statistics do not really provide a method to monitor progress. For example, reviewing the statistics and noticing that there are a large number of "Waiting" statistics in any one of the message queues would indicate that all of the request processing threads are busy running long-running requests, and some reconfiguration of the Administration Process may be necessary. For example, you may need to add additional processing threads or configure dedicated threads.
Collection tables
Collection tables are separated by schedule time and then by request types. These ID tables contain the administration process request's NoteID for the request. For each NoteID added to a collection table, a TotalCount statistic is updated. TotalCount indicates the total number of NoteIDs that have ever been stored in the collection table. For example,
ADMINP.RequestIdTables.CollectionTables.Daily.DirectoryManyDoc.TotalCount = 40
A second statistic is also maintained for each ID table which represents the number of NoteIDs currently stored in the table "Waiting."
The following example shows the potential statistics in the Collection section of Request ID Table monitoring. The example includes only Immediate and Interval requests.
AllServer
DirectoryOneDoc
DirectoryManyDoc
ModifyACL
ModifyDesignElement
ModifyUnreadList
ModifyReaderAuthor
ModifyPersonDoc
ADMINP.RequestIdTables.CollectionTables.Immediate.DirectoryOneDoc.Waiting = 0
ADMINP.RequestIdTables.CollectionTables.Interval.DirectoryOneDoc.TotalCount = 1
BatchRequest tables
Collection tables transition to another group of ID tables, BatchRequest ID tables, when it is time to process that schedule of requests. BatchRequest ID tables contain the group of NoteIDs that will be handled by the batch processing request. These tables are used to group batched requests or to group requests with a common schedule type. For BatchRequest ID tables, the table remains as is until the associated batch request is executing and empties the table. An example of the BatchRequest statistic is shown here:
ADMINP.RequestIdTables.BatchRequest
The NoteIDs stored in the BatchedRequest ID table are a special case. A triggering request is included in one of the PrimaryTables to start the batch of requests. The actual request processing then refers to the appropriate BatchRequest table for further information about which requests need to be processed.
SecondaryRequest tables
There is also a group of ID tables called SecondaryRequest tables. SecondaryRequest tables are collection areas for less common schedule types such as timed requests, third party requests, quick retry requests, and others. An example of the SecondaryRequest statistic is shown here
ADMINP.RequestIdTables.SecondaryRequest
PrimaryRequest tables
With the exception of the requests stored in the BatchRequest tables, all requests eventually flow through the PrimaryRequest tables which are the last short term storage location for the request prior to being scheduled for processing. An example of the PrimaryRequest statistic is shown here:
ADMINP.RequestIdTables.PrimaryRequest
Table 2. Primary request tables
ADMINP.RequestIdTables.PrimaryRequest.Immediate
ADMINP.RequestIdTables.PrimaryRequest.Interval
ADMINP.RequestIdTables.PrimaryRequest.General
Each NoteID is removed from the PrimaryRequest Tables and placed in the next phase of the request schedule. Requests are retrieved from the Immediate table first, then the Interval table and finally the General table. This ensures that the urgency of the request scheduling is maintained. Once retrieved, the request is packaged and stored in the Request Message Queues.
Request Message Queues
Request Message Queues feed the request processing threads. When there is a request to process, the dispatching thread places a request message on the message queue and signals the request processing thread that there is work to be performed. The request processing thread accepts the message and processes the request accordingly. As messages are placed on the message queue a statistic is updated and a time stamp is recorded. As messages are removed from the message queue the statistic is also updated and the time stamp is used to determine the length of time the message was queued. There are four message queues being monitored by the processing threads; Immediate, Interval, General Purpose, and Poll.
The Immediate message queue only exists if special purpose threads have been configured to handle Immediate schedule requests. When the Immediate message queue exists, all requests targeted for immediate scheduling are placed on this thread. Any idle processing thread will check the immediate message queue before moving on to the next message queue.
The Interval message queue only exists if special purpose threads have been configured to handle Interval schedule requests. When the Interval message queue exists, all requests targeted for Interval scheduling are placed on this thread. Any idle processing thread will check the immediate message queue (if it exists), and then the interval message queue for requests to process.
The General purpose message queues handle any scheduling type, but if special purpose threads are in place the general purpose message queue is the last queue to check when looking for work to perform.
Examples of ReqMsgQue statistics from the Domino® server console:
ADMINP.ReqMsgQueue.Interval.AverageWaitTime = 0 Hours 0 Minutes 0 Seconds
ADMINP.ReqMsgQueue.Interval.TotalCount = 1
ADMINP.ReqMsgQueue.Interval.Waiting = 0
Once the request has been retrieved for processing, statistics are maintained for the long running batch requests.
Batch Request Processing
For each batch request, a statistic is maintained to monitor the maximum time to process the batch, and the average time to processes the batch.
Examples with processing time statistic from the Domino server console:
ADMINP.BatchReqProcessing.ModACL.AverageProcTime = 0 Hours 0 Minutes 15 Seconds
ADMINP.BatchReqProcessing.ModACL.MaxProcTime = 0 Hours 0 Minutes 15 Seconds
ADMINP.BatchReqProcessing.ModReaderAuthor.AverageProcTime = 0 Hours 0 Minutes 16 Seconds
ADMINP.BatchReqProcessing.ModReaderAuthor.MaxProcTime = 0 Hours 0 Minutes 16 Seconds
Related reference Administration Process Statistics