LDAP Bind Time和LDAP Search Time是ADDS性能监控的核心计数器：前者反映单次绑定平均耗时，持续超100ms需干预；后者体现每次搜索响应时间，突增提示查询效率下降，须结合LDAP Client Sessions、线程池使用率及缓存命中率综合分析。

直接看 ldap bind time 和 ldap search time 这两个计数器，比任何脚本或日志更及时、更贴近真实客户端体验。

重点盯住这两个核心计数器

在性能监视器（perfmon.exe）中添加以下对象：

• NTDS\LDAP Bind Time：单次 LDAP 绑定（如用户登录认证）的平均耗时。持续超过 100ms 就需干预；若偶发尖峰达 500ms+，要结合线程池和 GC 状态排查
• NTDS\LDAP Search Time：搜索操作（如查用户、组成员）的平均响应时间。注意不是“每秒搜索数”，而是每次搜索花多久——突增说明查询效率下降，常见于未索引属性或大范围筛选

搭配观察关联指标，避免误判

单独看延迟数值容易漏掉根源。务必同步检查：

• NTDS\LDAP Client Sessions：活跃会话数。长期 >500 且伴随高延迟，大概率是应用未关闭连接，而非域控本身慢
• NTDS\Threads in Thread Pool：工作线程使用量。接近最大值（默认 64–256）说明请求排队，此时即使 CPU 不高，也会出现“卡但不忙”的假象
• NTDS\DS Database Cache % Hit：数据库缓存命中率。低于 95% 意味着频繁读盘，要交叉验证磁盘延迟（PhysicalDisk\Avg. Disk sec/Read >15ms 就危险）

客户端视角补充验证（不能只信服务端计数器）

服务端平均值会掩盖毛刺，真实用户体验取决于最慢那一次。建议每天抽样测几轮：

• 用 ldp.exe 连接域控 IP（绕过 DNS），执行 Bind → Search（如 cn=Administrator,dc=domain,dc=com）→ Unbind，手动记时
• PowerShell 中运行：Measure-Command { Get-ADUser Administrator -Server dc01.domain.com }，看实际耗时
• 若客户端测得 200ms 而 perfmon 显示平均 40ms，说明存在大量快响应 + 少量超长延迟，需启用调试日志抓取慢查询详情

Exchange 环境额外关注 LDAP Read Time

Exchange 服务器自带监控项：MSExchangeDSAccess\LDAP Read Time。该计数器每 5 秒采样一次，5 分钟内报告最大值。微软明确警告：平均值超 50ms 即触发告警。这不是阈值建议，而是 Exchange 服务可接受的硬性延迟上限——超过即可能影响邮箱访问、地址簿查询等关键功能。