UserPrincipal.GetGroups()调用执行时间逐次增加的原因及解决方法

可能的原因 #

• 资源泄漏：PrincipalSearchResult<Principal>实现了IDisposable接口，但你的代码未手动释放资源。每次调用后残留的对象会占用内存和AD连接资源，累积后导致后续调用逐步变慢。
• 未复用连接上下文：如果每次同步都新建PrincipalContext，会重复建立AD连接，随着调用次数增加，连接开销不断累积，拖慢查询速度。
• 延迟加载的重复枚举：PrincipalSearchResult是延迟加载集合，若后续代码多次枚举该集合（比如循环、计数），会重复向AD发送查询请求，实际执行的查询次数远超预期。
• AD服务器负载升高：频繁的查询请求可能导致AD服务器CPU、内存负载上升，响应速度自然下降。

解决办法 #

• 强制释放资源：用using语句包裹GetGroups()的结果，确保每次调用后及时清理资源：

  using (var userGroups = userAd.GetGroups())
  {
      // 提前将集合转为列表，避免后续重复枚举触发多次AD查询
      var groupsList = userGroups.ToList();
      // 后续操作使用groupsList
  }
  

• 复用PrincipalContext：不要每次同步都创建新的PrincipalContext，将其作为单例或在请求范围内复用，减少连接建立的开销：

  // 全局或请求级复用的AD上下文
  private static readonly PrincipalContext _adContext = new PrincipalContext(ContextType.Domain);
  
  // 同步函数中复用上下文获取UserPrincipal
  var userAd = UserPrincipal.FindByIdentity(_adContext, IdentityType.SamAccountName, username);
  

• 缓存查询结果：如果用户组不会频繁变化，将查询到的组信息缓存起来（比如内存缓存），设定合理过期时间，避免每次同步都去AD查询：

  var cacheKey = $"UserGroups_{username}";
  var cachedGroups = _cache.Get(cacheKey) as List<string>;
  if (cachedGroups == null)
  {
      using (var userGroups = userAd.GetGroups())
      {
          cachedGroups = userGroups.Select(g => g.Name).ToList();
          _cache.Set(cacheKey, cachedGroups, TimeSpan.FromHours(1)); // 1小时过期
      }
  }
  // 使用cachedGroups进行后续操作
  

• 优化AD查询精度：如果只需要组的特定属性（比如名称、SID），用DirectorySearcher替代UserPrincipal.GetGroups()，精确指定要加载的属性，减少数据传输量：

  var searcher = new DirectorySearcher(_adContext)
  {
      Filter = $"(&(objectCategory=group)(member={userAd.DistinguishedName}))",
      PropertiesToLoad = { "name", "objectSid" } // 仅加载需要的属性
  };
  using (var results = searcher.FindAll())
  {
      // 处理查询结果
  }
  

• 排查AD服务器状态：联系AD管理员查看服务器的CPU、内存、磁盘IO负载，确认是否是服务器本身的性能瓶颈导致响应变慢。

内容的提问来源于stack exchange，提问作者Vladimir