性能测试学习一

日期：2024年4月19日
从今日起开始系统更新性能测试学习笔记，一方面督促自身的学习进度，另一方面提高专注力，保持日更。

什么是性能测试

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

性能项目分类

• 新系统性能测试类：一般要求测试出系统的最大容量，不然上线心里没底
• 旧系统新版本性能测试类：一般是和旧版本对比，只要性能不下降旧可以根据历史数据推算容量，一般对调优要求不高
• 新系统性能测试优化类：这样的系统不仅要测试出最大容量，还有调优到最好的需求

对性能团队的职责定位：

• 性能验证：针对给定的指标，只做性能验证。
• 性能测试：针对给定的系统，做全面的性能测试，可以得到系统最大容量，但不涉及调优
• 性能测试+分析调优：针对给定的系统，做全面的性能测试，同时将系统调优到最优状态

性能测试流程

实际情况不会像这张图描绘：

老师理解的部分：

• 重负载区的资源饱和和tps达到最大值之间在很多时候不是在同样的并发数之下的，比如说，当cpu资源使用率达到100%之后，随着压力的增加，队列慢慢变长，但是由于用户数增加的幅度会超过队列长度，所以tps依然会增加，也就是说资源使用率达到饱和之后还有一段时间tps才会达到上限
• 大部分情况下，相应的曲线都不会像这个图中画的这样陡峭，并且也不一定是在塌陷区突然上升的，更可能是在重负载区突然上升
• 吞吐量曲线，不一定会出现下降的情况，在有些控制比较好的系统中会维持水平
• 最优并发数这个点，通常只是一种感觉，而没有绝对的数据来证明，在生产运维的过程中，其实我们大部分人会更加谨慎，而不会定这个点为最优并发，而是更靠前一些
• 最大并发数这个点，就完全没有道理了。性能都已经衰减了 ，最大并发数肯定是在更靠前的位置，应该更加理智的关注tps
• 这个图没有考虑到一些锁或线程配置不合理的场景，而这类场景又比较常见，也就是我们说的tps上不去，资源用不上。这个图默认了一个前提，只要线程能用得上去，资源就会蹭蹭往上长。

【实际中更加合理的图】

A点：最优响应时间点
C点：tps达到最大值，不报错
D点：响应时间很高，tps已经下降，性能衰减的过程
E点：表达超时的一个过程
B点：应该是业务部门给出指标的一个点

场景分类

• 基准场景（单交易容量场景）
  • 验证单业务用户场景的执行
  • 找到单业务的最大tps和最优响应时间
• 容量场景（递增场景，最大tps，最快响应时间场景）
  • 关键点：递增
  • 最核心的性能执行部分
• 稳定性场景（运维最好的状态）
  • 不必拿最大的tps的80%来运行
  • 要考虑运维周期之间的业务累计量
• 异常场景（运维中异常的处理）
  • 保持tps的稳定性

基准场景

容量场景

稳定性场景

场景	作用
基准性能场景	也可称为单交易容量。即将每一个业务都压到最大tps，从而为后续场景做数据对比
容量性能场景	也可以称为混合容量性能场景。即将所有业务根据比例加到一个场景中，在数据、软硬件环境、监控等的配合之下，分析瓶颈并调优的过程
稳定性能场景	核心就是时长，在长时间的运行之下，观察系统的性能表现，分析瓶颈并调优的过程
异常性能场景	显然就是异常的定义最为重要。异常手段有：宕主机、宕应用、宕网卡。随着云基础架构，还有宕容器、缓存、虚拟机、队列、流控、熔断等等

性能指标

简写	英文全称	含义
RT	response time	响应时间，包括请求request和response time
HPS	hits per second	每秒点击数
TPS	transactions per second	每秒事务数
QPS	queries per second	在mysql中指每秒sql数
RPS	requests per second	每秒请求数
CPS	codes for second	在http协议中，cps偶有提及，指的是http返回码每秒
PV	page view	页面浏览量
UV	unique vistior	独立访问者
IP	internet protocol	独立ip数
throught		吞吐量
IOPS	input/output operations per second	描述磁盘

性能指标

分为：业务指标和技术指标

• 业务指标：业务部门给出的指标，例如多少人同时使用，业务场景分布情况
• 技术指标：时间指标（接口响应时间，业务响应时间，用户级别响应时间）、容量指标（接口容量、业务容量）、资源利用率指标（操作系统、jvm等）

并发

在线用户数根据并发度计算出tps 再根据响应时间，计算出并发线程数
TPS=(1/avg(RT))*threadnumber
假设在线用户有10000个，并发度为5%，那么tps就是500tps【这里是tps，并不是并发线程数】，要求响应时间100ms，那么并发数：500tps/（1000ms/100ms）=50（并发线程）

并发度是指的是假设10000个在线用户在某一秒发了多少业务亲请求来计算这个并发度，假如发了100个请求，那么并发度就是1%、发了500个请求，并发度就是5%

在线用户数、并发用户数怎么计算

拿缓存的内存来计算在线的最大用户数
假设一个用户进入系统后，需要用10K内存来维护一个用户信息，那么10G内存能hold住1048576个用户数据【1G=1024MB 1MB=1024KB 1KB=1024B;K是KB简称】，这就是最大的在线用户数。

用户并发数到压力机的并发数转换过程

有 10000 个在线用户数，同时并发度是 1%，那显然并发用户数就是 100tps，如果每个线程的 20TPS，显然只需要 5 个线程就够了（请注意，这里说的线程指的是压力机的线程数）。这时对 Server 来说，它处理的就是 100TPS，平均响应时间是 50ms。50ms 就是根据 1000ms/20TPS 得来的（请注意，这里说的平均响应时间会在一个区间内浮动，但只要 TPS 不变，这个平均响应时间就不会变）。如果我们有两个 Server 线程来处理，那么一个线程就是 50TPS。我们说的并发就是指服务器上 100TPS 的处理能力，而不是指 5 个压力机的并发线程数