小规模使用的时候性能表现很好，在大规模使用的时候，性能变得很差，业务响应时间随业务压力变得越来越慢
原因：代码中对资源使用产生的瓶颈，后续的请求在资源(cpu、内存、锁、线程池)上排队
例子： 没有索引的表的查询 随着业务量增加，表的行数快速增加，查询越来越慢
性能测试解决的大部分问题是这种类型
在一定压力情况下，应用的性能突然变差或者不可使用
原因：应用突然进入了一个异常逻辑，占用了很多资源，并且无法从异常状态下退出
例子：fetion 后台 初期版本中使用同步的socket连接，网络单点异常的时候，全网的服务都不可用。
性能测试很难解决这种类型的性能问题。很难定位异常逻辑是什么。
在压力大于某个阀值的情况下，总会出现少量业务错误
原因：业务逻辑考虑不严密，导致少量流程不是按照期望发生
例子：取一个值做uniquekey值，锁保护不够导致，取值不唯一。
性能测试能够很好的解决这类问题。
一些基本概念详细解析
Response time是性能测试中考察被测试软件性能的一个指标；
Response time包括从客户端请求发出开始，到reponse 应答回来后的时间总和，可能包括：
网络传输
cpu上可执行队列的等待时间
cpu计算
线程执行sleep语句的时间
锁、闩的等待时间
磁盘io等待时间等。
吞吐量 tps是考察性能的另一个指标；
单位时间内完成业务量的多少，tps 是一个具体的常用的指标，每秒钟完成的业务个数。
通常的误会是认为response time一定会影响tps，这个不一定成立
并发是指同时被处理的请求个数，同时处理可以有2个含义
同时都在线程堆栈上的请求
指在正在cpu上处理的请求
这里指得是后者。
那么最大的tps=Concurrency*1000/请求在cpu上的处理时间(ms)
Think Time思考时间 Think time是在测试代码中出现的概念，为了在测试代码中模拟时间用户的思考时间而加的sleep时间，2个作用
第一作用是控制测试代码的业务执行速度，完美地执行出预计的场景
模拟实际用户执行的思考时间
有状态的服务 很重要
无状态的服务 不重要
测试压力是什么？或者是客户做了什么导致服务器产生压力
对于无状态服务器，客户端的压力来源于客户端的请求数/秒
对于有状态服务器，客户端的压力是客户端的在服务器的留存信息和rps。
数据库是一个有状态的服务器
有状态的服务器更容易有性能问题
性能测试过程
完美的性能测试就是软件在现网上实际运行的过程
实验室状态下永远也无法完全模拟
性能测试无法找到所有的问题
定义了在影响软件运行性能的各个方面采用什么样的方法和策略模拟真实的情况，达到尽量真实模拟的目的。
非常重要， 决定了测试的成败
关于基础数据的原则
必须调查或者预测出数据库表中每个表应该有多少行的数据。
而且数据取值要实际情况一样丰富。
数据长度和实际情况相同
基础数据决定着数据库server的cpu、内存、io使用或其他多种资源的使用逻辑。
测试数据： 从基础数据中选取的，参与到性能测试中的数据
选择原则
在应用合理范围内随机挑选数据、挑选足够的量。
挑选数据的方式通常影响数据库的内存和io，有状态服务的cpu和内存，线程、锁等。
测试完成哪些业务？完成速率？
建立业务模型的原则
最好是实际用户行为的统计，如果没有借助同类软件的用户行为统计，再没有，根据有经验人员的预估。
把用户所有可能使用业务按使用频繁程度排序，频繁程度越高就越应该纳入测试场景。
查看业务消耗计算资源的程度，预计消耗程度越大的越应该纳入测试场景
建立业务模型的原则
多个业务在一起的复杂场景：把所有业务的在周期内的tps放在一起考察，一般情况下所有业务会有一致性的行为，即tps变化一致，取峰值阶段的tps为测试通过标准。
如何有明显不一致，需要取2到多个典型场景分别测试
多大测试压力（多少在线用户或者rps是多少）
