性能测试
文章平均质量分 93
weixin_44294159
这个作者很懒,什么都没留下…
展开
-
25丨SkyWalking:性能监控工具之链路级监控及常用计数器解析
对微服务来说,链路监控工具是标配。在性能分析中,需要查看微服务的性能状态时必须用到链路监控工具。我们用 APM 工具要实现的就是以下四点:查看微服务节点的健康状态。判断响应时间的消耗点。通过我们前文中提到的定向监控手段进行详细地问题定位,细化到组件的配置、代码行和 SQL 层级。最后根据定位的根本原因,提出具体的性能瓶颈解决方案。从上面的步骤就可以看出,从性能瓶颈的判断逻辑上,APM 工具给我们提供了很多便利。但是,APM 工具也不能告诉你性能瓶颈的根本原因,因此还是需要定向分析来做细化。原创 2023-06-07 16:37:58 · 229 阅读 · 0 评论 -
24丨Kafka:性能监控工具之队列级监控及常用计数器解析
严格来说,这一篇文章是为了告诉你一个逻辑,那就是对一个组件不了解的时候,如何用你的基础技术知识把对组件的性能优化方向整理出来,以及如何通过自己的基础知识来做一个非常合理的分析。这个逻辑就是:先了解这个组件的基本知识:包括架构、实现原理等信息。再整理出这个组件的配置参数。找到合适的全局监控工具。做压力测试时给出明显的判断。原创 2023-06-07 16:26:51 · 268 阅读 · 0 评论 -
22&23丨MySQL:数据库级监控及常用计数器解析
好了,我们拿一个 mysqlreport 报表从上到下看了一遍之后,你是不是觉得对 MySQL 有点感觉了?这里我给一个结论性的描述吧:在这个性能场景中,慢日志太多了,需要定向监控看慢 SQL,找到慢 SQL 的执行计划。在这个插入多的场景中,锁等待太多,并且等待的时候又太长,解决慢 SQL 之后,这里可能会解决,但还是要分析具体的原因的,所以这里也是指向了 SQL。这里为什么要描述得这么细致呢?主要是因为当你看其他一些工具的监控数据时,分析思路是可以共用的。原创 2023-06-07 16:20:42 · 205 阅读 · 0 评论 -
21丨Tomcat:中间件监控及常用计数器解析
至于其他的 Tomcat 调优参数,你可以在自己的场景中实际操作一下。总之,Tomcat 的优化就是这么几个关键环节:协议、运行模式(尽管现在我认为它已经不再有争议了,但是当你用老版本的 Tomcat 时还是要注意一下)、线程池(关键中的关键)等。不止是 Tomcat 这样,其他类似的应用服务器也是一样。尽管这些应用服务器在架构设计上会不同,但是在我的调优生涯中,针对这样的应用服务器,可调优的关键点真的就这么几个。可见这样的应用服务器本身可调优的点并不多。原创 2023-06-07 15:08:04 · 732 阅读 · 0 评论 -
19&20丨Java & C ++:代码级监控及常用计数器解析
大部分时间里,性能测试和分析都在和时间打交道,而在时间的拆分逻辑中,我们在前面也提到过思路,如何一步步把时间拆解到应用当中,那就是分段。当拆解到应用当中之后,就是抓函数方法的执行时间了。这是保证我们从前到后分析逻辑的关键一环,请你注意,是关键一环,而不是最初的一环。通过这篇文章我想告诉你,在大部分的开发语言中,都有手段直接将方法的执行时间消耗抓出来,你可能现在还不知道是什么方法,没关系,因为跟踪的手段有很多,你可以临时去学习如何操作。原创 2023-06-07 14:38:19 · 203 阅读 · 0 评论 -
17&18丨CentOS:操作系统级监控及常用计数器解析
在操作系统的分析过程中,CPU 绝对是一个重点分析的对象,它的一举一动都牵动着性能分析的人,所以我们需要在 CPU 的高低上花很多的时间去分析判断。幸运的是,当 CPU 使用率高的时候,我们可以有很多的手段来找到对应的根本原因。这个过程不仅分析思路完整,而且工具繁多。它不像网络那么绕,也不像内存那么复杂,逻辑上还是很清楚的。对操作系统的监控及常用计数器的分析会涉及到很多的内容,所以两篇文章可能也是覆盖不全的,我只把在性能测试分析工作中经常见到的计数器解析了一遍。原创 2023-06-07 11:41:29 · 228 阅读 · 0 评论 -
16丨案例:性能监控工具之Grafana+Prometheus+Exporters
为什么要解释数据的逻辑呢?因为最近在工作中遇到一些情况,有人觉得有了 Prometheus+Grafana+Exportor 这样的组合工具之后,基本上都不再用手工执行什么命令了。但我们要了解的是,对于监控平台来说,它取的所有的数据必然是被监控者可以提供的数据,像 node_exporter 这样小巧的监控收集器,它可以获取的监控数据,并不是整个系统全部的性能数据,只是取到了常见的计数器而已。这些计数器不管是用命令查看,还是用这样炫酷的工具查看,它的值本身都不会变。原创 2023-06-06 18:25:04 · 8041 阅读 · 0 评论 -
15丨性能测试场景:如何进行监控设计?
在本篇中,我描述了监控设计的思维逻辑。对架构中的组件进行了分析之后,通过全局—定向的思路列出要看的计数器,再通过相应的监控工具去实现,拿到要分析的数据。这就完成了要做的监控设计和具体实施。至于你是用什么工具去实现的,这并不重要,因为拿到监控数据,可供分析证据链最重要。原创 2023-06-06 15:18:19 · 160 阅读 · 0 评论 -
14丨性能测试场景:如何理解业务模型?
在这一篇中,我描述了业务模型的来源和计算过程。其实就是一些常规的求和平均计算,只要判断出哪一段业务是我们需要的就可以了。另外我也强调了,不管用什么炫酷的手段来实现生产环境的流量模拟,最终的目标是实现和线上比较接近的业务模型。不是说一定用生产流量回放才是正确的,只有适合自己企业的手段才是最正确的。原创 2023-06-06 14:37:27 · 160 阅读 · 0 评论 -
13丨性能测试场景:如何进行场景设计?
在对基准场景、容量场景、稳定性场景和异常场景做了详细的,有逻辑的描述之后,相信你已经能体会到场景的博大精深了。在本篇中,由于字数有限,我只对场景的具体执行过程中的关键点做了细致地描述。但是场景绝对不止这些哦,还有很多细节的内容。同时,为了让理解更为清晰,这里我只描述了场景本身,场景包括的其他内容,比如说参数设计、监控设计等等,在本篇中都没有描述。从这里,你大概能明白我说的场景对性能有多么重要了吧。希望今天的这篇文章能给你在设计性能场景时提供参考。原创 2023-06-06 14:12:12 · 405 阅读 · 0 评论 -
12丨性能场景:做参数化之前,我们需要考虑什么?
在今天的文章中,需要你领悟到的是,参数化数据的合理性对性能场景有着举足轻重的作用。通常,我们在做参数化数据之前,需要先分析实际业务的逻辑。比如说:什么数据是唯一的?什么数据是可重复使用的?数据是客户主动输入,后端只保存即可,还是客户输入后,后端需要比对?这些都是我们在做参数化之前要分析的部分。而参数化的数据量的重要性,不仅和业务需求相关,也和数据存储和查询的方式相关。这个话题我们在后面也会讨论到。原创 2023-06-06 11:57:52 · 88 阅读 · 0 评论 -
11丨性能脚本:用案例和图示帮你理解HTTP协议
对于 HTTP 协议来说,我们在性能分析中,主要关心的部分就是传输字节的大小、超时的设置以及压缩等内容。在编写脚本的时候,要注意 HTTP 头部,至于 Body 的内容,只要能让业务跑起来即可。原创 2023-06-06 11:43:03 · 81 阅读 · 0 评论 -
10丨案例:在JMeter中如何设置参数化数据?
通过今天的内容,我们对性能测试中的参数化做了一次解析,在执行性能测试时,我们需要根据实际的业务场景选择不同的数据量和参数设置组合。不同的压力工具在参数化的实现逻辑上也会不同,但是参数化必须依赖业务逻辑,而不是工具中能做到什么功能。所以在参数化之前,我们必须分析真实业务逻辑中如何使用数据,再在工具中选择相对应的组合参数的方式去实现。这里我总结一下性能工作中参数化的逻辑,希望对你有所启发。分析业务场景;罗列出需要参数化的数据及相对应的关系;将参数化数据从数据库中取出或设计对应的生成规则;原创 2023-06-06 10:46:49 · 163 阅读 · 0 评论 -
09丨关联和断言:一动一静,核心都是在取数据
实际上,关联和断言的前半部分是一样的,都是从服务器返回信息中取出数据。但不同的是,关联取来的数据每次都会不同;而断言取出来的数据基本上都是一样的,除非出了错。对服务端生成的,并且每次生成都不一样的动态变化的数据,那么将其取回来之后,在后续的请求中使用,这种逻辑就是关联。对服务端返回的,可标识业务成功与否的数据,将其取回来之后,做判断。这种逻辑就是断言。原创 2023-06-06 10:38:39 · 43 阅读 · 0 评论 -
07丨性能测试工具:如何录制脚本?
这篇文章,应该是我写的所有的文章中,最最基础的一篇了,并且,从操作上,一步步地描述,也比较清晰。如果你有性能工具使用经验,肯定会觉得这篇过于简单。可是为什么还要写呢?因为在性能测试的过程中,有很多新手对录制的逻辑并不清楚。代理录制的这个动作他们也可以很快学会。但是很快就忘记了,我曾经给一些人手把手教过如何做代理录制。结果第二天就不记得了。其实并不是不记得动作,而是出了问题,脑子里没有判断问题的逻辑,所以根本无从下手排查。另外,你需要注意的是,录制功能并不是性能测试工具必备的功能。原创 2023-06-05 17:21:16 · 1167 阅读 · 0 评论 -
08丨案例: 手把手教你编写最简单的性能脚本
其实这篇文章只想告诉你一件事情,手工编写脚本,从基础上说,是非常简单的,只是有三点需要特别强调:涉及到业务规则和逻辑判断之后,编写脚本就复杂了起来。但是了解业务规则是做脚本的前提条件,也是性能测试工程师的第一步。编写脚本的时候,要知道后端的逻辑。这里的意思不是说,你一开始写脚本的时候,就要去读后端的代码,而是说你在遇到问题的时候,要分析整个链路上每个环节使用到了什么技术,以便快速地分析判断。写脚本是以最简为最佳,用不着故意复杂。原创 2023-06-05 17:32:48 · 351 阅读 · 0 评论 -
06丨性能分析思路
在这一篇中,我说到了瓶颈的精准判断、线程递增的策略、性能衰减的过程、响应时间的拆分、构建分析决策树以及场景的比对,这几个环节,是性能分析过程中非常重要的环节。从我的经验上来说,这一篇文章可能是我工作十几年的精华所在了。而这里的每一个环节,又有非常多的细分,特别是构建分析决策树这一块,它需要太多的架构知识、系统知识、数据库知识等等。鉴于本文只是想起到一个提纲挈领的作用,所以无法展开描述,希望在后续的篇幅中,我们尽量细致拆解。原创 2023-06-05 15:17:56 · 90 阅读 · 0 评论 -
05丨指标关系:你知道并发用户数应该怎么算吗?
下面我们就来说一下“并发”这个概念。我们假设上图中的这些小人是严格按照这个逻辑到达系统的,那显然,系统的绝对并发用户数是 4。如果描述 1 秒内的并发用户数,那就是 16。是不是显而易见?但是,在实际的系统中,用户通常是这样分配的:也就是说,这些用户会分布在系统中不同的服务、网络等对象中。这时候”绝对并发“这个概念就难描述了,你说的是哪部分的绝对并发呢?要说积分服务,那是 2;要说库存服务,那是 5;原创 2023-06-05 13:39:13 · 311 阅读 · 1 评论 -
04丨JMeter和LoadRunner:要知道工具仅仅只是工具
总体来说,性能测试工具的市场中,可以说现在的工具已经种类繁多了,并且各有优点。在项目中,根据具体的实施成本及企业中的规划,选择一个最适合的就可以了。也可以用它们来组建自己的平台。但是请注意, 不要觉得做平台可以解决性能测试的问题,其实平台只是解决了人工的成本。如果单纯为了追潮流而把性能测试工具的使用成本升得特别高,那就不划算了。原创 2023-06-05 10:57:26 · 176 阅读 · 1 评论 -
03丨性能综述:怎么理解TPS、QPS、RT、吞吐量这些性能指标?
今天的这一篇和前两篇文章是一个体系,我利用这三篇文章对当前的性能测试市场上的一些关键概念进行一些拆解。性能测试策略、性能测试场景、性能测试指标,这些关键的概念在性能测试中深深地影响着很多人。我们简化它的逻辑,只需要记住几个关键字就可以,其他的都不必使用。性能测试概念中:性能指标、性能模型、性能场景、性能监控、性能实施、性能报告。性能场景中:基准场景、容量场景、稳定性场景、异常场景。性能指标中:TPS、RT。(记住 T 的定义是根据不同的目标来的)有了这些之后,一个清晰的性能框架就已经出现了。原创 2023-06-02 17:48:49 · 392 阅读 · 1 评论 -
02丨性能综述:TPS和响应时间之间是什么关系?
总之,在具体的性能项目中,性能场景是一个非常核心的概念。因为它会包括压力发起策略、业务模型、监控模型、性能数据(性能中的数据,我一直都不把它称之为模型,因为在数据层面,测试并没有做过什么抽象的动作,只是使用)、软硬件环境、分析模型等。有了清晰的、有逻辑的场景概念之后,在后面的篇幅当中,我们将从场景的各个角度去拆解。在本专栏中,我们将保持理念的连贯性,以示我不变的职业初心。原创 2023-06-02 14:19:37 · 189 阅读 · 1 评论 -
01丨性能综述:性能测试的概念到底是什么?
高楼:性能测试实战原创 2023-06-02 13:54:39 · 151 阅读 · 1 评论