通過 WAN 執行終端伺服器 (RDS) 的延遲門檻值是多少？
我見過：高延遲連結上的終端伺服器性能
但是我有一個客戶有興趣將他們的系統基礎設施遷移到一個數據中心，該數據中心距離他們的主要總部有大約 62 毫秒的延遲。
該環境由三個 Windows Server 2008 R2 RDS 伺服器、文件和列印服務以及 Microsoft Exchange 2010 組成。它們目前都在 vSphere 5.5 集群上進行了虛擬化。目前共有 80 個使用者使用 HP 瘦客戶端在本地連接到 RDS 系統。
由於設施問題以及異地和遠端使用者的增加，推動將系統轉移到數據中心設施。新站點將採用更高端的 vSphere 主機和全快閃記憶體儲存。
與託管設施的連接將通過具有多個 ISP 和故障轉移的站點到站點 VPN 建立。
不過，這是個壞主意嗎？我經常連接到這個站點以通過 RDP 和 SSH 進行維護工作，性能對於我的案例來說是完全可以接受的。使用者正在使用基本的 MS Office 套件和幾個基於 SSH 終端的輕量級ERP 應用程序。
對於這種類型的使用者負載和 Microsoft RDS，62ms 是否合理？
我在全球有幾千人每天都在連接和使用會計/辦公軟體。只要他們的響應時間低於 300 毫秒，我們就不會收到投訴，而是 ymmv。
作為概念證明，我使用 linux / netem 機器設置了我們使用者的一個交換機，並不斷提高延遲/丟包率，直到我開始抱怨。在本地複製網路條件然後移動我的應用程序兩次要容易得多。
我覺得這有點主觀，因為除非延遲就像本地桌面體驗一樣，否則有些使用者不會高興，而即使延遲是 300 毫秒，其他使用者也會高興並且不會抱怨。
延遲確實是使用者體驗的殺手，但具體多少是個人感知的問題。
這是 TechEd 2014 上關於類似場景中使用者體驗的非常好的影片（該影片是關於 VDI，但它與遠端桌面服務的體驗類似。）
https://www.youtube.com/watch?v=CcKAwzebHoc&feature=youtu.be
所以你可能會說，永遠不要超過 300 毫秒。62ms 可能是“OK”。