Mo小泽的技术博客

非功能体系能力是企业技术能力的全面体现，是技术深度认识的完整概括。

7D性能项目日记9：​性能项目最终是要按目标交付，而不是按过程交付

7D性能项目日记8：​性能项目的目标/进度/深度/费用管理

现如今对使用国密算法加密的接口进行性能测试也逐渐成为是常见的测试场景。使用 JMeter 希望实现更灵活的国密加密测试方式，可以通过对 JMeter 自定义 Java Sampler进行扩展开发来实现。

一个完整的性能项目中一定要有明确的结论，也一定要有明确的瓶颈分析。

7D性能项目日记6：在性能工作中痛苦挣扎的人呀

如果你想在性能市场上生存下去，性能分析的思路一定是重要的能力之一。*

在前面两篇文章中介绍了emqtt-bench工具和MQTT的入门压测，本文示例 emqtt_bench 对 MQTT Broker 做 Beachmark 测试，让大家对 MQTT消息中间 BenchMark 测试有个整体了解，方便平常在压测工作查阅。

真的喜欢这个行业的话，将修炼自己的技术深度、宽度做为信仰，可以让你更值钱，也更受尊重

物联网系统在架构、网络模式、通信协议等方面与传统的互联网系统有所区别。因此，传统的性能测试方法不能直接套用到物联网系统中。

7D性能项目日记3：性能项目的进度如何管控？

MQTT 协议是目前最适合物联网场景数据平台搭建的通信协议。基于此，BenchMark 联网场景中的 MQTT 消息采集与传递，以及如何构建一个百万级，甚至千万级 MQTT 消息平台，可以为物联网业务的企业用户提供平台架构设计参考。

7D性能项目日记2：指标细化和性能环境

7D性能项目日记1：你的性能项目真的有需求指标吗？

sar(System Activity Reporter系统活动情况报告)是目前Linux比较全的系统性能分析工具之一，可以从多方面对系统的活动进行报告 ，包括：文件的读写情况、系统调用的使用情况、磁盘I/O、CPU效率、内存使用状态、进程活动有IPC有关的活动等。

vmstat(VirtualMeomoryStatistics，虚拟内存统计)是一个不错的 Linux/Unix 监控工具，在性能测试中除了top外也是比较常用的工具之一，它可以监控操作系统的 CPU 使用率，内存使用情况，虚拟内存交换情况，以及IO读写情况。与 top 相比各有千秋吧。

本文主要总结解析 TaosKeeper Prometheus Dashboard for 3.x dashboard，让大家对 TDengine 主流监控指标有个整体了解，方便平常在性能监控工作查阅。

技术运营是“**建设运营一体化模式**”大型项目必不可少的保障机制，其包括系统巡检、稳定性保障、数据库管理、信息安全管理以及网络云架构管理等内容。需要成立运行维护机构，建立规范化、标准化、制度化的运行维护体系，制定和监督执行系统运行制度和标准。相关维护遵循信息技术服务标准（ITSS），从项目人员培训及考核、运营工具等资源和技术的利用、安全及时间过程管理等方面制定相应的制度，支持大型项目系统的安全、稳定、高效、持续运行。

本文对常见的几种二开方法进行总结，方便大家学习查阅。

支持合同(UC)，服务提供方与外部供应商就某项服务的提供所签订的合同，外部供应商按服务提供方的要求为顾客提供商品或服务以满足与顾客的SLA中所约定的服务级别目标。运营级别协议（OLA），在SLA的总目标下，为了支持每个环节的具体目标，服务提供方与其内部的某个部门就某项服务签订的协议，从而支持服务提供方所提供的各种服务。服务级别协议（SLA），由服务方和客户之间在一定成本控制下为保障系统的性能和可靠性签订的，描述将要提供的一项或多项双方认可服务的一份协议。产品质量更多的是考虑软件产品或系统本身的质量特性。

面对chatGPT，冷静比鸡血更重要！

这是全局监控可以告诉我们的，而定向监控是让我们找到根本原因的，所以要进入这个机器去查看更细的数据。而我们的要做的就是一步步的找到这些问题，并给出优化方案，像上面的例子中，我们要把sql和io的问题解决，解决的方式要根据瓶颈的原因来提出解决方案。在这个例子中，因为缓存的节点的问题，导致缓存失效，当缓存节点在其他节点自动重建时，tps就恢复了。好多天没写实施日记了，这段时间，我也有些其他事情要做，因为前阵子答应了写些东西，所以这几天晚上弄到两三点，终于写完了五万字的东西交了差。最终我们希望看到的是这样的情况。

