1.性能测试的概念
性能测试针对系统的性能指标，建立性能测试模型，制定性能测试方案，制定监控策略，在场景条件下执行性能场景，分析判断性能瓶颈并且调优，最终得出性能结果来评估系统的性能指标是否满足既定值。
针对这个性能测试概念的解读，如下：
性能测试需要有指标：
对应"有指标"这个定义来说，理论上合理的，并且应该有的指标是：时间指标，容量指标，资源利用率指标。
但是这些指标还可以再进行细分.......
性能测试需要有模型：
模型是什么？它是真实场景的抽象。比如说，我们有 100 种业务，但不是每个业务都需要有并发量，可能只有 50 个业务有，那就要把这些有并发的业务统计出来，哪个业务并发多，哪个业务并发少，做压力时就要控制好这样的比例。
其实就是我们需要挑选出来需要并发的业务，还要区分这些业务各自的并发是多少，有不同的并发比例。这些数据最好都是从生产环境获取。
性能测试要有方案：
一个方案中包含着：测试环境、测试数据、测试模型、性能指标、压力策略、准入准出和进度风险这些关键点。
性能测试中要有监控：
这个部分的监控，要有分层、分段的能力，要有全局监控、定向监控的能力
性能测试要有预定的条件：
这里的条件包括软硬件环境、测试数据、测试执行策略、压力补偿等内容 ，在场景执行之前，这些条件应该是确定的。
关于动态扩展，也是有确定的策略的，比如说CPU 使用率达到 80% 或 I/O 响应时间达到 10ms 时，就做动态扩展。
性能测试中要有场景：
对性能场景中的“场景”比较正宗的描述是：在既定的环境（包括动态扩展等策略）、既定的数据（包括场景执行中的数据变化）、既定的执行策略、既定的监控之下，执行性能脚本，同时观察系统各层级的性能状态参数变化，并实时判断分析场景是否符合预期。这才是真正的场景全貌。
性能场景也要有分类
- 基准性能场景：这里要做的是单交易的容量，为混合容量做准备（不要跟我说上几个线程跑三五遍脚本叫基准测试，那只是场景执行之前的预执行，用来确定有没有基本的脚本和场景设计问题，不能称之为一个分类）。
- 容量性能场景：这一环节必然是最核心的性能执行部分。根据业务复杂度的不同，这部分的场景会设计出很多个
- 稳定性性能场景：稳定性测试必然是性能场景的一个分类。只是现在在实际的项目中，稳定性测试基本没和生产一致过。在稳定性测试中，显然最核心的元素是时间（业务模型已经在容量场景中确定了），而时间的设置应该来自于运维周期，而不是来自于老板、产品和架构等这些人的心理安全感
- 异常性能场景：要做异常性能场景，前提就是要有压力。在压力流量之下，模拟异常。这个异常的定义是很宽泛的
性能测试中要有分析调优：
就要不要进行调优做了如下划分
- 新系统性能测试类：这样的项目一般都会要求测试出系统的最大容量，不然上线心里没底。
- 旧系统新版本性能测试类：这样的项目一般都是和旧版本对比，只要性能不下降就可以根据历史数据推算容量，对调优要求一般都不大。
- 新系统性能测试优化类：这类的系统不仅要测试出最大容量，还要求调优到最好
对性能团队的职责定位有如下几种。
- 性能验证：针对给定的指标，只做性能验证。第三方测试机构基本上都是这样做的。
- 性能测试：针对给定的系统，做全面的性能测试，可以得到系统最大容量，但不涉及到调优。
- 性能测试 + 分析调优：针对给定的系统，做全面的性能测试，同时将系统调优到最优状态。
当只能做性能验证的团队遇到旧系统新版本性能测试类和新系统性能测试优化类项目，那就会很吃力，这样的团队只能做新系统性能测试类项目。
当做性能测试的团队，遇到需要新系统性能测试优化类项目，照样很吃力。这样的团队能做前两种项目。
只有第三个团队才能做第三种项目。
性能测试肯定要有结果报告：
性能结果如何来定义呢？有了前面监控的定义，有了场景执行的过程，产生的数据就要整理到结果报告中了。
这个文档工作也是很重要的，是体现性能团队是否专业的一个重要方面。并不是整理一个 Word，美化一下格式就可以了。
测试报告是需要汇报或者归档的。
总结：
在性能测试的概念中，性能指标、性能模型、性能场景、性能监控、性能实施、性能报告，这些既是概念中的关键词，也可以说是性能测试的方法和流程。
2.TPS和响应时间之间是什么关系？
首先，性能要有场景， 性能场景要有基准性能场景、容量性能场景、稳定性性能场景、异常性能场景
然后来看一张图，分析这张图：
在这个图中，定义了三条曲线、三个区域、两个点以及三个状态描述。
- 三条曲线：吞吐量的曲线（紫色）、利用率（绿色）、响应时间曲线（深蓝色）。
- 三个区域：轻负载区（Light Load）、重负载区（Heavy Load）、塌陷区（Buckle Zone）。
- 两个点：最优并发用户数（The Optimum Number of Concurrent Users）、最大并发用户数（The Maximum Number of Concurrent Users）。
- 三个状态描述：资源饱和（Resource Saturated）、吞吐下降（Throughput Falling）、用户受影响（End Users Effected）。
首先，很多时候，重负载区的资源饱和，和 TPS 达到最大值之间都不是在同样的并发用户数之下的。比如说，当 CPU 资源使用率达到 100% 之后，随着压力的增加，队列慢慢变长，响应时间增加，但是由于用户数增加的幅度大于响应时间增加的幅度之前，TPS 仍然会增加，也就是说资源使用率达到饱和之后还有一段时间 TPS 才会达到上限。
大部分情况下，响应时间的曲线都不会像图中画得这样陡峭，并且也不一定是在塌陷区突然上升，更可能的是在重负载区突然上升。
另外，吞吐量曲线不一定会出现下降的情况，在有些控制较好的系统中会维持水平。
有经验的性能测试人员，都会更关心服务端能处理的请求数即 TPS，而不是压力工具中的线程数
这张图没有考虑到锁或线程等配置不合理的场景，而这类场景又比较常见。也就是我们说的，TPS 上不去，资源用不上。所以这个图默认了一个前提，只要线程能用得上，资源就会蹭蹭往上涨。
上图中蓝线表示 TPS，黄色表示响应时间
在 TPS 增加的过程中，响应时间一开始会处在较低的状态，也就是在 A 点之前。接着响应时间开始有些增加，直到业务可以承受的时间点 B，这时 TPS 仍然有增长的空间。再接着增加压力，达到 C 点时，达到最大 TPS。我们再接着增加压力，响应时间接着增加，但 TPS 会有下降（请注意，这里并不是必然的，有些系统在队列上处理得很好，会保持稳定的 TPS，然后多出来的请求都被友好拒绝）。最后，响应时间过长，达到了超时的程度。
用场景的定义来替换这些混乱的概念
通常大家认为的性能测试、负载测试、压力测试在操作的层面，只有压力工具中线程数的区别
在性能中，我们有非常多的配置，像 JVM 参数、OS 参数、DB 参数、网络参数、容器参数等等
在一般的性能场景中，递增都是必不可少的过程。同时，递增的过程，也要是连续的，而不是 100 线程、200 线程、300 线程这样断开执行场景，这样是不合理的。
总之，在具体的性能项目中，性能场景是一个非常核心的概念。因为它会包括压力发起策略、业务模型、监控模型、性能数据（性能中的数据，我一直都不把它称之为模型，因为在数据层面，测试并没有做过什么抽象的动作，只是使用）、软硬件环境、分析模型等
3.怎么理解TPS、QPS、RT、吞吐量这些性能指标？
通常我们都从两个层面定义性能场景的需求指标：业务指标和技术指标。
这两个层面需要有映射关系，技术指标不能脱离业务指标。
这张示意图以便你理解业务指标和性能指标之间的关系
这个示意显然不够详细，但也能说明关系了。所有的技术指标都是在有业务场景的前提下制定的，而技术指标和业务指标之间也要有详细的换算过程。这样一来，技术指标就不会是一块飞地。同时，在回答了技术指标是否满足的同时，也能回答是否可以满足业务指标。
有了这样的关联关系，下面我们看一下性能测试行业常用的性能指标表示法。
QPS 一开始是用来描述 MySQL 中 SQL 每秒执行数 Query Per Second，所有的 SQL 都被称为 Query
QPS 和 TPS 到底是什么关系呢？
RPS 指的是每秒请求数。这个概念字面意思倒是容易理解，但是有个容易误解的地方就是，它指的到底是哪个层面的 Request？如果说 HTTP Request，那么和 Hits Per Second 又有什么关系呢？
HPS，这也是个在字面意思上容易理解的概念。只是 Hit 是什么？有人将它和 HTTP Request 等价，有人将它和用户点击次数等价。
我们都知道 TPS 是性能领域中一个关键的性能指标概念，它用来描述每秒事务数。我们也知道 TPS 在不同的行业、不同的业务中定义的粒度都是不同的。所以不管你在哪里用 TPS，一定要有一个前提，就是所有相关的人都要知道你的 T 是如何定义的。
通常情况下，我们会根据场景的目的来定义 TPS 的粒度。如果是接口层性能测试，T 可以直接定义为接口级；如果业务级性能测试，T 可以直接定义为每个业务步骤和完整的业务流。
用一个示意图来说明一下。
如果我们要单独测试接口 1、2、3，那 T 就是接口级的；如果我们要从用户的角度来下一个订单，那 1、2、3 应该在一个 T 中，这就是业务级的了
当然，这时我们还要分析系统是如何设计的。通常情况下，积分我们都会异步，而库存不能异步哇。所以这个业务，你可以看成只有 1、2 两个接口，但是在做这样的业务级压力时，3 接口也是必须要监控分析的。
所以，性能中 TPS 中 T 的定义取决于场景的目标和 T 的作用。一般我们都会这样来定事务。
接口级脚本：
——事务 start（接口 1）
接口 1 脚本
——事务 end（接口 1）
——事务 start（接口 2）
接口 2 脚本
——事务 end（接口 2）
——事务 start（接口 3）
接口 3 脚本
——事务 end（接口 3）
业务级接口层脚本（就是用接口拼接出一个完整的业务流）：
——事务 start（业务 A）
接口 1 脚本 - 接口 2（同步调用）
接口 1 脚本 - 接口 3（异步调用）
——事务 end（业务 A）
用户级脚本
——事务 start（业务 A）
点击 0 - 接口 1 脚本 - 接口 2（同步调用）
点击 0 - 接口 1 脚本 - 接口 3（异步调用）
——事务 end（业务 A）
你要创建什么级别的事务，完全取决于测试的目的是什么，在性能测试过程中，TPS 之所以重要，是因为它可以反应出一个系统的处理能力。
首先是 QPS，如果它描述的是数据库中的 Query Per Second，从上面的示意图中来看，其实描述的是服务后面接的数据库中 SQL 的每秒执行条数。如果描述的是前端的每秒查询数，那就不包括插入、更新、删除操作了。显然这样的指标用来描述系统整体的性能是不够全面的。所以不建议用 QPS 来描述系统整体的性能，以免产生误解。
RPS（Request per second），每秒请求数。看似简单的理解，但是对于请求数来说，要看是在哪个层面看到的请求，因为请求这个词，实在是太泛了。
HPS（Hits Per Second），每秒点击数。Hit 一般在性能测试中，都用来描述 HTTP Request。当它描述 HTTP Request 时，如果 RPS 也在描述 HTTP Request，那这两个概念就完全一样了。
- 用一个概念统一起来。我觉得直接用 TPS 就行了，其他的都在各层面加上限制条件来描述。比如说，接口调用 1000 Calls/s，这样不会引起混淆。
- 在团队中定义清楚术语的使用层级。
- 如果没有定义使用层级，那只能在说某个概念的时候，加上相应的背景条件。
响应时间 RT
在性能中，还有一个重要的概念就是响应时间（Response Time）。这个比较容易理解。我们接着用这张示意图说明：
RT = T2-T1。计算方式非常直接简单。但是，我们要知道，这个时间包括了后面一连串的链路。
性能测试工具都会记录响应时间，但是，都不会给出后端链路到底哪里慢。经常有人问问题就直接说，我的响应时间很慢。问题在哪呢？在这种情况下，只能回答：不知道。因为我们要先画架构图，看请求链路，再一层层找下去。比如：
所有服务的进出口上都做记录，然后计算结果就行了。在做网关、总线这样的系统时，基本上都会考虑这个功能。而现在，随着技术的发展，链路监控工具和一些 Metrics 的使用，让这个需求变得简单了不少。比如说这样的展示：
它很直观地显示了，在一个请求链路上，每个节点消耗的时间和请求的持续时间。
为什么要性能测试团队来主导 协调其他团队的人一起来分析瓶颈点
举例来说，DB 的 CPU 使用率达到 90% 以上，DBA 会觉得没有问题，因为都是业务的 SQL，并不是 DB 本身有问题。开发觉得 SQL 执行时间慢是因为 DB 有问题，而不是自己写的有问题，因为业务逻辑并没有错，有问题的点应该是 DB 上索引不合理、配置不合理。你看，同样的问题，每个人的看法都有区别。当然也不能排除有些人就是想推诿责任。这时怎么办呢？如果你可以把执行计划拿出来，告诉大家，这里应该创建索引，而那里应该修改业务条件，这时就具体了。
（重点）压力工具中的线程数和用户数与 TPS
但是做性能的都会知道，并发线程数在没有模拟真实用户操作的情况下，和真实的用户操作差别非常远。
现在很多人都没有明白压力工具中的线程数和用户以及 TPS 之间是怎样的关系。同样，我们先画一个示意图来说明一下。
这里先说明一个前提，上面的一个框中有四个箭头，每个都代表着相同的事务。
在说这个图之前，我们要先说明“并发”这个概念是靠什么数据来承载的。
在上面的内容中，我们说了好多的指标，但并发是需要具体的指标来承载的。你可以说，我的并发是 1000TPS，或者 1000RPS，或者 1000HPS，这都随便你去定义。但是在一个具体的项目中，当你说到并发 1000 这样没有单位的词时，一定要让大家都能理解这是什么。
在上面这张示意图中，其实压力工具是 4 个并发线程，由于每个线程都可以在一秒内完成 4 个事务，所以总的 TPS 是 16。这非常容易理解吧。而在大部分非技术人的脑子里，这样的场景就是并发数是 4，而不是 16。
那么用户数怎么来定义呢？涉及到用户就会比较麻烦一点。因为用户有了业务含义，所以有些人认为一个系统如果有 1 万个用户在线，那就应该测试 1 万的并发线程，这种逻辑实在是不技术。通常，我们会对在线的用户做并发度的分析，在很多业务中，并发度都会低于 5%，甚至低于 1%。
拿 5% 来计算，就是 10000 用户 x5%=500(用户级 TPS)，注意哦，这里是 TPS，而不是并发线程数。如果这时响应时间是 100ms，那显然并发线程数是 500TPS/(1000ms/100ms)=50(并发线程)。
通过这样简单的计算逻辑，我们就可以看出来用户数、线程数和 TPS 之间的关系了。
但是！响应时间肯定不会一直都是 100ms 的嘛。所以通常情况下，上面的这个比例都不会固定，而是随着并发线程数的增加，会出现趋势上的关系。
所以，在性能分析中，我一直在强调着一个词：趋势！
业务模型应该如何得到呢？这里有两种方式是比较合理的：
- 根据生产环境的统计信息做业务比例的统计，然后设定到压力工具中。有很多不能在线上直接做压力测试的系统，都通过这种方式获取业务模型。
- 直接在生产环境中做流量复制的方式或压力工具直接对生产环境发起压力的方式做压力测试。这种方式被很多人称为全链路压测。其实在生产中做压力测试的方式，最重要的工作不是技术，而是组织协调能力。相信参与过的人都能体会这句话的重量。
那么响应时间如何设计比较合理呢？这里有两种思路推荐给你。
- 同行业的对比数据。
- 找到使用系统的样本用户（越多越好），对他们做统计，将结果拿出来，就是最有效的响应时间的制定标准。
总结:
今天的这一篇和前两篇文章是一个体系，我利用这三篇文章对当前的性能测试市场上的一些关键概念进行一些拆解。
性能测试策略、性能测试场景、性能测试指标，这些关键的概念在性能测试中深深地影响着很多人。我们简化它的逻辑，只需要记住几个关键字就可以，其他的都不必使用。
- 性能测试概念中：性能指标、性能模型、性能场景、性能监控、性能实施、性能报告。
- 性能场景中：基准场景、容量场景、稳定性场景、异常场景。
- 性能指标中：TPS、RT。 （记住 T 的定义是根据不同的目标来的）
4.JMeter和LoadRunner：要知道工具仅仅只是工具
JMeter、LoadRunner 的基本功能基本就做了两件事情，做脚本和发压力
在性能场景学习期这个阶段，你关心的将不再是工具的使用操作，而是如何做一个合理的性能测试。你可以学会调整业务比例，并设计到压力工具中；你可以学会参数化数据的提取逻辑；你可以学会场景中要观察哪些数据。按照这个思路，再做几个项目，就会慢慢摸着一些门道。
学会使用工具了，也有了场景设计的经验，通过监控工具也拿到了一堆大大小小的数据。可是，数据也太多了，还在不断的变化。我又怎么判断性能瓶颈在哪里呢？
我们应该知道我们针对一个性能压测结果，我需要看什么数据，我想要看什么数据，而不是“把数据都给我看看”。
公司性能团队成长的三个阶段阶段
性能团队初建
这时的团队，可以执行场景，可以拿出数据，但工作出的结果并不理想。团队整体的价值就体现在每天跟着版本跑来跑去，一轮轮地测试下去，一个版本短则一两个星期，长则一个月。没有时间去考虑测试结果对整个软件生命周期的价值，在各种琐碎的项目中疲于奔命。做脚本，拿出 TPS 和响应时间，做版本基线比对，出数据罗列式的性能测试报告。
性能团队初成熟
到了这个阶段，团队已经可以应付版本的更迭带来的性能工作压力，团队合作良好，稍有余力，开始考虑团队价值所在，在公司的组织结构中应该承担什么样的职责。在产品的流水线上终于可以占有一席之地了。这样很好，只是从实际的技术细节上来说，仍然没有摆脱第一阶段中琐碎的工作，没有把性能的价值体现出来，只是一个报告提供机器。这时就需要考虑平台上是不是可以加个 SLA 来限制一下？在各个流程的关卡上，是不是可以做些性能标准？是不是该考虑下准入准出规则了？是的，这时一个团队开始慢慢走向成熟，站住脚之后要开始争取尊重了。
性能团队已成熟
直观上说，主要体现在一下几个方面。
1. 通过你的测试和分析优化之后，性能提升了多少？
一个成熟的团队应该回答的是：提升了 10 倍，我们调优了什么。这样的回答有理有据，底气十足。
2. 通过你的测试和分析优化之后，节省了多少成本？
这个问题就没有那么好回答了，因为你要知道整体的容量规划，线上的真实运营性能。如果之前的版本用了 200 台机器，而通过我们的测试分析优化之后，只用到了 100 台机器，那成本就很明显了。
对个人以及团队来说，工具应该如何选择
比较常见的工具做下比对
所以在压测工具中同时收集监控计数器，就是不符合真实场景的。这样压测平台就有出现的必要了，我们可以看到出现了五花八门的压测平台，也会有后端监控数据的曲线，乍看起来，就两个字：全面！可是，同样也没有告诉你瓶颈在哪里。
压测工具也好，压测平台也好，都没有一个工具可以直接告诉你瓶颈在哪里，能告诉你的只是数据是什么。分析只有靠自己，在这个过程中，我们也会用到很多的分析剖析工具，用这些工具的人也都会知道，工具也只提供数据，不会告诉你瓶颈点在哪里。
如果选择合适自己的工具？
所以我们用工具，一定要知道几点：
- 工具能做什么？
- 工具不能做什么？
- 我们用工具的目标是什么？
- 当工具达不到目标时，我们怎么办？
对企业，举例来说：
如果是一个需要支持万级、亿级 TPS 的电商网站，本身就是云基础架构，那么可能最简单的就是直接买这家的云压测工具就好了。这样做的优点是不用再买机器做压力了。压力发起，主要就是靠压力机的量堆出来大并发
但缺点也很明显，一是不能长期使用，长期用，费用就高了。二是数据也只能自己保存比对，如果测试和版本跨度大，还是要自己比对，无法自动比对。最后一个缺点就是 压力机不受控了。
所以如果有这样需求的企业，也基本上可以自己开发一套云压测工具了，从使用周期和长远的成本上来看，自已开发，都是最划算的。
如果是一个需要支持每秒 100TPS 的企业内部业务系统，就完全没必要买什么云服务了，自己找一台 4C8G 的机器，可能就压得够了。
5.你知道并发用户数应该怎么算吗？
在不同的测试目标中设置不同的事务，也就是 TPS 中的 T 要根据实际的业务产生变化。那么问题又来了，TPS 和并发数是什么关系呢？ 在并发中谁来承载”并发“这个概念呢？
我们先说一下所谓的“绝对并发”和“相对并发”这两个概念。
- 绝对并发指的是同一时刻的并发数；
- 相对并发指的是一个时间段内发生的事情。
什么是并发？
我们假设上图中的这些小人是严格按照这个逻辑到达系统的，那显然，系统的绝对并发用户数是 4。如果描述 1 秒内的并发用户数，那就是 16。是不是显而易见？但是，在实际的系统中，用户通常是这样分配的：
也就是说，这些用户会分布在系统中不同的服务、网络等对象中。这时候”绝对并发“这个概念就难描述了，你说的是哪部分的绝对并发呢？
所以“绝对并发”这个概念，不管是用来描述硬件细化的层面，还是用来描述业务逻辑的层面，都是没什么意义的。
我们只要描述并发就好了，不用有“相对”和“绝对”的概念，这样可以简化沟通，也不会出错。
那么如何来描述上面的并发用户数呢？在这里我建议用 TPS 来承载“并发”这个概念。并发数是 16TPS，就是 1 秒内整个系统处理了 16 个事务。这样描述就够了，别纠结。
在线用户数、并发用户数怎么计算?
在线用户数和并发用户数应该如何算呢？下面我们接着来看示意图：
如上图所示，总共有 32 个用户进入了系统，但是绿色的用户并没有任何动作，那么显然，在线用户数是 32 个，并发用户数是 16 个，这时的并发度就是 50%。
但在一个系统中，通常都是下面这个样子的。
为了能 hold 住更多的用户，我们通常都会把一些数据放到 Redis 这样的缓存服务器中。所以在线用户数怎么算呢，如果仅从上面这种简单的图来看的话，其实就是缓存服务器能有多大，能 hold 住多少用户需要的数据。
最多再加上在超时路上的用户数。如下所示：
所以我们要是想知道在线的最大的用户数是多少，对于一个设计逻辑清晰的系统来说，不用测试就可以知道，直接拿缓存的内存来算就可以了。
假设一个用户进入系统之后，需要用 10k 内存来维护一个用户的信息，那么 10G 的内存就能 hold 住 1,048,576 个用户的数据，这就是最大在线用户数了。在实际的项目中，我们还会将超时放在一起来考虑。
但并发用户数不同，他们需要在系统中执行某个动作。我们要测试的重中之重，就是统计这些正在执行动作的并发用户数。
当我们统计生产环境中的在线用户数时，并发用户数也是要同时统计的。这里会涉及到一个概念：并发度。
要想计算并发用户和在线用户数之间的关系，都需要有并发度。
那么该如何计算或者估算并发度呢？
1. 统计某时段的当前在线用户数；
2. 统计同一时段的操作某个功能的用户数；
3. 把所有功能操作的用户数都统计出来；
4. 将统计出来的用户数除以在线用户数就知道并发度了。
服务端线程的工作情况图在哪看？
java的可以用jvisuamvm之类的工具看
做性能的人都知道，我们有时会接到一个需求，那就是一定要测试出来系统最大在线用户数是多少。这个需求怎么做呢？
很多人都是通过加思考时间（有的压力工具中叫等待时间，Sleep 时间）来保持用户与系统之间的 session 不断，但实际上的并发度非常非常低。
那就是压力工具中的线程或用户数到底是不是用来描述性能表现的？我们通过一个示意图来说明：
通过这个图，我们可以看到一个简单的计算逻辑：
- 如果有 10000 个在线用户数，同时并发度是 1%，那显然并发用户数就是 100。
- 如果每个线程的 20TPS，显然只需要 5 个线程就够了（请注意，这里说的线程指的是压力机的线程数）。
- 这时对 Server 来说，它处理的就是 100TPS，平均响应时间是 50ms。50ms 就是根据 1000ms/20TPS 得来的（请注意，这里说的平均响应时间会在一个区间内浮动，但只要 TPS 不变，这个平均响应时间就不会变）。
- 如果我们有两个 Server 线程（不是压力机线程）来处理，那么一个线程就是 50TPS，这个很直接吧。
- 请大家注意，这里我有一个转换的细节，那就是并发用户数到压力机的并发线程数。这一步，我们通常怎么做呢？就是基准测试的第一步。关于这一点，我们在后续的场景中交待。
而我们通常说的“并发”这个词，依赖 TPS 来承载的时候，指的都是 Server 端的处理能力，并不是压力工具上的并发线程数。在上面的例子中，我们说的并发就是指服务器上 100TPS 的处理能力，而不是指 5 个压力机的并发线程数。
上面说了这么多，我们现在来看一个实例。
这个例子很简单，就是：
JMeter（1 个线程） - Nginx - Tomcat - MySQL
通过上面的逻辑，我们先来看看 JMeter 的处理情况：
summary + 5922 in 00:00:30 = 197.4/s Avg: 4 Min: 0 Max: 26 Err: 0 (0.00%) Active: 1 Started: 1 Finished: 0 summary = 35463 in 00:03:05 = 192.0/s Avg: 5 Min: 0 Max: 147 Err: 0 (0.00%) summary + 5922 in 00:00:30 = 197.5/s Avg: 4 Min: 0 Max: 24 Err: 0 (0.00%) Active: 1 Started: 1 Finished: 0 summary = 41385 in 00:03:35 = 192.8/s Avg: 5 Min: 0 Max: 147 Err: 0 (0.00%) summary + 5808 in 00:00:30 = 193.6/s Avg: 5 Min: 0 Max: 25 Err: 0 (0.00%) Active: 1 Started: 1 Finished: 0 summary = 47193 in 00:04:05 = 192.9/s Avg: 5 Min: 0 Max: 147 Err: 0 (0.00%)
我们可以看到，JMeter 的平均响应时间基本都在 5ms，因为只有一个压力机线程，所以它的 TPS 应该接近 1000ms/5ms=200TPS。从测试结果上来看，也确实是接近的。有人说为什么会少一点？因为这里算的是平均数，并且这个数据是 30s 刷新一次，用 30 秒的时间内完成的事务数除以 30s 得到的，但是如果事务还没有完成，就不会计算在内了；同时，如果在这段时间内有一两个时间长的事务，也会拉低 TPS。
那么对于服务端呢，我们来看看服务端线程的工作情况。
可以看到在服务端，我开了 5 个线程，但是服务端并没有一直干活，只有一个在干活的，其他的都处于空闲状态。这是一种很合理的状态。但是你需要注意的是，这种合理的状态并不一定是对的性能状态。
- 并发用户数（TPS）是 193.6TPS。如果并发度为 5%，在线用户数就是 193.6/5%=3872。
- 响应时间是 5ms。
- 压力机并发线程数是 1。这一条，我们通常也不对非专业人士描述，只要性能测试工程师自己知道就可以了。
下面我们换一下场景，在压力机上启动 10 个线程。结果如下：
summary + 11742 in 00:00:30 = 391.3/s Avg: 25 Min: 0 Max: 335 Err: 0 (0.00%) Active: 10 Started: 10 Finished: 0 summary = 55761 in 00:02:24 = 386.6/s Avg: 25 Min: 0 Max: 346 Err: 0 (0.00%) summary + 11924 in 00:00:30 = 397.5/s Avg: 25 Min: 0 Max: 80 Err: 0 (0.00%) Active: 10 Started: 10 Finished: 0 summary = 67685 in 00:02:54 = 388.5/s Avg: 25 Min: 0 Max: 346 Err: 0 (0.00%) summary + 11884 in 00:00:30 = 396.2/s Avg: 25 Min: 0 Max: 240 Err: 0 (0.00%) Active: 10 Started: 10 Finished: 0 summary = 79569 in 00:03:24 = 389.6/s Avg: 25 Min: 0 Max: 346 Err: 0 (0.00%)
平均响应时间在 25ms，我们来计算一处，(1000ms/25ms)*10=400TPS，而最新刷出来的一条是 396.2，是不是非常合理？
再回来看看服务端的线程：
同样是 5 个线程，现在就忙了很多。
- 并发用户数（TPS）是 396.2TPS。如果并发度为 5%，在线用户数就是 396.2/5%=7924。
- 响应时间是 25ms。
- 压力机并发线程数是 10。这一条，我们通常也不对非专业人士描述，只要性能测试工程师自己知道就可以了。
如果要有公式的话，这个计算公式将非常简单：
下面公司代表个人理解：
理论TPS计算：
TPS=在线用户数*并发度
实际TPS计算：
TPS=1000ms/响应时间(单位ms)∗压力机线程数
对于压力工具来说，只要不报错，我们就关心 TPS 和响应时间就可以了，因为 TPS 反应出来的是和服务器对应的处理能力，至少压力线程数是多少，并不关键。
但是通常服务端都是有业务逻辑的，既然有业务逻辑，显然不会比压力机快。应该说，服务端需要更多的线程来处理压力机线程发过来的请求。所以我们用几台压力机就可以压几十台服务端的性能了。
总结
通过示意图和示例，我描述了在线用户数、并发用户数、TPS（这里我们假设了一个用户只对应一个事务）、响应时间之间的关系。有几点需要强调：
- 通常所说的并发都是指服务端的并发，而不是指压力机上的并发线程数，因为服务端的并发才是服务器的处理能力。
- 性能中常说的并发，是用 TPS 这样的概念来承载具体数值的。
- 压力工具中的线程数、响应时间和 TPS 之间是有对应关系的。