在SQL Server 2008中壓縮TCP

-7

我們有使用實體框架的.NET 4.0應用程序。應用程序通過TCP遠程連接到SQL Server。在局域網上時，速度很快，但通過互聯網，流量非常高。在SQL Server 2008中壓縮TCP

所有我們想要做的是把一些TCP compression，但它看起來像SQL Server 2008不提供此功能。

什麼，使TCP通信壓縮的簡單的解決方案？

2011-08-21 Cartesius00

提示 - 侮辱的人誰是幫助你不會讓你擁有這個網站上。 – Hogan

此外，如果您在LAN上看不到問題，但在WAN上看到問題，則問題與延遲有關 - 您正在進行大量小型連接，並且在WAN上運行緩慢。壓縮不會幫助解決這個問題（事實上它可能會使情況變得更糟）。在你的程序上運行一個配置文件，看看實體真的在做什麼。它會讓你哭泣。 – Hogan

這個問題尖叫'錯誤的建築選擇'，不幸的是沒有一個簡單的解決方案。有幾個人試圖告訴你，已經和簡單地駁回他們的建議不會使問題消失 – Eddy

SQL Server使用TDS protocal。

它並不關心你是否使用TCP或命名管道「力」。從獲取數據到B

你需要啓用或設立某種compression（谷歌搜索）的：

在OS級
接口/硬件級
網絡級

來源

2011-08-21 11:37:25 gbn

太通用了。對不起，但沒用。 – Cartesius00

@James：我會用簡單的語言爲你解釋：「這不是SQL Server問題」。投票結束並且-1 – gbn

@James - gbn答案完全是關鍵。你的問題與SQL服務器或實體框架無關（除了實體框架是錯誤的平臺使用，因爲它總是有這樣的問題） - 如果你想回答這個問題，把它帶到硬件和系統管理站點 - - 超級用戶或服務器故障。你在這裏得不到多少幫助。 – Hogan

您正試圖在錯誤的級別/層上解決問題。用SQL服務器分析您的通信並開始考慮優化。這是開始的唯一有效點。 EF的不正確使用會導致可怕的喋喋不休和與SQL服務器的通信速度緩慢，這是任何壓縮都無法解決的問題，因爲繁瑣的順序通信意味着多次不必要的往返數據庫，每次往返都會增加數據庫的處理持續時間潛伏。我已經看到了解決方案（其中一些是我自己做的），在不正確的EF使用情況下，在單個請求處理中創建了數千個延遲加載查詢。

而且是它可以與存儲過程和自定義查詢，並與整個放棄EF最壞的情況下更換你的EF代碼部分結束。

如果你的問題是傳輸的數據量再次是時間去想優化和傳輸的數據量減少到只需要子集，或使用存儲過程或視圖SQL服務器上的一些預處理。順便說一句。這種思考應該在應用程序設計期間完成，您應該考慮應用程序運行的目標環境。

編輯：

還有一點需要注意。通過WAN與數據庫進行通信並不常見。通常這樣的需求導致實現另一個層次，其中業務邏輯坐在具有SQL服務器的局域網服務器上。此業務邏輯層向WAN上的客戶端公開Web服務。此架構可以減少與數據庫進行大量通信時的等待時間，同時，客戶端和服務之間正確的消息交換架構可以帶來額外的改進。

來源

2011-08-21 12:35:35

+1不錯，考慮周到的答案 – gbn

正是我想說的！ – Hogan

在SQL Server 2008中壓縮TCP

回答

相關問題