分析思路其实非常简单，就是3段论：发起端、传输路径、接收端。

其实分析很多联机问题的时候，都是这个思路，比如一个报文没有被收到，同样要分析发起端、传输路径、接收端。只是很多时候，大家并没有把三个方面都考虑进去，或者想当然的认为某一端是没问题的，导致互相之间的扯皮，扯皮中的核心利器就是从技术上证明某一段没有问题，把嫌疑撇清，把怀疑范围不断缩小。

接收端的吞吐量不达预期，比如忽高忽低，比如比预期少，往往是接收端自己的应用逻辑有问题或者处理能力受限，但本节通过介绍另外两端出现问题的例子，说说全面思考的重要性。

案例1：吞吐量忽高忽低

一个服务器的吞吐量忽高忽低往往是应用逻辑造成的，比如代码周期性的做一件事，或者每隔一个周期就遇到一个资源争用（比如数据库锁、文件锁）等等，这是我们的经验。

有这样一个Case，服务器B的应用在旧版本情况下，TPS非常稳定，压力工具以每秒130笔的速度发过去，从应用上看，TPS长期稳定在127-132之间，可以说是非常稳定。

换版之后，应用的TPS忽高忽低，在50-130之间震荡。查看CPU利用率：

10秒为一个周期，CPU抖动

业务场景是这样的：

A：PC压力机
B、C、D均为服务器
E：PC压力机，作为挡板，接收D发来的请求，给出对应的回复。

分析B的吞吐量问题，思路就是3段论：发起端、传输、接收端。此时并不急于换成旧版本，因为换版的过程复杂，耗时长，况且，系统环境随时在变化。

接收端

首先看服务器B的网络IO

从nmon上看，服务器B的CPU抖动应该是由于网络IO的抖动造成的。即服务器B接收的报文多，则CPU利用率高，接收的报文少，则CPU利用率低。NET read和write是对称的，因为，收到报文并处理后，立即又将处理后的报文发送出去。

从上面的分析可以看出，抖动不是应用造成的，B作为一个业务的接收端，应该是没有问题的。为了确诊这一问题，再做一个实验，只做A发给B，B只接收不做业务处理。

至此，可以看出，没有应用启动的情况下，NET IO也是梳子形状，问题得到确认。

那么剩下的就是发起端和传输路径。

发起端

要么是网络问题，要么是A和C发给B的来包的TPS抖动。我们先看发起端。

发起端有两个，A和C，如果是A和C发给B的来包的TPS抖动，那么A和C的来包要抖动频率一致才能有这个效果。而C的来包也是A¬>B>C>D>E>D>C这条路径过来的，C的报文最初也是A产生的。因此问题归结到1个发起端上。即A发送出来的报文的TPS抖动

此时观察A（PC机）的性能监控数据，CPU、磁盘IO、内存均正常。而网络延时方面忽大忽小有时网络延时2-3ms，有时40-50ms。似乎网络的可能性更大一些。

传输路径端

网络的可能性大一些，因此查看一下网络情况。从B ping A，看看网络传输效果，差的时候，每10秒出现一次略大的延时（20ms级别），其他都是小于1ms，这个ping的结果和nmon中网络IO的变化规律一致。都是10秒为一个周期。问题定位在了传输路径。

此时找网络管理员求助，网络管理员查到他们新加的P780服务器连接的到交换机的端口一直在up，down，对交换机性能产生影响。把连这台设备的端口down掉了，问题得到解决。
网络IO也恢复正常

案例2：HA切换过程中报文丢失了

某场景，压力机向A服务器通过JMS协议发送MQ报文，A和B为HA集群，A为主用服务器，B为备用服务器

在HA切换过程中（20秒钟），压力机显示一直在以每秒几十笔的速度发送报文，而这段时间这些报文既没有在A上出现，也没有在B上出现，似乎报文丢了。

拿出我们的3段论：发起端、传输、接收端来分析。

接收端

业务处理日志没有显示有处理，消息队列没有报文。确认两个接收端都没有收到，那么，要么是发起端没发出来，要么是传输过程丢了。

传输路径端

可能1）网络不好，发不出去或者丢包。由于该系统是基于TCP传输的，从协议的角度，如果没发出去，消息应该还在发起端存放着

可能2）机器的路由配置，把报文引导到AB之外的机器。但经过配置文件的排查，并没有发现有配置错误。

发起端

发起端的压力工具显示一直以每秒几十笔的速度发送报文。这就不太合乎逻辑了。AB在做HA的时候，耗时有20秒，这个过程中A的MQ已经停止工作，而B的MQ还没有准备好（不一定有20秒那么久，但至少也有5秒、10秒），这段时间，没有任何一个MQ队列可以接收消息，此时JMS协议是不可能发到对端的。

那只有一种可能，发起端根本就没有发出去。
那么问题来了，“压力工具显示一直以每秒几十笔的速度发送报文”是怎么回事？可以猜测，肯定是代码处理有逻辑问题，即底层遇到发送错误，但没有向上汇报，上层代码仍然在不停的计数。

通过检查代码，果然是上述问题。至此，扯皮结束。

搜索微信号关注“性能测试与调优”