性能测试负载目标探讨

一、前提

　　近期我跟踪了2个外协人员参与的性能测试项目，沟通中发现大家在制定测试策略时对如何确定负载目标、计算并发用户数量等方面有很多不同方法，本文希望能对各种方法进行探讨，并根据已有经验对策略制定方面给出一些自己的建议。本文被测应用以银行系统为主，压力发起工具以LoadRunner为例。

　　二、术语

　　单位时间：本文中以1秒为单位时间。

　　在线用户数量：访问被测应用的用户数量，但单位时间内用户不会同时对被测服务器发送请求，产生压力。

　　并发用户数量：部分书中分狭义和广义两种，狭义指单位时间内同时执行一种操作的用户数量，广义指单位时间内同时执行多种不同操作的用户数量，广义的并发用户操作更接近实际业务环境。但本文中的并发用户数量仅指狭义而言，因为广义是多种狭义的组合。

　　TPS：Transaction per Second，每秒事务数量，单位是事务/秒。

　　TRT：Transaction Response Time，事务响应时间，指TPS稳定时的平均事务响应时间，单位是秒。

　　三、负载目标

　　1. 负载视角

　　制定测试策略是性能测试的重点，包括测试范围、场景提取、负载目标、发起方式、通过标准等。而负载目标关系整个测试的场景设计、并发配比、结果评判，因此确定负载目标也决定了测试的总体方向。通过了解业务需求，负载目标都会转化为一系列具体的数值，一般可从两方面来划分：

　　前端：业务人员更关注前端并发用户数量或在线用户数量，以人数衡量;

　　后端：技术人员更关注后端应用服务器和数据库服务器的负载能力，以TPS衡量;

　　前端并发用户数量的计算在业界中有很多公式和原则，如2/8原则、10%在线用户数量估算、(在线用户数量*session时间)/监控时间等，但各公式和原则计算出的并发用户数量并不精确，如有10万在线用户的系统不能说仅测试10万*10%=1万并发用户即可。

　　后端TPS反应被测应用的实际负载能力，对已有具体业务量的应用可以计算精确，如银行系统中某省行对公交易量日均10万笔，则可精确计算出TPS均值=10万/(6*3600)=4.63笔/秒(对公业务按6小时计算)，若被测应用达不到TPS要求则完成不了当日业务。

　　同一个被测应用以不同视角估算负载目标，得到的数值可能会有很大差异，因此如何正确选择负载目标，将会直接影响之后的测试方法和场景设计。

　　2. 负载指标

　　抛开视角的选择，单从最终测试指标来说，对于一个软硬件环境固定的应用程序，只有一个负载指标是固定的，那就是最大事务处理能力 – 通常以TPS衡量。随着负载的增加，被测应用将会逐渐达到最大事务处理能力，若应用足够健壮，则负载继续增加，应用的事务处理能力也不会骤然下降。因此性能测试的目标就是确定被测应用的最大事务处理能力。以事务处理能力反推，将逐渐捋清TPS、TRT、并发用户数量、在线用户数量等负载目标的关系和估算。

　　1、TPS

　　Transaction的粒度会直接影响TPS的计算，因此Transaction定义时要保证粒度适当：

　　C/S架构联机类应用中一笔交易往往会流经多层前置应用，需要确定压力发起工具所在位置，建议跨过前端直压被测应用，此时一个Transaction代表一支后台交易。

　　B/S架构经管类应用中一个页面操作可能会和后台有多次交互，建议以页面上的操作为Transaction划分基准，但要保证Transaction内的交互操作在前端是不可再拆分的。

　　LoadRunner发起压力时Action内的语句是反复迭代的，而LR计算TPS仅看1秒内执行了几次Transaction，如果Action内有多个Transaction则各事务的TPS都一样，反应不出各事务的真实处理能力，因此建议Action内只定义一个或尽量精简的Transaction。

　　由此TPS才可以准确表示被测应用的事务处理能力。

　　通过获取生产日志、参考相似系统等方式能够得到具体交易(事务)数量的被测应用程序，以TPS为负载目标是直接也最准确的。但要注意，若以TPS为目标，则前端配置的并发数量就不再代表并发人数，而是并发提交事务的数量。TPS和TRT的计算关系将在下面详述。

　　2、TRT

　　TRT指TPS稳定时(不一定是最大时)的平均事务响应时间，不关注个别事务，它和TPS关系紧密，随TPS的变化而变化。当负载增加时TRT会逐渐增大，直至事务阻塞，交易超时。

　　TPS × TRT = 并发提交事务的数量。如果以TPS=20为目标，且此时TRT=2秒，则并发提交事务的数量=20×2=40笔。如果1个用户单位时间内提交1笔事务，则可等于有40个并发用户数量。

　　设定好目标TPS后要同时兼顾TRT的表现，若TRT明显超出业务要求，即使达到负载目标也是无效的。TRT无固定的好坏标准，一般来说对OLTP的联机应用，从前端提交到返回不应高于3秒，后台应用程序和数据库的处理应在1秒左右。对OLAP的在线分析系统或一般网站可遵循3/5/8原则，或更长。

　　3、并发用户数量

　　通常理解并发用户数量就是LoadRunner里设置的VUser数量，通过梯度增加VUser，对比TPS变化即可找到被测应用的最大并发用户。但我却认为并发用户数量不等于LoadRunner中设置的VUser数量。受交易响应时间、thinktime、pacing和集合点等因素影响，VUser数量不能直接体现被测应用负载能力。假设同样10个VUser并发一次，如果A程序的响应时间是1秒，则A程序的TPS=10/1=10。而B程序的响应时间是5秒，则B程序的TPS=10/5=2。同样在混合场景中用VUser比例体现不同应用的负载比例也是错误的，混合场景下由于各交易相互影响，单交易负载时响应快的很可能现在出现阻塞，前端VUser的比例根本无法准确控制后端应用的压力。

　　因此我更愿意将“并发用户数量”和“并发提交事务数量”挂钩，体现被测应用实际负载：单位时间内n个用户并发向被测应用提交n个事务请求(n是相同的)。VUser的数量和发起设置只是实现并发用户数量的一种手段。

　　4、在线用户数量

　　在线用户数量与并发用户数量、TPS、TRT间没有固定的换算公式，我不提倡10%这样的粗糙比例，对联机类应用在线用户就是每天签到的柜员数量，对经管类应用就是月末、季末时所有登录系统的用户数量。在线用户数量可以从需求人员或生产管理员处获得大概数值，但不能通过性能测试倒推出在线数量。