三.数据分析。
从业务流程中可以想象，fcgi端的TE_tpcall()时间似乎应该大致等于或略大于(网络传输时间等等)svr_cc上服务总的时间加上排队时间，而排队时间应该这样线性计算：前端并发数/服务端并发数*服务端服务单笔总的平均时间。但上表的实际数据是TE_tpcall()时间小于svr_cc上服务总的时间!类似的，browser端的时间和fcgi上fcgi进程处理时间也有这种现象，只是相差很小。
这是因为实际情况不是我们想象的那样!SUN主机上即有客户端cc1(包括FCGI)节点也有服务端cc2节点的进程和TE核心运行。如果cc1上只有一个fcgi进程(TE客户端进程)串行发起业务，我们可以认为fcgi端的TE_tpcall()时间似乎应该大致等于或略大于(网络传输时间等等)svr_cc上服务总的时间。而当cc1上有多个fcgi进程(TE客户端进程)并发发起业务时，在处理一笔服务业务逻辑的时间段内，SUN上的CPU时间还会分给其他客户进程以及TE核心(处理其他事务)，这样在客户端并发情况下，每笔业务的服务端处理时间实际上包含一部分其他笔业务(客户进程和TE核心)的处理时间里。而所有的业务都是如此，最终TE_tpcall()平均时间小于svr_cc上服务总的平均时间。
在cc1进程和cc2进程的关系中，由于他们在一台主机上，并且cc1进程不在少数，因此上述两个时间差别也较大。而在browser和cc1的关系中，可以排除客户端进程的处理(因为在另外一台机器上)对服务端的影响，而只有TE核心并行处理多个交易对单笔服务处理时间的影响。在测试环境下，服务业务处理时间是主要时间，TE处理时间相对很小，因此上述两个时间差别也非常小。
经验：在多前端并发情况下，前端等待服务端应答时间和服务端处理时间不是线性比例关系，会比预期线性比例关系算出的时间小。具体差别和测试环境配置有关系。客户端和服务端分开在不同的机器上会更接近线性比例关系。
四.平均值以外的东西。
对测试原始数据取平均值可以对整个系统的性能有一个了解，但有时只看平均值会遗漏一些同样有价值的东西。
取30_20_10_2测试中任一个svr_cc服务进程的原始数据，用excel读入，计算每笔service_before_tpcall时间(该服务的主要业务逻辑时间，也是整个开户业务中最耗时间的环节)，并制作service_before_tpcall时间随笔数变化的图表，我们可以看到服务业务逻辑随数据库中记录数的变化规律，这显然是平均值无法体现的。
从图中可以看出，该业务逻辑时间的平均分布随笔数的增加而增加，也就是说，该业务逻辑时间和数据库中记录数有关(因为开户是插入操作，应该是该业务逻辑时间的平均分布随数据库记录数的增加而增加)，在这种大型OLTP系统中，这种处理时间和数据库记录数有较大关系的现象是不好的。一般是因为数据库索引设置问题，需要调整数据库索引。
至于最后几十笔的时间急剧减小，是因为在最后几十笔时有些前端应用已经完成，对于后台的压力减小，服务处理时间自然减小，并且越到后来运行的前端应用越少，服务处理时间也越少。结合前面第二节的经验，在这个例子中，因为这些无效数据只占全部数据很少一部分，它们不会对平均值产生太大的误差。
经验：有时平均值数据不能反映系统全部特性。尤其对于系统关键环节，必要时还对原始数据做进一步统计分析。
文章来源于领测软件测试网 https://www.ltesting.net/