我们的这个例子中，由于在前后续步骤中使用的参数化数据不够多，导致后续步骤的数据过于集中，从而更新的时候有大量锁等待的出现。对于网络，我们也进行了基准能力的测试，在公有云的网络结构中，网络传输导致的si cpu已经高达40%，也没啥可调的空间了，毕竟基础的网络也不是我们能控制的。这几天还有连续的企业内训要做，一天从早到晚地干活，感觉回到了我曾经年轻的岁月，那时候天还很蓝、水还很清，项目也很累，但是很快乐。主要是在场景执行的过程中，遇到的问题就不一而足了，脚本问题、参数化问题、网络问题、数据库问题等等。

比如说在登录接口中，递增压力线程直到tps不再上升，然后通过分析压力数据的趋势和全局监控的计数器来判断当前的瓶颈点在哪，给出明确结论。在这样的环境中，没有部门岗位产生的权限壁垒，没有不可见的技术细节，没有因为私心而不愿意做的技术分享，也没有教会学生饿死师傅的担心。根据RESAR性能分析七步法，显然第一步的判断是有瓶颈，而要找到对应的瓶颈点，就得走下面的六步才可以。第二：通过对应用的全局监控和定向监控，可以看到应用的内存初始值过小，ygc还是比较频繁，这是另一个需要优化的瓶颈点。

在解决不了网络流量大小的前提下，先把集中的服务分散，以便使用到不同的云服务器。从图上看，像 innodb_buffer_pool_size、query_cache_size、open_table 之类的相关参数还是要调的，暂时还不知道调了之后的效果。上图中出错的那个点就是调整服务的时候，从上图可以看出调整前后 TPS 是有变化的，从1700到2100左右，增加了400左右。这个执行结果，我觉得还是不错的。我在让大家写分析的过程，希望他们写的东西，也能在后面分享出来，这就取决于文档功底了。

我们放眼现在的性能测试项目，做过的人都知道，很多性能工程师不仅没有开发能力，也理解不了代码的执行逻辑，那也就完全没有理解线程栈的能力。不仅学习了项目的源代码，也给其他的同学做了多次分享。像这种单步调试的分享过程，对一个做性能测试、分析的人来说是非常重要的理解项目代码的过程。我们一直在强调逻辑分析能力，而在项目中，代码逻辑是经常被认为最为核心的性能优化对象。其实这个项目中我们之前在测试的过程中使用过，并且对其中的一些逻辑进行过修改。我们在项目中做这样的分享，我觉得对于没有代码能力的性能工程师非常必要。

自从性能实施项目启动以来，划分的管理组、脚本开发组、环境搭建组、开发组、分析调优组、架构组，都已经各自拉了小群，开始商讨具体工作内容了。这是个很好的现象，驱动起来了，后面就可以完整地看到一个项目的样子。

这也是不合理的，因为数据在不同的脚本中可能是相同的，也有些是需要关联的，这里每个脚本都让不同的人来做，那不是重复的工作量很大吗？也怪我没有说清楚，我是想表达的是，如果有兴趣，你可以参与所有的事情，但是当你不能做现在别人正在做的并且会有冲突的事情，你可以跟他建议，但是不能直接上手。其实这样的沟通是很必要的，就是要统一认识。根据我的经验，性能项目的管理部分做得都是非常潦草的，基本上不怎么管，全靠事情往前推。其实管理组的组长也写了个计划，发给我看了，在任务细分上倒是没有太多的区别，不过是多了产出物和风险的部分。

这个系统，其实我们之前在写专栏的时候也是用过的，是一个开源项目。在这个项目中，我也会根据自己的经验对项目实施过程以及产出物提出严格的要求，争取让所有人都能体会到我对性能项目的。其实在我的想法里，用什么项目并不重要。昨天晚上就组织了一次关于k8s的技术分享，这样的事情在没有我的组织之下，都可以自行开展起来，深感欣慰呀。在这个实施项目中，把RESAR性能工程的每个环节都落地一遍，让所有参与培训的学员都可以参与。如果对于大企业来说，这样的分组还是有点潦草的，还要细分角色职责之类的，并且要和绩效挂钩起来。

