性能测试数据分析经验(3)

　　经验：有时取平均值会有较大的误差，尤其是测试不完全正常的情况。这时需要仔细分析原始数据，排除造成误差的数据，以系统稳定(正常)时的数据作为有效数据。这里excel图表功能是一个非常好用的工具。

　　三.数据分析。

　　从业务流程中可以想象，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系统中，这种处理时间和数据库记录数有较大关系的现象是不好的。一般是因为数据库索引设置问题，需要调整数据库索引。

　　至于最后几十笔的时间急剧减小，是因为在最后几十笔时有些前端应用已经完成，对于后台的压力减小，服务处理时间自然减小，并且越到后来运行的前端应用越少，服务处理时间也越少。结合前面第二节的经验，在这个例子中，因为这些无效数据只占全部数据很少一部分，它们不会对平均值产生太大的误差。

　　经验：有时平均值数据不能反映系统全部特性。尤其对于系统关键环节，必要时还对原始数据做进一步统计分析。

原文转自：http://www.uml.org.cn/Test/200505265.htm