序：本案例来自我工作中的真实案例，但排查时间之长，涉及人员之多让我感慨，怎样才能成为一个能畅游知识大海的优秀测试工程师。

SAS

本案例是公司的一个与搜索服务相关的功能接口，为了不涉及公司隐私，我会忽略一些细节，在此简称SAS。

网络拓扑

network_topology_sas.png

上图中的网络拓扑图共分三层，粗略描述了这部分服务所处的网络环境架构：

• Load Balance层: 会从收发请求信息，将请求信息按照一定规则传递给下层Gateway;
• Gateway层: 服务网关，收到上层请求后传递给下层的应用服务器集群，并接收响应向上层传送；
• Application Servers: SAS应用服务所在层级，进行业务处理的，并返回结果向上层传送；

测试场景

• 20，100 Virtual User/ 10 min

• 链路测试实验，分别施加压力在图中三层；

• 测试方法：

  • 从Application Server层中挑选一台机器
  • 从Gateway中挑选一台服务器，使其连接Application Server层中的所有服务器（在执行时有不规范，最初该层并未测试）
  • 从Load Balance中挑选一台服务器，使其连接Gateway层中的所有服务器
  • 测试顺序，由下往上依次完成；

测试目的

• 掌握链路上每层节点的性能数据，建立基线；
• 保证链路上的每一层上，在较大负载时能有良好的表现，尽量减小每一层传输所造成的性能损耗；
• 性能水平能够达到需求规定；

执行测试

发现问题

在20， 100 User的压力下：

• 在Application Server的测试非常顺利，图形和数据都很优秀。

• 但是从Load Balance层施压100 User压力，就可以看到大相径庭的图形，如下：

  
  sas_phenomenon.png
  sas_phenomenon_zoom_in.png
  

  图中标出的两组测试图形差异极大，后者的表现只能用不合格来形容。

• 而且蹊跷的一点是在20 user的小压力下，这两层所表现的图形还是比较稳定的，只是load balance层上的性能略微差一些。按照经验来说，从最高层往下压测，性能的稳定性应该还是不错的。头一回遇到这种情况，当时就懵了，看来这次测试是无法通过了。

排查思路

• 先查看测试报告，上个图：

  
  sas_phenomenon_error_report.png
• 报告中报错最多的就是Non HTTP Response code，这种错误占比很高，关于这个问题，我在另外一篇文章JMeter-failed to respond Connection reset问题 中已经有详细的分析，此处不再赘述。但从现象上来看，似乎是和网络传输有一定的关系；
• 反复对比测试，现象依然存在。。。。

漫漫分析之路

分析：由于在Application Server端，并没有出现不稳定的情况。而在LoadBalance端出现的极其不稳定，那么似乎应该是由Load Balance或者Gateway产生的问题

因此，
嫌疑1：Gateway上面的部署的监控SAS服务的追踪日志。
测试结果：打开和关闭日志，其性能差异微乎其微，在Load Balance端的压测的结果依然不好；

嫌疑2：Gateway服务集群是否有可能存在某些台服务器的性能出了问题。这个问题，在我以前的测试中是遇到过，也就是说某些服务器是否拖了后腿。
测试结果：花了两天排查了所有的Gateway Server，不存在拖后腿的问题；

嫌疑3：既然Gateway集群已经洗清嫌疑，那么焦点似乎就集中到了Load Balance上了。当时的Load Balance有两种服务软件，Netscaler和Haproxy。在测试前就制定了计划，其主要目的是确认：

• 是否在性能上这两种服务存在性能差异？
• 如果有差异，是否是配置造成的？
• 这些Load Balance连接单台和连接多台Gateway服务器后的性能表现如何？

测试结果：

• 性能上两者存在一定的性能差异，但是差距不大且表现的都不稳定；
• 协同运维工程师的合作，对存在可能问题的配置点进行了调整，但是没有明显效果；
• 但发现一个特点，无论是NetScaler或者是Haproxy，连接的Gateway Server数量越少，其性能表现就越稳定；反之，则越糟糕；

这个结果还不算最糟糕的，因为线上还有很多服务运行在同样的load balance下已经很多年，但是并没有发现这种奇怪的现象产生。为此，我还进行了大量的横向对比测试，发现就是针对这个服务引起的。

曙光初现

• 作为一个技术人员，最无助的时刻就像是我操作着一叶孤舟面在汹涌澎湃的大海中寻找目标。

• 前面的报错报告中，谈到了网络错误，这给了我们一些提示；由于我没有权限去观测Haproxy的网络指标，因此运维同事特意搭建了一台临时的服务器，并在上面安装了netdata这个小工具。从这个图像上面，我们看到了网络对比情况：
  

  首先是SAS服务的网络状况 perf_haproxy_netstat_sas.png
  接着是其它服务网络状况 perf_haproxy_netstat_otherservice.png
  

  从中可以看到SAS的网络图像是很杂乱的，似乎是tcp的连接关闭频繁，导致图像很杂乱；而下图中其它服务所对应的网络图形已经近似一个方形很有规律，tcp的建立的连接复用率较高。

这时，开发也提供了一个信息，这次的服务使用的是tomcat 8，而以往都是使用的tomcat 7。一切的疑点又回到了原点，最初认为问题出在Load Balance层面，绕了一圈又回到了这个服务本身。常常感叹人生无常，没想到技术上也是如此。。。

Tomcat 7 vs Tomcat 8

首先声明，这里不会涉及两个web容器版本的不同。而只针对我们公司的服务应用场景，所展示出来的两者性能差异；
查看它们的tcp网络图：
20 user /10 min

tomcat7_20user.jpg
tomcat8_20user.jpg

100 user / 10 min

tomcat7_100user.jpg
tomcat8_100user.jpg

性能计数器图：

tomcat7_vs_8_perfconter.jpg

乘胜追击

拿出了铁一般证据后，线上开始将SAS服务逐步配置tomcat 7。再从Load balance施加压力，就发现，性能图形已经很稳定，且吞吐量符合要求。

change_to_tomcat7.jpg

后续

• 实际上疑点并没有完全解除，虽然知道了tomcat 7和8在该应用场景上的性能稳定性差距很大，但是并不能说明是tomcat 8的问题；应该说，产生这种差距最可能的原因还是在容器的配置上的差异导致。但遗憾的是，目前开发人员并没有时间去研究其中的差异。但经历了这个案例，我还是想继续追踪下去，有新消息我会更新；
• 我对TCP/IP并不熟悉，当探测到了网络丢包，tcp连接不能服用等原因后，还是欠缺从这方面下手找原因的方法和手段。从一个侧面也告诉你，每一个问题，都是对你的一个考题，知识越丰富，才越能体现你的价值；
• 虽然这篇文章不长，但是从现象到分析出问题的点，却花费了很长时间。这过程是很煎熬的，一方面不想放弃找到原因，另一方面，协助我的同事还忙于其他事物，尽管他们对这个问题很有兴趣，但时间一长，他们也产生了倦怠。此时，我只能硬着头皮去激励他们继续与我合作，在我意志开始动摇的之前。
• 写出此文的目的，是为了厘清处理问题的思路，为我今后的工作积累经验。另外就是一些乌托邦式的成就感，当然这不会改变领导对测试人员的价值看法，价值几何？也许还不够加个鸡腿吧。。。