今天一同事在压测时提到怎么用 JMeter 里虚拟多个 IP 来发送请求，我想了一下以前用LR时用过虚拟ip地址，JMeter 还没有使用过。想着原理应该是相通的，既然 LR 都能支持的话，那 JMeter 应该也是支持，于是就有了JMeter 虚拟化IP地址的研究。在网上也查找了相应的资料，摸索参考着实践了一把，坑吃了1个来小时吧，还是可行了。所以就以我自己的实践为案例把此操作记录下来，以备遇到同样问题的使用者做参考资源。

古人有句话这样说：“授人以鱼，不如授人以渔”。掌握分析思路才能帮助企业节约资源，让资源使用最大化。我们看到的呈现已经是果，对于果，我们应该怎么去排查的起因呢？这里我们引用《RESAR 性能分析七步法》：根据 《 RESAR 性能分析七步法 》第二步：看架

近几年疫情肆虐，健康码系统和核酸检测系统成了民生的保障。在疫情张狂的时候，这类系统的稳定性、可用性是关键的技术支撑能力。

因为昨天在 7DGroup 的群里有个人一直在问问题，所以约了一个晚上 8 点的会开始直播在线性能分析，针对他的那个系统做一次全面的分析，免得再一直问。

但前端的性能不止在这个页面中得到体现 ，还有更多的工具可以参照。

最近处理了几个项目中的性能问题，来跟大家唠唠。这几个问题是非常常见的。性能瓶颈就有这么个特点，大部分瓶颈分析到最后，都给人有一种猛拍大腿突然醒悟的感觉。但是在分析到具体的原因之前，都是抓耳挠腮，百思不解。这就是性能瓶颈的魅力所在了。问题一：单队列网卡导致软中断高这个问题在专栏也好，公众号文章也好，都不止一次描述过。但是看到过的同学们似乎还是没办法在项目中非常快速地定位出来。问题的现象我就不描述了，无非就是 TPS 压不上去。先看一下这个压力的路径。这是一个清晰的路径。我们直接来说判断的关

用户登录说起来只是一个很普通的功能，不过它的逻辑一点也不简单。因为登录过程要对个人的信息进行对比验证，验证过程中又要调用相应的加密算法，而加密算法是对性能要求很高的一种功能。复杂的加密算法安全性高，但性能就差；不复杂的加密算法性能好，但安全性高，这是一个取舍的问题。

最近觉得很是有点燥。在我主观的意识中，觉得性能测试工程师个人如果不具备性能分析的能力，那这个团队也应该具备。如果性能团队不具备，就应该是有一个虚拟的组织具备，而这个虚拟的组织由产品、架构、开发、测试、运维组成。这个组织的的工作需要串起来，而串起来的这个协调沟通的工作，在性能项目中，显然应该是由性能测试工程师完成。可是在我们实际的工作中，性能测试工程师的职位一直是职低言轻的。从而导致的是，这个协调工作很重的分析过程，根本无法协调下去。对架构、开发、运维来说，他们觉得这个过程应该是性能测试组的活。而性

前言不同的压力工具在参数化的实现逻辑上也会不同，但是参数化必须依赖业务逻辑，而不是工具中能做到什么功能。所以在参数化之前，我们必须分析真实业务逻辑中如何使用数据，再在工具中选择相对应的组合参数的方式去实现。参数化在 Locust 工具中有怎么使用参数化完成工作，在开展工作开始前，先了解 Python 中的一个 Queue 类，queue它是一个队列数据结构是先进先出的数据结构，具体原理大家自己查询即可。Queue种类：FIFO：Queue.Queue(maxsize=0)FIFO即First

文章目录前言脚本示例总结前言最近在学习 Locust 性能工具，发现 Locust 性能工具脚本需要 python 基础才能写脚本，但是对于性能测试人员来说 python 是基本功夫。脚本示例在 Locust 中 get 脚本怎么写，为了方便直接在代码运行调试，采用关闭 web 模式，通过参考官方文档自己实验 get/post 代码，参考代码如： @task(1) def get_7dTest(self): # 定义请求头 header = {

Locust是一个易于使用，分布式，用户负载测试工具。它用于负载测试web站点(或其他系统)并计算一个系统可以处理多少并发用户。