爱分享的淘金达人

在微服务横行的年代，没有链路级监控简直就是灾难。技术在不断的发展过程中，总是会有新的工具被推出来，它们存在的价值就是解决问题。链路监控工具存在的价值就是尽快找到微服务中哪一个环节是最慢的。

在我看来队列服务器是最简单的一种组件了。因为队列给我们下手的机会实在是并不多。我们只是用它，如果想改变它就只能去改代码，其他的都只是配置问题。在当前的市场中，Kafka 算是用得非常火的一个队列服务器了，所以今天，我选择它来做一些解读。虽然我在前面一直在强调分析的思路，但在这一篇中，我打算换个思路，不是像以前那样，直接给你一个结论型的思维导图，而是一起来分析一个组件，让我们看看从哪里下手，来观察一个被分析对象的相关配置。

上一篇文章中，我们讲了有关数据库的全局分析，那么在今天的文章中，我们继续看看在数据库中，如何做定向分析。还记得我在上篇文章中提到的工具吗？mysqlreport、pt-query-digest 和 mysql_exportor+Prometheus+Grafana。我们在上一篇中已经讲完了 mysqlreport，今天我们来看看剩下的这几个。

数据库是一个非常大的话题，我们在很多地方，都会看到对数据库的性能分析会包括以下部分：数据库架构、硬件、操作系统、索引、表结构、应用、存储设备、数据库配置。但其实呢，以上这些内容都是我们应该具备的基础知识，所以我今天要讲的就是，具备了这些基础知识之后我们应该干什么事情。也就是说，从性能瓶颈判断分析的角度入手，才是性能从业人员该有的逻辑。

在当今 Spring Cloud 微服务架构盛行的时代，Tomcat 仍然作为应用最广的应用服务器而存在着，所以我们不得不说一说对它的性能分析。很多时候，我们做性能测试分析时，都会把 Tomcat 这类的应用弄混淆。对它的监控和分析，总是会和 JDK、框架代码、业务代码混合来看，这就导致了分析上的混乱。我们应该把这些分析内容分隔开来，哪些是 tomcat，哪些是 JDK 等。在我看来，Tomcat、WebLogic、JBoss 等，它们都具有同样的分析思路。因为 Tomcat 的市场范围更大。

我经常看到有些人在简历中动辄说自己做过上百个性能项目，以彰显自己有充足的经验。事实上，如果一个性能项目需要做两个星期的话，基本上做不到调优的层面，最多是弄个脚本压个报告。在我的经验中，基本上一个完整的架构级的性能项目从准备开始到写出测试报告、调优报告，需要 1.5 个月以上。你可以想像，这样的项目，就算一年不停地做，做 10 个都算是非常快的了，而要做上百个这样的项目，至少需要 10 年的时间。

写这篇文章的时候，我想起来一句似乎无关紧要的话：“我离你如此之近，你却对我视而不见。”在性能测试中，参数化数据是少有的每个性能测试工程师都会用得到，却经常出现问题的技术点之一。从我的角度来说，究其原因，大部分是因为对性能参数化数据的理解不足。导致的结果就是用了参数化，但和真实的用户场景不一致，从而使得整个性能测试场景都失去了意义。这样的例子不在少数。

这个案例从一个概括的描述开始，到各阶段的分析定位，是一个非常完整的过程。从一个项目的角度上来说，现在是不是性能已经达标，要有两方面的判断。技术方面来说，显然这系统还有很多优化的空间，我们在文中也留了不少的扣。业务方面来说，系统是否可以上线，就取决于业务指标了。但是这个性能是不是已经做得完整了呢？显然还没有。现在只是调了一个节点而已。因为这是在测试环境中做的，硬件环境显得非常简单。线上部署结构也会包括分布式多节点集群等。所以从一个性能项目的角度来说，还远远没有结束

今天我们来看一个真实的案例。事情是这样的，之前有人在微信上问我一个问题，这个问题的现象很典型：典型的 TPS 上不去，响应时间增加，资源用不上。大概的情况是这样的：有两台 4C8G 的服务器，一台服务器上有 2 个 Tomcat，一台服务器上是 DB。压测的混合场景有 4 个功能模块，其中 3 个访问一个 Tomcat，另外一个访问一个 Tomcat。

