1.性能指标综述
通常我们都从两个层面定义性能场景的需求指标:业务指标和技术指标。这两个层面需要有映射关系,技术指标不能脱离业务指标。
所有的技术指标都是在有业务场景的前提下制定的,而技术指标和业务指标之间也要有详细的换算过程。这样一来,技术指标就不会是一块飞地。同时,在回答了技术指标是否满足的同时,也能回答是否可以满足业务指标。
1.1常用的性能指标表示法
简写 | 英文全称 | 含义 |
RT | Response Time | 响应时间,通常说的响应时间都是包括了Request Time和Response Time |
HPS | Hits Per Second | 每秒点击数 |
TPS | Transactions Per Second | 每秒事务数 |
QPS | Queries Per Second | 在MySQL中指每秒SQL数 |
RPS | Requests Per Second | 每秒请求数 |
CPS | Codes Per Second | 在HTTP协议中,CPS偶有提及,指的是HTTP返回码每秒 |
PV | Page View | 页面浏览量 |
UV | Unique Vistor | 独立访问者 |
IP | Internet Protocol | 本意是IP地址,在性能中一般指独立IP数 |
Throughput | 吞吐量 | |
IOPS | Input/Output Operations Per Second | 通常描述磁盘 |
1.2性能指标解读
TPS 是性能领域中一个关键的性能指标概念,它用来描述每秒事务数。TPS 在不同的行业、不同的业务中定义的粒度都是不同的。所以不管在哪里用 TPS,一定要有一个前提,就是所有相关的人都要知道 T 是如何定义的。
通常情况下,会根据场景的目的来定义 TPS 的粒度。如果是接口层性能测试,T 可以直接定义为接口级;如果业务级性能测试,T 可以直接定义为每个业务步骤和完整的业务。
在性能测试过程中,TPS之所以重要,是因为它可以反应出一个系统的处理能力。
以上图为例,说明TPS中T的定义取决于场景的目标和T的作用。如果我们要单独测试接口 1、2、3,那 T 就是接口级的;如果我们要从用户的角度来下一个订单,那 1、2、3 应该在一个 T 中,这就是业务级的了。
接口级脚本:
事务 start(接口1) | 事务 start(接口2) | 事务 start(接口3) |
接口1 脚本 | 接口2 脚本 | 接口3 脚本 |
事务end(接口1) |
事务 end(接口2) | 事务end(接口3) |
业务级接口层脚本(就是用接口拼接出一个完整的业务流):
事务 start(业务A) |
接口1脚本 - 接口2(同步调用) |
接口1脚本 - 接口3(异步调用) |
事务 end(业务A) |
用户级脚本:
事务 start(业务A) |
点击0 - 接口1脚本 - 接口2(同步调用) |
点击0 - 接口1脚本 - 接口3(异步调用 |
事务 end(业务A) |
你要创建什么级别的事务,完全取决于测试的目的是什么。一般情况下,会按从上到下的顺序一一地来测试,这样路径清晰地执行是容易定位问题的。
QPS,如果它描述的是数据库中的 Query Per Second,从上面的示意图中来看, 其实描述的是服务后面接的数据库中 SQL 的每秒执行条数。如果描述的是前端的每秒查询数,那就不包括插入、更新、删除操作了。显然这样的指标用来描述系统整体的性能是不够 全面的。所以不建议用 QPS 来描述系统整体的性能,以免产生误解。
在性能中,还有一个重要的概念就是响应时间(Response Time),指从客户端发起请求开启,到客户端接收到结果的总时间,包括服务器处理时间与网络传输时间。其中响应时间还可以根据服务架构使用链路监控工具和一些Metrics工具来分析在一个请求链路上,每个节点消耗的时间和请求的持续时间。对于响应时间来说,时间的拆分定位是性能瓶颈定位分析中非常重要的一节。
1.3压力工具中的线程数和用户数与 TPS
并发是需要具体的指标来承载的。你可以说,我的并发是1000TPS,或者1000RPS,或者1000HPS,这都随便去定义。但是在一个具体的项目中,当你说到并发1000这样没有单位的词时,一定要让大家都能理解这是什么。
因为用户有了业务含义,所以有些人认为一个系统如果有1万个用户在线,那就应该测试1万的并发线程,这种逻辑是不技术的。通常,会对在线的用户做并发度的分析,在很多业务中,并发度都会低于5%,甚至低于1%。
拿5%来计算,就是10000用户x5%=500(TPS),注意哦,这里是TPS,而不是并发线程数。如果这时响应时间是100ms,那显然并发线程数是500TPS/(1000ms/100ms)=50(并发线程)。
但是!响应时间肯定不会一直都是100ms的。所以通常情况下,上面的这个比例都不会固定,而是随着并发线程数的增加,会出现趋势上的关系。 所以,在性能分析中,要注意观察:趋势!
2.并发与用户数
绝对并发指的是同一时刻的并发数;相对并发指的是一个时间段内发生的事情。
假设上图中的这些小人是严格按照这个逻辑到达系统的,那显然,系统的绝对并发用户 数是 4。如果描述 1 秒内的并发用户数,那就是 16。
但是,在实际的系统中,用户通常是这样分配的:
也就是说,这些用户会分布在系统中不同的服务、网络等对象中。这时候”绝对并发“这个 概念就难描述了,很难说是哪部分的绝对并发呢?所以“绝对并发”这个概念,不管是用来描述硬件细化的层面,还是用来描述业务逻辑的层面,都是没什么意义的。
我们只要描述并发就好了,不用有“相对”和“绝对”的概念,这样可以简化沟通,也不会出错。
如何来描述上面的并发用户数呢?建议用 TPS 来承载“并发”这个概念。并发数是 16TPS,就是 1 秒内整个系统处理了 16 个事务
2.1在线用户数与并发用户数
如上图所示,总共有 32 个用户进入了系统,但是绿色的用户并没有任何动作,那么显然, 在线用户数是 32 个,并发用户数是 16 个,这时的并发度就是 50%。
但在一个系统中,通常都是下面这个样子的。
为了能 hold 住更多的用户,通常都会把一些数据放到 Redis 这样的缓存服务器中。所以在线用户数怎么算呢,如果仅从上面这种简单的图来看的话,其实就是缓存服务器能有多大,能 hold 住多少用户需要的数据。所以我们要是想知道在线的最大的用户数是多少,对于一个设计逻辑清晰的系统来说,不用测试就可以知道,直接拿缓存的内存来算就可以了。但是在实际的项目中,还会将超时放在一起来考虑。
要想计算并发用户和在线用户数之间的关系,都需要有并发度。
通过这个示例图可以得出:
- 如果有 10000 个在线用户数,同时并发度是 1%,那显然并发用户数就是 100。
- 如果每个线程的 20TPS,显然只需要 5 个线程就够了(请注意,这里说的线程指的是压 力机的线程数)。
- 这时对 Server 来说,它处理的就是 100TPS,平均响应时间是 50ms。50ms 就是根据 1000ms/20TPS 得来的(请注意,这里说的平均响应时间会在一个区间内浮动,但只要 TPS 不变,这个平均响应时间就不会变)。
- 如果有两个 Server 线程来处理,那么一个线程就是 50TPS,这个很直接吧。 请注意,这里有一个转换的细节,那就是并发用户数到压力机的并发线程数。
而通常说的“并发”这个词,依赖 TPS 来承载的时候,指的都是 Server 端的处理能力,并不是压力工具上的并发线程数。在上面的例子中,说的并发就是指服务器上 100TPS 的处理能力,而不是指 5 个压力机的并发线程数。
TPS = 1000ms/响应时间(单位ms) * 压力机线程数
对于压力工具来说,只要不报错,我们就关心 TPS 和响应时间就可以了,因为 TPS 反应出来的是和服务器对应的处理能力,至少压力线程数是多少,并不关键。
服务端有多少个线程,就可以支持多少个压力机上的并发线程。但是这取决于 TPS 有多少,如果服务端处理的快,那压力机的并发线程就可以更多一些。这个逻辑看似很合理,但是通常服务端都是有业务逻辑的,既然有业务逻辑,显然不会比压力机快。 应该说,服务端需要更多的线程来处理压力机线程发过来的请求。所以我们用几台压力机就可以压几十台服务端的性能了。
- 通常所说的并发都是指服务端的并发,而不是指压力机上的并发线程数,因为服务端的并发才是服务器的处理能力。
- 性能中常说的并发,是用 TPS 这样的概念来承载具体数值的。
- 压力工具中的线程数、响应时间和 TPS 之间是有对应关系的。