处理管理请求时生成的统计信息

所有已进行处理调度的管理进程请求都是从“管理请求”数据库 (ADMIN4.NSF) 发起的。通常，系统会定期从 ADMIN4.NSF 检索请求，并根据请求的类型和时间安排将其临时存储到各种标识表中。在时间安排中确定的处理时间到来之前，它们会一直停留在标识表内。会为这些标识表维护统计信息，以提供有关标识表使用情况和管理进程负载的反馈信息。所有这些统计数据引用的标识表中都包含要处理的管理进程请求的 NoteID。

管理进程妥善分类到相应的标识表中后，即可对其进行处理。在安排的相应时刻，它们将被放入多个可用消息队列之一。与为标识表维护的统计信息类似，也会为每个消息队列维护统计信息，以提供信息队列使用情况的反馈信息。

此外，还提供了第三组统计信息，以提供管理进程批量请求的请求处理相关信息的反馈信息。

这些统计信息划分为以下三个区域：

提供这些统计信息目的是为了呈现一种管理进程活动的表示。这些统计信息并不真的提供用于监控进程的方法。例如，检查统计信息并发现任一消息队列中有大量“等待中”统计信息说明所有请求处理线程都在忙于运行长时间运行的请求，并且可能必须对管理进程再执行一些配置。例如，可能需要添加额外的处理线程或配置专用线程

Collection 表

Collection 表首先依据时间安排，然后依据请求类型划分。这些标识表包含请求的管理进程请求的 NoteID。在 Collection 表中的每添加一个 NoteID，TotalCount 统计信息都会被更新。TotalCount 表示在 Collection 表中存储过的 NoteID 的总数。例如，

ADMINP.RequestIdTables.CollectionTables.Daily.DirectoryManyDoc.TotalCount = 40

还会为每个标识表维护另外一个统计信息，表示“Waiting”表中当前存储的 NoteID 的数量。

以下示例显示了“请求标识表”监视的“收集”部分中可能的统计信息。示例中仅包含“立即”和“时间间隔”请求。

• 立即 (ADMINP.RequestIdTables.CollectionTables.Immediate)

  AllServer

  DirectoryOneDoc

  DirectoryManyDoc

  ModifyACL

  ModifyDesignElement

  ModifyUnreadList

  ModifyReaderAuthor

  ModifyPersonDoc

• 时间间隔 (ADMINP.RequestIdTables.CollectionTables.Interval)

  AllServer

  DirectoryOneDoc

  DirectoryManyDoc

  ModifyACL

  ModifyDesignElement

  ModifyUnreadList

  ModifyReaderAuthor

  ModifyPersonDoc

所有这些统计信息中都包含 TotalCount 和 Waiting 的统计信息。例如：

ADMINP.RequestIdTables.CollectionTables.Immediate.DirectoryOneDoc.Waiting = 0

ADMINP.RequestIdTables.CollectionTables.Interval.DirectoryOneDoc.TotalCount = 1

BatchRequest 表

Collection 表在到了处理该相应请求的时间时，会转变为另外一组标识表 － BatchRequest 标识表。BatchRequest 标识表中包含的是将由批量处理请求处理的一组 NoteID。这些表用于分组批量请求或分组具有共同时间安排类型的请求。BatchRequest 标识表在关联的请求被执行和表被清空之前会保持原样。以下为 BatchRequest 统计信息的示例：

ADMINP.RequestIdTables.BatchRequest

BatchedRequest 标识表中存储的 NoteID 是一种特殊情况。PrimaryTables 之一中会包含触发请求以启动请求分批。然后，实际的请求处理会引用相应的 BatchRequest 表获取更多有关需要处理哪些请求的更多信息。

SecondaryRequest 表

此外，还有一组标识表，称为 SecondaryRequest 表。SecondaryRequest tables 是不常用的时间安排类型（如定时请求、第三方请求、快速重试请求和其他请求）的收集区域。以下为 SecondaryRequest 统计信息的示例：

ADMINP.RequestIdTables.SecondaryRequest

PrimaryRequest 表

除了 BatchRequest 表中存储的请求，所有其他请求在被安排进行处理前，都会流过 PrimaryRequest 表，此表是请求的最后一个短期存储位置。以下为 PrimaryRequest 统计信息的示例：

ADMINP.RequestIdTables.PrimaryRequest

每个 NoteID 都将从 PrimaryRequest 表中取出并放入请求时间安排的下一个阶段。检索请求的顺序是首先从 Immediate 表中检索，然后是 Interval 表，最后是 General。这可以确保请求时间安排的紧急性可以得到维持。检索到请求后，会将其封装并存储到请求消息队列中。

请求消息队列

请求消息队列传播请求处理线程。当出现要处理的请求时，分派线程会在消息队列中放入一个请求消息，并向请求处理线程发出信号，表明有需要执行的工作。请求处理线程接收到此消息并对请求进行相应处理。在消息放入消息队列时，统计信息将会更新，并会记录时间戳记。在从消息队列中删除消息时，统计信息也会更新，并将使用时间戳记来确定消息在消息队列中停留了多长时间。处理线程监控的消息队列有四种，分别为 Immediate、Interval、General Purpose 和 Poll。

• ADMINP.ReqMsgQueue.Immediate
• ADMINP.ReqMsgQueue.Interval
• ADMINP.ReqMsgQueue.GeneralPurpose
• ADMINP.ReqMsgQueue.Poll respectively

Poll 消息队列和 Poll 线程专用于邮件策略管理。

Immediate 消息队列只有在配置了负责处理时间安排为“立即”的请求的特殊用途线程时才存在。当存在 Immediate 消息队列时，所有以“立即”时间安排为目标的请求都将放入此线程。所有闲置的处理线程在移向下一个小队列之前会先检查 Immediate 消息队列。

Interval 消息队列只有在配置了负责处理时间安排为“时间间隔”的请求的特殊用途线程时才存在。当存在 Interval 消息队列时，所有以“时间间隔”时间安排为目标的请求都将放入此线程。所有闲置的处理线程会先检查 Immediate 消息队列（如果有），然后检查 Interval 消息队列中是否有需要处理的请求。

General Purpose 消息队列负责处理所有类型的时间安排，但是如果存在特殊用途线程，检查需要执行的工作时将最后一个检查 General Purpose 消息队列。

Domino® 服务器控制台中的 ReqMsgQue 统计信息示例：

ADMINP.ReqMsgQueue.Interval.AverageWaitTime = 0 Hours 0 Minutes 0 Seconds

ADMINP.ReqMsgQueue.Interval.TotalCount = 1

ADMINP.ReqMsgQueue.Interval.Waiting = 0

检索到要处理的请求后，将为长期运行的批量请求维护统计信息。

批量请求处理

对于每个批量请求，将会维护一个统计信息，以监控处理该批次的最长时间，以及处理该批次的平均时间。

Domino® 服务器控制台中处理时间统计信息的示例：

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