性能测试的原则和方法

什么是性能问题

性能问题表现第一种

小规模使用的时候性能表现很好，在大规模使用的时候，性能变得很差，业务响应时间随业务压力变得越来越慢

原因：代码中对资源使用产生的瓶颈，后续的请求在资源(cpu、内存、锁、线程池)上排队

例子： 没有索引的表的查询 随着业务量增加，表的行数快速增加，查询越来越慢

性能测试解决的大部分问题是这种类型

性能问题表现第二种

在一定压力情况下，应用的性能突然变差或者不可使用

原因：应用突然进入了一个异常逻辑，占用了很多资源，并且无法从异常状态下退出

例子：fetion 后台 初期版本中使用同步的socket连接，网络单点异常的时候，全网的服务都不可用。

性能测试很难解决这种类型的性能问题。很难定位异常逻辑是什么。

性能问题表现第三种

在压力大于某个阀值的情况下，总会出现少量业务错误

原因：业务逻辑考虑不严密，导致少量流程不是按照期望发生

例子：取一个值做uniquekey值，锁保护不够导致，取值不唯一。

性能测试能够很好的解决这类问题。

一些基本概念详细解析

响应时间

Response time是性能测试中考察被测试软件性能的一个指标；

Response time包括从客户端请求发出开始，到reponse 应答回来后的时间总和，可能包括：

网络传输

cpu上可执行队列的等待时间

cpu计算

线程执行sleep语句的时间

锁、闩的等待时间

磁盘io等待时间等。

吞吐量tps

吞吐量 tps是考察性能的另一个指标；

单位时间内完成业务量的多少，tps 是一个具体的常用的指标，每秒钟完成的业务个数。

通常的误会是认为response time一定会影响tps，这个不一定成立

并发

并发是指同时被处理的请求个数，同时处理可以有2个含义

同时都在线程堆栈上的请求

指在正在cpu上处理的请求

这里指得是后者。

那么最大的tps = Concurrency*1000 /请求在cpu上的处理时间(ms)

思考时间

Think Time思考时间 Think time是在测试代码中出现的概念，为了在测试代码中模拟时间用户的思考时间而加的sleep时间，2个作用

第一作用是控制测试代码的业务执行速度，完美地执行出预计的场景

模拟实际用户执行的思考时间

有状态的服务 很重要

无状态的服务 不重要

测试压力 business load

测试压力是什么？或者是客户做了什么导致服务器产生压力

对于无状态服务器，客户端的压力来源于客户端的请求数/秒

对于有状态服务器，客户端的压力是客户端的在服务器的留存信息和rps。

数据库是一个有状态的服务器

有状态的服务器更容易有性能问题