性能测试中如何 快速确定 并发用户数的 范围？
作者：互联网
我们在性能测试的过程中，有产品经理或技术总监 经常会问：我们的系统 支持多少并发用户数？
为什么我们要关注 并发用户数这个指标呢？
首先来谈谈 为啥 要关注 用户数 这个指标： 在性能测试的过程中，一个线程代表一个 VU（虚拟用户），
随着 并发用户数的增加 理论上被测系统接收到的并发请求数越多，但当并发用户数 并发的请求达到一定的量之后，系统无法继续处理更多的请求；这时会导致系统出现瓶颈甚至可能出现系统崩溃。
我们可能会出现的瓶颈是 系统资源利用率超过警戒值、事务的平均响应时间 延长 甚至有部分的请求超时、系统的处理能力开始下降等。
我们通过利用不用的并发用户数对系统 加压的过程，找出系统的拐点，同时也可以知道 多少个用户同时在线操作 我们的系统是正常的，最大多少用户数操作时 系统会出现性能下降；
这样我们通过这个并发用户数的加压测试过程的得出的 性能指标结果分析，优化我们的 业务性能、架构节点、硬件资源容量、应用程序算法 等等。
因此 寻找系统支撑多少并发用户数 是 寻找系统瓶颈的 一个手段之一。
那我们如何来测试 系统支撑多少并发用户数呢？
我们来设定一个业务场景：
如果 一家医院有20个科室， 每个科室有5个医生 ，每天每个医生看病100个病人 ，单个科室看病5个医生×100个病人= 500人 1天需挂号500病人×20个科室=1万人，看病的周期为5天，则为1万人×5天=5万人。
现在假设有50家医院 则一个礼拜需要处理 5万人×50家医院=250万 个预约挂号操作
假设（这里的数据都是假设） 挂号是每周5晚上22点 开始开放，通过埋点 数据得知： 80%的人会在22点-24点之间 提前预约挂好号。则为2个小时 需要处理 250万*80%=200万笔预约挂号业务。
则2个小时的 处理数据为200万，我们得出TPS=200万/3600/2=277 TPS
设定 1个TPS包含了 5个接口 则qps（预估）=277*5=1385个请求/秒 （这里得到的只是计算出来的预估请求数）
假定 在做单业务基准测试时，拿 这个 预约挂号的 5个接口 单线程 循环迭代1000次，延迟时间为0，运行时间不限制， 跑完 算出 实际的qps = 总的请求数/ 实际运行时间
如果 实际测试的 qps= 50 个请求/秒 ，这里是指1个线程 处理 预约挂号 每秒钟需要处理的 请求。
我们压测过程中就以得出得并发用户数开始压测，可以缩短探索并发用户数的时间，在没有埋点数据得情况下我们就可以通过计算获得预估得初始起点 最小并发用户数。
假定我们每个线程的处理能力都是一样的（实际不一样），这样我们就算出一个 最小的并发用户数（预估）=qps（预估）1385个请求/秒 ÷ 实际测试的qps 50 个请求/秒 =27.7 ≈2
为啥 最小并发用户数 = 预估的qps ÷ 实际测试的qps， 表示的是1个人（1个线程）能够完成的工作量，在相同时间内 要完成 总的工作量，相处就得出 多个人在同一时间完成的工作量。
比如 一个人在1秒钟能够吃1个月饼（实际能力），我现在有10个月饼（预估要达成的目标） 需要在一秒钟吃完，则需要 10个月饼/秒 ÷ 1个月饼/秒 =10个人 同时并发吃月饼。
至于 要吃完 100个月饼，1个人并发的TPS 与 5个人并发的TPS 10个人的TPS 会呈现 先线性增长随后变成 平稳 再到 降低的 一个曲线
这样，我们就可以通过 预估的最小并发用户数 作为测试的 起点 来 进行负载压力测试时，找出系统瓶颈的拐点。得出一个最佳并发用户数、最大并发用户数。
TPS是衡量业务处理能力是否满足系统处理能力的指标。
qps是TPS的另外一种接口请求的技术型表达方式。
吞吐率是通过数据字节的方式 对网络 与 内存等容量单位的 一种评估手段。
资源利用率是评估服务器的软硬件能力瓶颈的表达方式。
中间件的性能指标是 建立在不同的硬件资源服务器和 配置文件配置 以及 节点的基础上的 一个能力，这个中间件的基础能力可以通过中间件自带的 基准性测试工具来测试评估得出。
数据库的性能指标 可以通过2种方式来评估：1是通过基准性测试工具来评估本身的 最佳性能 2是在现有配置情况下业务数据来测试 数据库的 explain、缓存命中率、行数正确性、
覆盖索引不能回表、联合索引不能无限建、给字符串加索引、索引排序问题、数据库内存读写能力、磁盘读写能力、数据库连接池问题等。
标签：请求,并发,TPS,测试,qps,用户数 来源： https://www.cnblogs.com/xiezhifei-testingtechnology/p/16110907.html