性能测试（一）

1. 性能测试的概念：

性能测试针对系统的性能指标，建立性能测试模型，制定性能测试方案，制定监控策略，在场景条件之下执行性能场景，分析判断性能瓶颈并调优，最终得出性能结果来评估系统的性能指标是否满足既定值。

性能指标：可以是技术指标也可以是业务指标，一般可以分为三类：时间指标、容量指标、资源利用率指标；

性能测试模型：对真实场景的一种抽象；

性能测试方案（通常不包含性能测试计划）：方案中通常有 测试环境、测试数据、测试模型、性能指标、压力策略、准入准出、进度风险；

监控策略：要有全局监控、定向监控的能力。在全局监控发现问题之后再去做定向的监控；

性能场景：性能测试中要有场景。场景的描述是这样的：在既定的环境（包括动态扩展等策略）、既定的数据（包括场景执行中的数据变化）、既定的执行策略、既定的监控之下，执行性能脚本，同时观察系统各层级的性能状态参数变化，并实时判断分析场景是否符合预期。

2. 性能场景

性能场景可以分为如下几类：

1. 基准性能场景：比如单交易的容量（为混合容量做准备），即将每一个业务都压到最大TPS，从而为后续场景做数据比对；
2. 容量性能场景：根据业务复杂度，这部分的场景会设计出很多个，即将所有业务根据比例加到一个场景中，在数据、软硬件环境、监控等的配合下，分析瓶颈并调优的过程；
3. 稳定性性能场景：这个场景中最核心的是时间，时间的设置应当来自于运维周期；
4. 异常性能场景：对应的是破坏性的压力测试。常用的手段是宕主机、宕应用、宕网卡，随着云基础架构的发展，现在我们还有宕容器、宕虚机、宕缓存、宕队列、宕集装箱、宕流控、宕熔断等等。

总结：

3. 性能指标

性能需求指标：技术指标和业务指标。所有的技术指标都是在有业务场景的前提下制定的。

性能测试中的概念：

TPS（Transactions Per Second）：每秒事务数，这个T（事务）具体看你怎么定义，可以是接口级的，也可以是业务级的，用户级的。事务的定义取决于你测试的目标；

RT（Response Time）：响应时间；

压力工具中的线程数：首先，压力工具中的并发线程数不等于真实的用户操作。那么，这里的并发线程数究竟指的是什么？它和用户、TPS有什么样的关系呢？

打个比方：假设并发线程数是4个，每个线程可以在1s内完成4个事务，那么总的TPS就是16。而往往我们会认为并发数是4，而不是16。

4. 性能测试过程中一些概念：

1）怎么理解并发？

谈到并发，大家可能会想到绝对并发和相对并发。绝对并发说的是同一时刻的并发数，相对并发指的是一个时间段内的并发数：

从上面这个图里可以看出来：系统的绝对并发用户数是4，但如果描述1s内的并发用户数，那就是16。

但通常情况下，用户在系统中的表现是这样的：

即这些用户分布在系统中的不同服务、网络等对象中。这时候用绝对并发很难描述清楚。那么，究竟如何描述并发用户数呢？这里我们采用TPS来承载并发这个概念，可以说，并发数是16TPS，即1s内处理了16个事务。

2）在线用户数，并发用户数怎么计算？

如上图，假设一个用户进入系统后，需要用10k内存来维护一个用户的信息，那么10G的内存就能hold住10*1024*1024/10=1048576个用户，这个，就是最大在线用户数了（在实际的项目中，我们会将超时放在一起来考虑） 。

但并发用户数不同，他们需要在系统中执行某个动作，我们要测试的重点，就是统计正在执行动作的并发用户数。

性能测试过程中，我们不仅要统计生产环境的在线用户数，还要统计并发用户数。至于二者之间的关系，一般是由并发度来描述的。

1）假设有10000个在线用户数，同时并发度是1%，那么并发用户数就是100；

2）如果每个线程是20TPS，那么5个线程就能模拟出100TPS了；

3）