在大部分的性能项目中，当系统调优到一定程度的时候，性能的瓶颈往往会体现在两类计数器上：一个是 CPU，另一个就是磁盘 I/O 了。所以我们也经常会在一些性能优化的文章中看到两个分类，分别是 CPU 密集型和磁盘 I/O 密集型。有人说为什么不说内存呢？内存是那么重要。不是说内存不会成为瓶颈，只不过内存的瓶颈基本上都可以转嫁给 CPU 和磁盘 I/O。当内存不够的时候，大不了就是清理得快一点。内存能表现出来的，就是满不满，而谁去清理呢？那就是 CPU 了。清理得快就得 CPU 转得快。

在性能分析的人眼里，性能瓶颈就是性能瓶颈。无论这个性能瓶颈出现在代码层、操作系统层、数据库层还是其他层，最终的目的只有一个结果：解决掉！有人可能会觉得这种说法过于霸道。事实上，我要强调的性能分析能力，是一套分析逻辑。在这一套分析逻辑中，不管是操作系统、代码还是数据库等，所涉及到的都只是基础知识。如果一个人都掌握这些内容，那确实不现实，但如果是对一个性能团队的要求，我觉得一点也不高。在性能测试和性能分析的项目中，没有压力发起，就不会有性能瓶颈，也就谈不上性能分析了。所以每个问题的前提，都是要有压力。

在性能分析中，前端的性能工具，我们只需要关注几条曲线就够了：TPS、响应时间和错误率。这是我经常强调的。但是关注 TPS 到底应该关注什么内容，如何判断趋势，判断了趋势之后，又该如何做出调整，调整之后如何定位原因，这才是我们关注 TPS 的一系列动作。今天，我们就通过一个实际的案例来解析什么叫 TPS 的趋势分析。

在性能测试中，我觉得监控是非常重要的环节。因为这是做性能分析的前提，走出这一步，才有后面的分析。监控是性能分析承上启下的关键点。设计监控是我们性能测试工程师必须要做的事情。当然了，仅仅设计监控是不够的，还要看懂监控数据才能分析。我们将在后面的篇幅一一拆解。我觉得性能测试工程师也一定要自己去实现一遍监控的环节，而不是直接用其他团队搭建的监控工具。你可以自己找个 demo 服务器做一遍，这样才能真正理解后续要关注的点在哪里。

在性能测试中，我们要关注的数据主要有以下几类，分别是参数化数据、监控数据和基础铺底数据。我们今天先描述第一种参数化数据，在后面的文章中再描述其他数据。首先我们需要了解，为什么要关注性能场景中的参数化数据呢？我以下面的两个例子说明一下。

因为做性能测试分析的人来说，HTTP 协议可能是绕不过去的一个槛。在讲 HTTP 之前，我们得先知道一些基本的信息。HTTP（HyperText Transfer Protocol，超文本传输协议），显然是规定了传输的规则，但是它并没有规定内容的规则。HTML（HyperText Marked Language，超文本标记语言），规定的是内容的规则。浏览器之所以能认识传输过来的数据，都是因为浏览器具有相同的解析规则。希望你先搞清楚这个区别。

、性能场景中的业务模型是性能测试工作中非常重要的一部分。而在我们真实的项目中，业务模型跟线上的业务模型不一样的情况实在是太多了。原因可能多种多样，这些原因大大降低了性能测试的价值。有人说，就是因为这样才应该直接用生产流量的方式来做嘛，这样就不用管业务模型了，直接就有生产的业务模型了。没错，只要你能通过生产流量扩大回放的方式实现压力部分，确实可以不用考虑业务场景了。但这么做的前提也必须是你的生产流量来源是可以覆盖想要测试的业务场景的。

