通常我们都从两个层面定义性能场景的需求指标：业务指标和技术指标。这两个层面需要有映射关系，技术指标不能脱离业务指标。一旦脱离，你会发现你能回答”一个系统在多少响应时间之下能支持多少 TPS“这样的问题，但是回答不了”业务状态是什么“的问题。
举例来说，如果一个系统要支持 1000 万人在线，可能你能测试出来的结果是系统能支持 1 万 TPS，可是如果问你，1000 万人在线会不会有问题？这估计就很难回答了。我在这里画一张示意图以便你理解业务指标和性能指标之间的关系。
这个示意显然不够详细，但也能说明关系了。所有的技术指标都是在有业务场景的前提下制定的，而技术指标和业务指标之间也要有详细的换算过程。这样一来，技术指标就不会是一块飞地。同时，在回答了技术指标是否满足的同时，也能回答是否可以满足业务指标。有了这样的关联关系，下面我们看一下性能测试行业常用的性能指标表示法。
QPS 一开始是用来描述 MySQL 中 SQL 每秒执行数 Query Per Second，所有的 SQL 都被称为 Query。后来，由于一些文章的转来转去，QPS 被慢慢地移到了压力工具中，用来描述吞吐量，于是这里就有些误解，QPS 和 TPS 到底是什么关系呢？
RPS 指的是每秒请求数。这个概念字面意思倒是容易理解，但是有个容易误解的地方就是，它指的到底是哪个层面的 Request？如果说 HTTP Request，那么和 Hits Per Second 又有什么关系呢？
HPS，这也是个在字面意思上容易理解的概念。只是 Hit 是什么？有人将它和 HTTP Request 等价，有人将它和用户点击次数等价。
CPS，用的人倒是比较少，在性能行业中引起的误解范围并不大。同时还有喜欢用 CPM（Calls Per Minute，每分钟调用数）的。这两个指标通常用来描述 Service 层的单位时间内的被其他服务调用的次数，这也是为什么在性能行业中误解不大的原因，因为性能测试的人看 Service 层东西的次数并不多。
为了区分这些概念，我们先说一下 TPS（Transactions Per Second）。我们都知道 TPS 是性能领域中一个关键的性能指标概念，它用来描述每秒事务数。我们也知道 TPS 在不同的行业、不同的业务中定义的粒度都是不同的。所以不管你在哪里用 TPS，一定要有一个前提，就是所有相关的人都要知道你的 T 是如何定义的。
经常有人问，TPS 应该如何定义？这个实在是没有具体的“法律规定”，那就意味着，你想怎么定就怎么定。通常情况下，我们会根据场景的目的来定义 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 的 T 是什么，下面就要说什么是 TPS 了。字面意思非常容易理解，就是：每秒事务数。在性能测试过程中，TPS 之所以重要，是因为它可以反应出一个系统的处理能力。我在很多场景中都说过，事务就是统计了一段脚本的执行时间，并没有什么特别的含义。而现在又多加了其他的几个概念。
首先是 QPS，如果它描述的是数据库中的 Query Per Second，从上面的示意图中来看，其实描述的是服务后面接的数据库中 SQL 的每秒执行条数。如果描述的是前端的每秒查询数，那就不包括插入、更新、删除操作了。显然这样的指标用来描述系统整体的性能是不够全面的。所以不建议用 QPS 来描述系统整体的性能，以免产生误解。
RPS（Request per second），每秒请求数。看似简单的理解，但是对于请求数来说，要看是在哪个层面看到的请求，因为请求这个词，实在是太泛了。我们把上面的图做一点点变化来描述一下请求数。
如果一个用户点击了一次，发出来 3 个 HTTP Request，调用了 2 次订单服务，调用了 2 次库存服务，调用了 1 次积分服务，那么这个 Request 该如何计算？如果你是算 GDP 的专家，我觉得可能会是：3+2+2+1=8（次）。而在具体的项目中，我们会单独描述每个服务，以便做性能统计。如果要描述整体，最多算是有 3 个 RPS。如果从 HTTP 协议的角度去理解，那么 HTTP Request 算是一个比较准确的描述了，但它本身的定义并没有包含业务。如果赋予它业务的含义，那么用它来描述性能也是可以的。
HPS（Hits Per Second），每秒点击数。Hit 一般在性能测试中，都用来描述 HTTP Request。但是，也有一些人用它描述真正的客户在界面上的点击次数。关于这一点，就只有在具体的项目中才能规定得具体一些。当它描述 HTTP Request 时，如果 RPS 也在描述 HTTP Request，那这两个概念就完全一样了。
CPS/CPM：Calls Per Second/ Calls Per Minutes，每秒 / 每分钟调用次数。这个描述在接口级是经常用到的，比如说上面的订单服务。显然一次客户界面上的点击调用两次。这个比较容易理解。但是，在操作系统级，我们也经常会听到系统调用用 call 来形容，比如说用 strace 时，你就会看见 Calls 这样的列名。
这些概念本身并没有问题，但是当上面的概念都用来描述一个系统的性能能力的时候，就混乱了。对于这种情况，我觉得有几种处理方式：
- 用一个概念统一起来。我觉得直接用 TPS 就行了，其他的都在各层面加上限制条件来描述。比如说，接口调用 1000 Calls/s，这样不会引起混淆。
- 在团队中定义清楚术语的使用层级。
- 如果没有定义使用层级，那只能在说某个概念的时候，加上相应的背景条件。
所以，当你和同事在沟通性能指标用哪些概念时，应该描述得更具体一些。在一个团队中，应该先有这些术语统一的定义，再来说性能指标是否满足。
在性能中，还有一个重要的概念就是响应时间（Response Time）。这个比较容易理解。我们接着用这张示意图说明：
RT = T2-T1。计算方式非常直接简单。但是，我们要知道，这个时间包括了后面一连串的链路。响应时间的概念简单至极，但是，响应时间的定位就复杂了。性能测试工具都会记录响应时间，但是，都不会给出后端链路到底哪里慢。经常有人问问题就直接说，我的响应时间很慢。问题在哪呢？在这种情况下，只能回答：不知道。因为我们要先画架构图，看请求链路，再一层层找下去。比如说这样：
在所有服务的进出口上都做记录，然后计算结果就行了。在做网关、总线这样的系统时，基本上都会考虑这个功能。而现在，随着技术的发展，链路监控工具和一些 Metrics 的使用，让这个需求变得简单了不少。比如说这样的展示：
它很直观地显示了，在一个请求链路上，每个节点消耗的时间和请求的持续时间。我顺便在这里说一下调优在当前性能项目中的状态。
对于响应时间来说，时间的拆分定位是性能瓶颈定位分析中非常重要的一节。但是请注意，这个环节并不是性能测试工程师的最后环节。在工作中，我经常看到有很多性能测试工程师连时间拆分都不做，只报一个压力工具中看到的响应时间，就给一个通过不通过的结论，丝毫没有定位。
另外，有一些性能测试工程师，倒是用各种手段分析了时间的消耗点，但是也觉得自己的工作就此结束了，而不做根本原因的分析或协调其他团队来分析。当然在不同的企业里，做分析的角色和要求各不相同，所以也要根据实际的企业现状来说。
在我的观点中，性能只测不调，那就是性能验证的工作，称不上是完整的性能项目。第三方性能测试的机构可以这样做，但是在一个企业内部这样做的话，性能团队的价值肯定就大打折扣了。 但是现在有很多人都不把性能调优做为性能团队的工作，主要原因有几点：
- 性能测试团队的人能力有限做不到；
- 性能调优代价高，耗时长，不值得做。
因为每个技术人员对性能瓶颈的定义并不相同，如果不细化到具体的计数器的值是多少才有问题，有误解的可能性就很大。
举例来说，DB 的 CPU 使用率达到 90% 以上，DBA 会觉得没有问题，因为都是业务的 SQL，并不是 DB 本身有问题。开发觉得 SQL 执行时间慢是因为 DB 有问题，而不是自己写的有问题，因为业务逻辑并没有错，有问题的点应该是 DB 上索引不合理、配置不合理。
这时怎么办呢？如果你可以把执行计划拿出来，告诉大家，这里应该创建索引，而那里应该修改业务条件，这时就具体了。
总是有很多人在并发线程数和 TPS 之间游荡，搞不清两者的关系与区别。这两个概念混淆的点就是，好像线程是真实的用户一样，那并发的线程是多少就描述出了多少真实的用户。但是做性能的都会知道，并发线程数在没有模拟真实用户操作的情况下，和真实的用户操作差别非常远。
在 LoadRunner 还比较红火的时候，Mercury 提出一个 BTO 的概念，就是业务科技优化。在 LoadRunner 中也提出”思考时间“的概念，其实在其他的性能工具中是没有”思考时间“这个词的。这个词的提出就是为了性能工具模拟真实用户。
但是随着性能测试的地位不断下降，以及一些概念和名词不断地被以讹传讹，导致现在很多人都没有明白压力工具中的线程数和用户以及 TPS 之间是怎样的关系。同样，我们先画一个示意图来说明一下。
这里先说明一个前提，上面的一个框中有四个箭头，每个都代表着相同的事务。在说这个图之前，我们要先说明”并发“这个概念是靠什么数据来承载的。
在上面的内容中，我们说了好多的指标，但并发是需要具体的指标来承载的。你可以说，我的并发是 1000TPS，或者 1000RPS，或者 1000HPS，这都随便你去定义。但是在一个具体的项目中，当你说到并发 1000 这样没有单位的词时，一定要让大家都能理解这是什么。
在上面这张示意图中，其实压力工具是 4 个并发线程，由于每个线程都可以在一秒内完成 4 个事务，所以总的 TPS 是 16。这非常容易理解吧。而在大部分非技术人的脑子里，这样的场景就是并发数是 4，而不是 16。
要想解释清楚这个非常困难，我的做法就是，直接告诉别人并发是 16 就好了，不用关心 4 个线程这件事。这在我所有项目中几乎都是一样的，一直也没有什么误解。
那么用户数怎么来定义呢？涉及到用户就会比较麻烦一点。因为用户有了业务含义，所以有些人认为一个系统如果有 1 万个用户在线，那就应该测试 1 万的并发线程，这种逻辑实在是不技术。通常，我们会对在线的用户做并发度的分析，在很多业务中，并发度都会低于 5%，甚至低于 1%。
拿 5% 来计算，就是 10000 用户 x5%=500(TPS)，注意哦，这里是 TPS，而不是并发线程数。如果这时响应时间是 100ms，那显然并发线程数是 500TPS/(1000ms/100ms)=50(并发线程)。通过这样简单的计算逻辑，我们就可以看出来用户数、线程数和 TPS 之间的关系了。
但是！响应时间肯定不会一直都是 100ms 的嘛。所以通常情况下，上面的这个比例都不会固定，而是随着并发线程数的增加，会出现趋势上的关系。
业务模型的 28 原则？
我看到有些文章中写性能测试要按 28 原则来计算并发用户数。大概的意思就是，如果一天有 1000 万的用户在使用，系统如果开 10 个小时的话，在计算并发用户数的时候，就用 2 小时来计算，即 1000 万用户在 2 小时内完成业务。
这个逻辑在一个特定的业务系统中是没有任何价值的。因为每个系统的并发度都由业务来确定，而不是靠这样的所谓的定律来支配着业务。
如果我们做了大量的样本数据分析，最后确实得出了 28 的比例，我觉得那也是可以的。但是如果什么数据都没有分析，直接使用 28 比例来做评估和计算，那就跟耍流氓没有区别。
业务模型应该如何得到呢？这里有两种方式是比较合理的：
- 根据生产环境的统计信息做业务比例的统计，然后设定到压力工具中。有很多不能在线上直接做压力测试的系统，都通过这种方式获取业务模型。
- 直接在生产环境中做流量复制的方式或压力工具直接对生产环境发起压力的方式做压力测试。这种方式被很多人称为全链路压测。其实在生产中做压力测试的方式，最重要的工作不是技术，而是组织协调能力。相信参与过的人都能体会这句话的重量。
响应时间的 258 原则合理吗？
对于响应时间，有很多人还在说着 258 或 2510 响应时间是业内的通用标准。然后我问他们这个标准的出处在哪里？谁写的？背景是什么？几乎没有人知道。真是不能想像，一个谁都不知道出处的原则居然会有那么大的传播范围，就像谣言一样，出来之后，再也找不到源头。
其实这是在 80 年代的时候，英国一家 IT 媒体对音乐缓冲服务做的一次调查。在那个年代，得到的结果是，2 秒客户满意度不错；5 秒满意度就下降了，但还有利润；8 秒时，就没有利润了。于是他们就把这个统计数据公布了出来，这样就出现了 258 principle，翻译成中文之后，它就像一个万年不变的定理，深深影响着很多人。
距离这个统计结果的出现，已经过去快 40 年了，IT 发展的都能上天了，这个时间现在已经完全不适用了。所以，以后出去别再提 258/2510 响应时间原则这样的话了，太不专业。
那么响应时间如何设计比较合理呢？这里有两种思路推荐。
- 同行业的对比数据。
- 找到使用系统的样本用户（越多越好），对他们做统计，将结果拿出来，就是最有效的响应时间的制定标准。
性能指标的计算方式
我们在网上经常可以看到有人引用这几个公式。
公式（1）：
并发用户数计算的通用公式：C=TnL
其中 C 是平均的并发用户数；n 是 login session 的数量；L 是 login session 的平均长度；T 指考察的时间段长度。
公式（2）：
并发用户数峰值： C’≈C+³√C
C’指并发用户数的峰值，C 就是公式（1）中得到的平均的并发用户数。该公式是假设用户的 login session 产生符合泊松分布而估算得到的。
仔细搜索之后发现会发现这两个公式的出处是 2004 年一个叫 Eric Man Wong 的人写的一篇名叫《Method for Estimating the Number of Concurrent Users》的文章。中英文我都反复看到很多篇。同时也会网上看到有些文章中把这个文章描述成“业界公认”的计算方法。在原文中，有几个地方的问题。
- C 并不是并发用户，而是在线用户。
- 这两个公式做了很多的假设条件，比如说符合泊松分布什么的。为什么说这个假设有问题？我们都知道泊松分布是一个钟型分布，它分析的是一个系统在全周期中的整体状态。
- 如果要让它在实际的项目中得到实用，还需要有大量的统计数据做样本，代入计算公式才能验证它的可信度。
- 峰值的计算，我就不说了，我觉得如果你是做性能的，应该一看就知道这个比例不符合大部分真实系统的逻辑。
- 有些人把这两个公式和 Little 定律做比较。我要说 Little 定律是最基础的排队论定律，并且这个定律只说明了：系统中物体的平均数量等于物体到达系统的平均速率和物体在系统中停留的平均时间的乘积。我觉得这句话，就跟秦腔中的”出门来只觉得脊背朝后“是一样一样的。
有人说应该如何来做系统容量的预估呢。我们现在很多系统的预估都是在一定的假设条件之下的，之所以是预估，说明系统还不在，或者还没达到那样的量。在这种情况下，我们可以根据现有的数据，做统计分析、做排队论模型，进而推导以后的系统容量。
