光纖 WAN 上的延遲和 SQL 連接 - 應用程序電子管理
我在鹽湖城的 VMware 主機上託管了一個加密的 SQL 伺服器數據庫 (SQL Server 2012)。我的鹽湖城數據管道通過 Comcast 的光纖傳輸速度為 100 Mbps。我的 Phoenix 端通過 Cox 提供了 50 Mbps 的光纖傳輸速率。我的站點之間的延遲是 45 毫秒。每個辦公室有大約 40 個使用者。20 個使用者正在從 Phoenix 登錄我們的 E-manage 應用程序，大約 20 個使用者正在從 Salt Lake 一側登錄。
使用 E-manage 的 Salt Lake LAN 使用者沒有速度問題，但是，我的 Phoenix LAN 使用者報告在 E-manage 應用程序中工作時訪問速度很慢。開發人員認為問題源於虛擬化的使用（VMWare ESxi 5.5）。當我檢查 VMware 和我的 SAN 的資源使用率時，我發現所有資源（CPU、RAM 等）基本上都處於休眠狀態。我為 Cox 和 Comcast 執行了頻寬報告，我的頻寬使用率在正常範圍內。對於我使用的內部應用程序的減速，我沒有其他問題。
我已經打開 Comcast 和 Cox 的票，看看可以做些什麼來將延遲從 45 毫秒降低到 20 的高 30 秒。我覺得這樣做會有所作為。我在網路的兩端都執行 WAN 加速器來加速 TCP 流量並且不包括 SQL 流量。為了排除 Phoenix 網路，我讓使用者將筆記型電腦直接連接到 Cox 光纖電路，然後使用 E-manage。結果相同。響應時間很慢。我在站點之間確實有一條 IPSec 隧道，為了排除 IPSec 隧道，我更改了 Phoenix DNS 記錄以利用我為我的 SQL 伺服器設置的公共 A 記錄。
我已經向 SQL 開發人員詢問了另一位客戶的聯繫方式，以便我可以看到從遠端站點執行時他們的訪問/響應時間是什麼樣的。我很樂意提供更詳細的資訊，看看是否有我遺漏的東西。我還考慮過從第三方執行獨立的 SQL 查詢，以查看我的 SQL 伺服器的執行狀況以及 SQL 數據庫是否存在任何潛在問題。
我確實有一個我準備配置的物理伺服器，看看它是否會有所作為。
我期待任何意見、建議和建議。
提前致謝 - 特洛伊
從性能的角度來看，通過 WAN 連接執行基於 SQL 的應用程序的 IMO（而且我沒有任何經驗數據）很少能很好地工作。有多個層面可能會導致 WAN 使用者出現問題，而 LAN 使用者不會很容易發現這些問題；應用程序延遲、SQL 加密延遲、作業系統延遲、網路延遲等。在其他條件相同的情況下，正如您所說，網路延遲可能是從使用者角度來看問題所在的地方。除非您在同一提供商的兩個位置之間建立了專用的私人連接，否則可能無能為力。他們只能控制自己的網路基礎設施，不能控制彼此，當然也不能控制兩者之間的任何東西。你的延遲並沒有讓我覺得太可怕所以我