我们在前面屡次强调了场景的重要性，今天终于到了要把实际场景拿出来解析的时候了。在本篇文章中，为了保证数据的连续性，我用之前的项目资料来作明确地说明。同时为了模糊关键业务信息，以及让场景的描述更通用性，我会把所有的业务名隐去。根据之前我们所说的，基准性能场景是为了测试出单业务的最大容量，以便在混合容量场景中判断哪个业务对整体容量最有影响。

今天的内容，我们对性能测试中的参数化做了一次解析，在执行性能测试时，我们需要根据实际的业务场景选择不同的数据量和参数设置组合。不同的压力工具在参数化的实现逻辑上也会不同，但是参数化必须依赖业务逻辑，而不是工具中能做到什么功能。所以在参数化之前，我们必须分析真实业务逻辑中如何使用数据，再在工具中选择相对应的组合参数的方式去实现。

通常我们会遇到要手写脚本的时候，就要针对一些接口编写脚本。这时候，我们需要知道接口规范和后台的数据是什么。而有些性能测试工程师写脚本时，并不知道后端的逻辑，只知道实现脚本，事实上，只知道实现脚本是远远不够的。在这一篇文章中，我不打算讲复杂的内容，只想针对新手写一步步的操作，描述最简单的脚本编写。如果你已经具有丰富的脚本编写经验，会觉得本文很简单。

对于一个性能测试工具来说，如果能实现以下几大功能，那么就基本上就满足了性能测试工具的功能。录制或编写脚本功能参数化功能关联功能场景功能报告生成功能。有很多性能测试工程师希望工具能做得非常全面，又人性化，而纵观当前的性能工具，真正能够做到傻瓜式录制完脚本，自动设置好参数化、关联、场景，直接产出结果的工具是没有的。不管是云性能测试平台，还是分布式性能测试工具（当然性能测试工具几乎全部具有分布式能力），都需要性能测试人员来定义参数化数据、设置关联、配置场景。

在上一篇文章中，我们讲述了性能场景，下面就要说性能需求指标了。通常我们都从两个层面定义性能场景的需求指标：业务指标和技术指标。这两个层面需要有映射关系，技术指标不能脱离业务指标。一旦脱离，你会发现你能回答“一个系统在多少响应时间之下能支持多少 TPS”这样的问题，但是回答不了“业务状态是什么”的问题。举例来说，如果一个系统要支持 1000 万人在线，可能你能测试出来的结果是系统能支持 1 万 TPS，可是如果问你，1000 万人在线会不会有问题？这估计就很难回答了。

我们在上一篇文章中讲了性能测试的概念，肯定会有人觉得，那些概念很重要，怎么能轻易抹杀呢？那么，在今天的文章中，我们就来扒一扒性能场景，看看概念与实际之间的差别。前面我们说了性能要有场景，也说了性能场景要有基准性能场景、容量性能场景、稳定性性能场景、异常性能场景。在我有限的十几年性能生涯中，从来没有见过有一个性能场景可以超出这几个分类。下面我将对前面说到的概念进行一一对应。

请不要再使用像性能测试、负载测试、容量测试这样的词来概括性能执行策略，这是对实施过程没有任何指导价值的。在性能测试的概念中，性能指标、性能模型、性能场景、性能监控、性能实施、性能报告，这些既是概念中的关键词，也可以说是性能测试的方法和流程。而这些概念我们在实际的工作中，都是非常重要的。因为它们要抹平沟通的误解。让不同层级，不同角色的人，可以在同样的知识背景下沟通，也可以让做事情的人有清晰的逻辑思路，同时对同行间的交流，也有正向的促进作用。

在这一部分中，我会重点给你讲解，为什么要使用某些工具的某些功能，以便确保工具的使用及结果是为性能测试需求指标和性能分析报告而服务的，而不是浮于表面的“炫技”。类似的工作还有很多，正是这些经历让我觉得，在一个性能测试项目中，分析是必然的过程，只有这样，性能测试的工作才有落地的价值。在专栏中，我将以实际的项目经历，告诉你在一个具体的项目是如何一步步落实到性能领域的每一个环节中的。所以，我们努力的方向是性能的完整工程，这就是我在开头提到的，既要有前期的测试，还要有中间的分析，以及最后的调优，而不仅仅是做做脚本。