Dio的性能测试经验总结 - 1

在行里做性能测试有些年头了，前前后后也经历了几十个不同的项目，开始几年像海绵一样疯狂充实，知识总是在不断的肯定和否定之间循环前进积累，但最近几年却因为各种原因懈怠了下来，今天开一个连载贴，希望能重新督促自己时时总结，也许各贴的内容和饱和度不一，但只希望不要烂尾。

最近一两年测试中心给新人培训和做技术交流总会叫上我，写培训材料的时候也思考了很多项目中遇到的问题和不同观点的差异，连载先从性能测试的术语概念讲起吧。

一、TPS：TPS是衡量系统处理能力最重要的指标之一，但它有2个隐含的含义需要明确：

1、TPS是一个平均值、统计值，不是瞬时值。

2、TPS大小受Transaction的定义范围影响。

一个小故事：

有一次领导找我聊性能测试，突然问到TPS峰值一般如何计算，我说如果没有生产统计值，业界通常会用2/8定律来估算，就是假设80%的交易量发生在20%的时间里。领导想了一会后说“那20%的时间也是个比较长的时间段啊，这个时间段里是不是还有峰值呢？是不是也应该用2/8定律再估算一下呢？，如此下去即使我们统计到了秒级，那一秒以内也还有更高的峰值啊...”听到这里我已经汗如雨下，感觉无法勒住领导的思路了。确实没有任何规定说2/8定律只能使用一次，如果将时间再细分下去也难保不会出现更高的峰值，但如此细分哪里是尽头？仿佛蚁人陷入了无限缩小的困境~

2/8定律是否准确暂且不论，收拾下思路，这个谈话其实明确了一点：TPS是一个秒级的统计值，一个平均值，如果要细化到毫秒那是TPmS，但不管是TPmS或TPS，它同样是一个时间间隔下的统计值、平均值，绝不是瞬时值。绝对的瞬时值是没有意义的，因为一个时间切片下事务没有“执行完成”的概念。

TPS中的事务（Transaction）与被测程序的数据库事务不是一个概念，TPS的事务通常由性能脚本开发人员定义，他可以对应的是一个请求，如接口测试，也可以对应多个请求，如LoadRunner中HTTP协议的函数，因此TPS的大小也就受事务Transaction定义的范围影响了，一般情况下事务的范围定义要看你是站在什么角度来模拟性能场景，没有强行规定，只要统一即可。另外LoadRunner工具是以Action为单位迭代的，因此一个Action里多个事务的TPS是一样的，慢的事务会拖累快的事务，这个需要注意。

二、TRT/ART（平均事务响应时间）：

Transaction Average Response Time，简写无论怎么写其含义是一样的，它体现的是一个场景下所有事务响应时间的均值。但实际分析时为了过滤掉不稳定的环境因素，通常在LoadRunner Analysis报告中会取90%（百分比可自定义）事务的响应时间，90%响应时间的含义是90%的事务响应时间比这个值小，10%的事务响应时间比这个值大，需要注意这里的90%不是按事务发生的时间先后排序，而是按响应时间的大小排序。最后因为也与事务相关，因此它的大小也同样受事务定义范围的影响。