我把它命名为“你的心脏搭桥显示”，因为你不能编造这些东西。
当我们分析重大问题的时候，我们总是先找一些平常的问题，心里总是在想:“我们以前见过这个吗?”
在大多数情况下，它是新的或不同的东西。
这个问题
最近，我们被叫来研究一个严重的性能问题。客户的企业服务器从企业数据中心转移到云解决方案提供商。当这个移动发生时，性能突然开始下降，以至于访问任何服务器都是不可用的。
为了解决这个问题，公司IT部门选择了一个新的广域网压缩供应商。乐动体育 足球快讯旧的供应商版本的广域网压缩设备仍然在那里，但在“旁路”模式下运行。我要补充的是，到目前为止，我们已经研究了很多东西，比如带宽利用率、核心基础设施中的组件，以及延迟和吞吐量测试。所以我们采取了一种新的方法包的跟踪看看是什么问题。当我们这样做的时候，我们总是很快地知道什么不是问题。我们在早期就这样做，从而节省了测试的时间和麻烦，这样我们就可以快速关注可能出现的问题。这也有助于消除每个人思维过程中的拥堵。
吞吐量测试和检查跟踪文件
然后我们开始运行几个吞吐量测试。这开始揭示了一些重复出现的情况，包括，当一个1gb或更大的文件被写入Colorado Springs的服务器时，TCP错误将开始出现，总是发生在文件的末尾。影响是如此的严重，它会减慢文件传输速度，以至于看起来它已经停止了，但实际上并没有。不久之后，SMB(文件传输协议)将超时。
回顾跟踪文件可以发现，与Colorado Springs的WAN压缩设备加速设备的NEW供应商版本相比，离开服务器的数据包的模式有所不同。这表明网络路径内的设备正在改变数据包。进一步的调查显示，在旁路模式下运行的旧供应商版本的广域网压缩设备正在影响流量中数据包的TCP部分。
具体来说，从Colorado Springs数据中心出站端的跟踪文件可以看出，“Selective ACKs”(SACK)被引入到流量中，但这些数据还没有从服务器发送。当客户机从处理这些SACKs中恢复过来时，写进程变得非常慢，响应时间为100毫秒。
SACK的正常使用发生在主机接收数据时，但是由于资源限制，数据在传递给接收应用程序之前就在机器上丢失了。例如，接收主机上的操作系统可能会“没收”属于其他进程的内存，以防止系统死锁或内存池耗尽，并且接收缓冲区在数据交付给应用程序之前被消除。当这种情况发生时，接收主机将发送一个SACK以重新传输丢失的数据。接收者释放资源并可能丢失数据的过程也称为乐动体育 南安普顿合作伙伴食言．
虽然这种情况被视为正常响应，但服务器并没有显示它，这表明数据路径中的另一个透明设备导致了问题。进一步的测试表明，通过从网络路径中移除旧的供应商版本的广域网压缩设备，多余的SACKs被消除了。
对进一步跟踪文件的检查显示，通过删除Bypass，多余的SACKS就消失了，所有数据都在没有任何损失的情况下交付了。SMB (Server Message Block)性能
SMB请求61,440字节的数据，在文件复制(读或写)操作期间需要请求每个数据块。下面的图1:1 - 1:2显示了在观察到问题时从服务器和客户端获取的测量值。
服务器端响应时间相当高，平均为263毫秒。
图1:1Microsoft SMB服务响应时间:统计服务器的最小、最大和平均服务响应时间
图1:2Microsoft SMB服务响应时间:统计来自客户端的最小、最大和平均服务响应时间(SRT)
图1:3SBM文件写请求和响应时间——下面的图表包含了SMB写请求和SMB写响应的时间度量。
吞吐量图
图2:1吞吐量图:该图显示了会话TCP 4153的单个吞吐量（红色的）和TCP 4184（绿色），这是在WAAS从网络中移除时进行的。TCP 4153平均花费139秒，而相同的文件在TCP 4184对话中花费151秒。
已建立的基线(齿轮位实验室测试网络)
在Gearbit Lab中，进行了测试以提供吞吐量基线。基线提供了在没有任何外部干扰的情况下可实现吞吐量的模拟。
图3:1低吞吐量:使用WAN模拟器进行，RTT 40ms，窗口大小16384结果为6,400,000 bps (800,000 bps)。
图3:2Gearbit Lab Test 2 Much Better Throughput: conducted using WAN emulator, RTT 40ms, Window Size 64440 Results yield 720,000,000 bps (90,000,000 bps)
总而言之，Gearbit实验室的测试表明，如果设置更高的传输窗口，则使用给定设备可以实现更高的吞吐量。此外，更换旧的广域网压缩设备显著提高了性能，消除了SACT违约问题。
访问www.gearbit.com用于其他案例研究。