System.DirectoryServices 在多线程时固定我的处理器 - 我可以减轻负担吗?

发布于 2024-07-13 15:49:23 字数 881 浏览 7 评论 0原文

我的应用程序获取当前登录的用户,并使用 DirectoryServices.DirectorySearcher 提取有关他们的一些其他详细信息(我们存储在一些自定义 AD 字段中的一些属性以及他们的电子邮件地址)。 这很好用,尽管我一直认为它有点慢 - 我的单线程代码每秒只能向 AD 发出大约 2-3 个请求。

当我将此代码移至网络服务器时,真正的问题出现了。 如果有多个并发用户,每秒的请求数会大幅增加,并且 LSASS.EXE 进程会固定在我的服务器上。 我检查了域控制器,它们很好 - 瓶颈显然在应用程序端。 我怀疑拖慢我速度的是 NTLM/Kerberos 质询/响应,以及同时请求的数量,甚至是多核处理器。

我们的网络策略不允许从 AD 进行匿名读取,因此没有选择。 另外,我已经尝试了“AuthenticationTypes”的每个成员(在示例中,我使用的是.FastBind),但它们似乎都具有相同的吞吐率和相同的处理器负载。

有人知道我如何解决这个限制并降低对处理器的要求吗?

这是我正在使用的代码 - 非常简单:

Dim sPath As String = "LDAP://" & stringUserDN
Dim entry As New DirectoryEntry(sPath)
entry.AuthenticationType = AuthenticationTypes.FastBind

For Each stringADNumber As String In entry.Properties(_ADPROP_EMPLOYEENUMBER)
    'return first item
    Return Convert.ToInt32(stringADNumber)
Next

Return String.Empty

My application takes the currently logged-in user and uses an a DirectoryServices.DirectorySearcher to pull a few additional detail about them (some properties we have stored in a few custom AD fields, as well as their email address). This works great, though I've always though it was a little slow - my single-threaded code could only make about 2-3 requests/second to AD.

The real problem came when I moved this code to a web server. With multiple simultaneous users, the number of requests/second jumps greatly, and the LSASS.EXE process pegs on my server. I've checked the domain controllers, and they're just fine - the bottleneck is clearly on the application side. I suspect that what's slowing my down is the NTLM/Kerberos challenge/response, and the number of simultaneous requests pegs even the multi-core processor.

Our network policy doesn't allow anonymous reads from AD, so that choice is out. Also, I've tried every member of "AuthenticationTypes" (in the example, I'm using .FastBind), but they all seem to have about the same throughput rate with the same load on the processor.

Does anybody have an idea for how I might work around this restriction and lower my demands on the processor?

Here is the code I'm using - pretty straightforward:

Dim sPath As String = "LDAP://" & stringUserDN
Dim entry As New DirectoryEntry(sPath)
entry.AuthenticationType = AuthenticationTypes.FastBind

For Each stringADNumber As String In entry.Properties(_ADPROP_EMPLOYEENUMBER)
    'return first item
    Return Convert.ToInt32(stringADNumber)
Next

Return String.Empty

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

救星 2024-07-20 15:49:23

我没有太多在 AD 中查找项目的经验。 但是,一个建议是您可能需要签入请求的 HttpContext。 当前发出请求的用户有一些基本信息,例如组、SID 和令牌信息。 我不相信默认情况下有电子邮件地址字段,但您也许可以使用 User.Name 属性 + "@your.domain" 构建一个电子邮件地址。

为了显示此数据,您需要 IIS 要求对请求进行身份验证。 匿名用户不会填充此数据。 此数据的访问器是 HttpContext.Current.Request.LogonUserIdentity,或者,在页面的隐藏代码中,您可以简称为 this.Request.LogonUserIdentity

希望这有帮助。 祝你好运。

I don't have a ton of experience with looking up items in AD. However, one suggestion is that you might want to check in the HttpContext for the request. There is some basic information for the current user that is making the request, such as groups, SID, and token information. I don't beleive there is an email address field by default, but you might be able to use the User.Name property + "@your.domain" to build an email address.

In order for this data to show up, you will need IIS to be requiring authentication for requests. Anonymous users will not have this data populated. The accessor for this data is HttpContext.Current.Request.LogonUserIdentity or, alternatively, within the code behind for your page, you can call this.Request.LogonUserIdentity for short.

Hopefully this helps. Good luck.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文