本文是基於上一篇《SQLServer 2012之AlwaysOn —— 指定數據同步鏈路，消除網絡抖動導致的提交延遲問題》的問題繼續進行優化；具體背景請參照上文；
前后折騰了一個多月，最近終於把這塊難啃的骨頭搞定了。問題只是出在網卡的高級功能上；
解決方案：關閉網卡的高級功能Jumbo Mtu和Large Send Offload V2
問題分析：根據Broadcom Ethernet 網絡適配器的解釋
Jumbo Mtu
Jumbo Mtu 屬性允許網絡適配器發送和接收長度大於 1514 字節但小於 9000 字節的超大 Ethernet 幀。此屬性要求具有能夠處理 Jumbo 幀的交換機。
默認情況下，幀大小設置為 1500 字節。要增加接收幀的大小，可按 500 字節的增量增大字節數量。
Large Send Offload
TCP 分段通常是由協議棧完成。啟用 Large Send Offload 屬性時，TCP 分段可由網絡適配器完成。
Disable： 禁用 Large Send Offload。
Enable （默認值）： 啟用 Large Send Offload。
Large Send Offload是網絡適配器的高級功能之一，其目的是在網絡適配器端進行TCP的分段工作，以此來降低CPU以及其他相關設備的壓力；但隨着多核CPU的廣泛應用，網絡適配器的處理能力相較於CPU弱了很多，因此當大量並發請求導致數據頻繁更新或大數據量傳送時，開啟Large Send Offload將嚴重影響性能；
在網上搜了一把，此類問題的影響還比較常見
http://www.peerwisdom.org/2013/04/03/large-send-offload-and-network-performance/
下圖是優化前的性能曲線，圖中表示方法調用TP99指標在100~300ms之間抖動
下圖是優化后的性能曲線，可以看到優化后的方法調用TP99指標在100~150ms范圍內，且比較平穩;
盡管WSFC不再像Windows Cluster一樣要有心跳線，但為了避免大量的數據同步對應用訪問鏈路造成影響，還是建議增加直連線（或專用的數據同步網絡），並修改endpoint_url使其生效，具體方法可以參照《SQLServer 2012之AlwaysOn —— 指定數據同步鏈路，消除網絡抖動導致的提交延遲問題》操作；