延遲的DirectoryEntry Refreshcache

我們（根據環境和負載11秒或以上）調用.NET的System.DirectoryServices.DirectoryEntry.RefreshCache（時）找到一個顯著延遲。這種延遲是由於通過DNS和WINS查找DC名稱的通用嘗試。有誰知道如何指導.NET使用提供的服務器名稱？細節在下面的部分提供。延遲的DirectoryEntry Refreshcache

DNS查詢： .NET經過一系列的服務DNS查詢，在查詢中使用的服務器名稱。當然，這個查詢不起作用。 .NET然後故障轉移到WINS/NetBIOS來查找服務器名稱。這不起作用，所以.NET會故障轉移到使用服務器名稱查詢DNS系統的A記錄。最後一步工作。其中一些步驟有重大延誤。

頻率：如果測試迭代間隔不夠好開，在每個測試迭代的開始發生此問題。在更強烈的測試負載下，問題可能會跳過一兩次測試。（ - 另一天的問題，我不知道爲什麼多個連接每次迭代製造）每個測試迭代中

後續連接嘗試通常效果都不錯。

技術：承載代碼的客戶端計算機比Active Directory服務器不同的域的成員。信任已經建立在域之間。

代碼：

AuthenticationTypes authTypes = AuthenticationTypes.SecureSocketsLayer; 
String connect = "LDAP://servername.otherdomain:636/DC=otherdomain" 
DirectoryEntry de = new DirectoryEntry(connect, serviceAccount, PWD, authTypes) 
de.RefreshCache(); // The delay is specific to this line. 

// And so on... 
dtree = de.Children; 
policy = new DomainPolicy(de); 
...

由於

來源

2017-07-28 user8383791

DNS查找似乎不是問題。將DC添加到服務器的主機文件中，而不會改變性能。 – user8383791

使用查詢中的服務器名稱，.NET看起來像經歷了一系列服務的DNS查找。這個查詢不起作用，當然.NET會故障轉移到WINS/NetBIOS來查找服務器名稱。這不起作用，所以.NET會故障轉移到使用服務器名稱查詢DNS系統的A記錄。最後一步工作。 – user8383791

的解決這一問題的是，以改變線

AuthenticationTypes使用authTypes = AuthenticationTypes.SecureSocketsLayer;

與

AuthenticationTypes使用authTypes = AuthenticationTypes.SecureSocketsLayer || AuthenticationTypes.ServerBind;

通過指定「ServerBind」我們讓程序知道，連接字符串包含服務器名稱。

如果沒有此ServerBind值，則涉及的組件開始猜測遊戲，嘗試查詢DNS以獲取包含給定字符串的服務名稱，然後故障轉移到WINS，然後再轉移到使用服務器的A記錄的DNS名稱。所有這些行動都需要花費大量的時間。

來源

2017-08-15 17:22:57 user8383791

延遲的DirectoryEntry Refreshcache

回答

相關問題