通過網絡對SQL的.NET訪問比本地更快 - 嗯，爲什麼？

我有一個不尋常的問題，因爲我的一臺服務器的性能比其他所有服務器都好，我想知道爲什麼 - 這樣我就可以讓其他人也能工作:-)通過網絡對SQL的.NET訪問比本地更快 - 嗯，爲什麼？

這是我的）場景：我有一個SQL Server 2012盒子，這是我們的生產環境 - 我們稱之爲PROD。我有一個我們創建的.NET工具，一次又一次地運行一些查詢。如果我在與本地數據庫交談的服務器上運行此工具，則對於一組簡單查詢，我得到的響應時間在4到20毫秒之間，對於更復雜的查詢，響應時間在589到731毫秒之間。

我們還有另一個相同規格的SQL Server 2012盒 - 我們稱之爲STAG。如果我在這個盒子上運行相同的工具，連接到PROD數據庫（即相同的代碼，相同的連接字符串等），我會得到簡單查詢的響應時間在0到1毫秒之間，對於更復雜的查詢響應時間爲109到133毫秒，即明顯更好。

我們有第三個相同規格的SQL Server 2012盒子 - 我們稱之爲TEST。再次運行連接到PROD的相同工具，我分別得到4到15和600到800毫秒的響應時間。

實際上，如果我在除STAG環境之外的任何服務器（或客戶端）上運行此工具，則時間大致相同。這僅僅是STAG出了所有其他環境，我真的想知道爲什麼！

如果我在SSMS中運行查詢，那麼它們都是高性能的（即像期望的那樣非常快）。

因此，似乎在大多數機器上，從.NET訪問數據庫都有一個開銷，除了我們的STAG服務器之外，我希望我們的所有服務器都具有這種級別的性能。

事情我已經檢查，均出現匹配：

SQL客戶端和服務器協議和配置
底層硬件（它在相同的vSphere基礎架構所有正在運行）
的.NET Framework版本
AV版和政策應用

我不知所措知道要檢查些什麼 - 任何人都可以提出任何建議嗎？

感謝

馬克

來源

2017-09-26 Mark E

分析它。我的意思是，*實際*分析它，沒有比較設置或假設事物應該是相同的。使用Wireshark跟蹤網絡流量並查看數據包延遲，「SET STATISTICS TIME ON」，查詢計劃。首先要做的是確定差異是由於SQL Server中的查詢執行還是底層網絡/ CPU /內存基礎架構造成的。我的錢就是後者。（虛擬硬件也是硬件，它可能比物理硬件表現得更加奇怪） –

我傾向於同意你的看法，即它不是SQL Server相關的，因爲它在上面提到的設置中在SSMS中運行相同的查詢，需要0ms - 你不能比這更快！另外，從STAG服務器訪問PROD更快的事實告訴我，這與.NET本身有關，因爲查詢數據庫的其他方法正在迅速減輕。我會看看wireshark的東西，但再次說服務器自己說話比其他服務器慢，這也似乎很奇怪。 –

使用Wireshark，我可以看到TEST服務器的數據發送和接收比STAG慢30ms，這對我來說顯示PROD服務器的網絡和底層硬件不是問題 - 它必須是介於代碼的運行和消息通過網絡 - 在.NET System.Data.SqlClient的內部也許？但是，這不就像我們使用的黑匣子嗎？ –

右鍵 - 我終於跟蹤下來，它是不是很大，但至少我有一致性。我們在工具的計算時序邏輯有一個錯誤 - 我們使用TimeSpan.TicksPerMillisecond以及由於某種原因，Stopwatch.Frequency是對我們的服務器8-一個不同@

切換到秒錶.StartNew（），然後停止（）並使用ElapsedMilliseconds給我們正確的答案。

感謝Jeroen爲您提供的所有幫助 - 至少在下次出現性能問題時，我可以採納您的建議並首先運行。

來源

2017-09-27 15:32:23

通過網絡對SQL的.NET訪問比本地更快 - 嗯，爲什麼？

回答

相關問題