本文是基于上一篇《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 —— 指定数据同步链路，消除网络抖动导致的提交延迟问题》操作；