性能测试
文章平均质量分 94
性能测试
_Rye_
左手代码右手诗
一行代码一行诗
展开
-
32丨当Postgres磁盘读引起I/O高的时候,应该怎么办?
在性能分析的道路上,我们会遇到各种杂七杂八的问题。很多时候,我们都期待着性能测试中的分析像破案一样,并且最好可以破一个惊天地泣鬼神的大案,以扬名四海。然而分析到了根本原因之后,你会发现优化的部分是如此简单。其实对于 PostgreSQL 数据库来说,像 buffer、log、replication 等内容,都是非常重要的分析点,在做项目之前,我建议先把这样的参数给收拾一遍,不要让参数配置成为性能问题,否则得不偿失。原创 2024-03-12 20:36:17 · 875 阅读 · 0 评论 -
31丨案例:当磁盘参数导致I/O高的时候,应该怎么办?
不管是什么样的性能问题,其实从分析思路上仍然逃不开我一直提到的思路——那就是一个分析的完整链路。当你一层一层往下找问题时,只要抓住了重点,思路不断,找到根本原因就可以解决问题。在这个 I/O 的问题中,难点在于怎么能知道 jbd2 的原理和参数。应该说,不管是谁,都不能保证自己的知识体系是完整的,那怎么办呢?查资料,各种学习,看源码,看逻辑。实在看不懂,那也没办法,接着修炼基础内功呗。所以说性能测试行业中,经常只测不分析,也是因为做性能分析需要的背景知识量有点大,还要不断分析各种新的知识点。原创 2024-03-12 18:07:26 · 954 阅读 · 1 评论 -
30丨案例:为什么参数化数据会导致TPS突然下降?
很多性能问题,在出现的时候,都会觉得无从下手,而当分析到根本原因的时候,就觉得啼笑皆非。但很多时候,在真实的场景中,很多性能问题连原因都没有分析出来,连啼笑皆非的机会都没有,就开始寻找规避的手段了,这就像用一个坑去埋另一个坑,于是大坑套小坑、小坑套水洼。还有,在做性能分析的时候,有经验固然是好事,但是经验也并不是在所有的场景中都能有效地帮你解决问题,相反,它们有时也会成为累赘,成为判断出现偏差的原因。原创 2024-03-12 17:30:38 · 880 阅读 · 0 评论 -
29丨案例:如何应对因网络参数导致的TPS呈锯齿状?
性能问题总是层出不穷,不管你以前多有经验,都可能会遇到不懂的性能问题。如果建立了分析问题的思路逻辑,并且又善于学习和查找各种资料,找到根本原因,最后都会给出完整的解决方案。这个案例应该说是个比较偏门的性能问题了,解决问题的思路就是我上面说的那样。其实你也可以看到,有很多时候,我们的性能问题和代码并没有关系,所以这里也提醒那些一玩性能就想看代码的人,眼光要放开阔一些。还有就是遇到性能问题时,一定要记住,不要慌!原创 2024-03-12 17:25:09 · 978 阅读 · 0 评论 -
28丨案例:带宽消耗以及Swap(下)
这个案例从一个概括的描述开始,到各阶段的分析定位,是一个非常完整的过程。从一个项目的角度上来说,现在是不是性能已经达标,要有两方面的判断。1. 技术方面来说,显然这系统还有很多优化的空间,我们在文中也留了不少的扣。2. 业务方面来说,系统是否可以上线,就取决于业务指标了。但是这个性能是不是已经做得完整了呢?显然还没有。现在只是调了一个节点而已。因为这是在测试环境中做的,硬件环境显得非常简单。线上部署结构也会包括分布式多节点集群等。所以从一个性能项目的角度来说,还远远没有结束。原创 2024-03-12 16:50:36 · 858 阅读 · 0 评论 -
27丨案例:带宽消耗以及Swap(上)
带宽问题是性能分析中常见的问题之一,其难点就在于,带宽不像 CPU 使用率那么清晰可理解,它和 TCP/IP 协议的很多细节有关,像三次握手,四次挥手,队列长度,网络抖动、丢包、延时等等,都会影响性能,关键是这些判断点还不在同一个界面中,所以需要做分析的人有非常明确的分析思路才可以做得到。而且现在的监控分析工具中,对网络的判断也是非常薄弱的。而 Swap 问题不能算是常见,只要出现,基本上就会很多人晕乎。解决的关键就是要明白 Swap 的原理,查到关联参数,然后就可以很快地定位了。原创 2024-03-12 16:11:19 · 744 阅读 · 0 评论 -
26丨案例:手把手带你理解TPS趋势分析
在这个案例中,我们将 TPS 从 150 多调到 6000 以上,就因为一句日志代码。分析过非常多的性能案例,到最后发现,很多情况下都是由各种简单的因素导致的,这一反差也会经常让人为这一路分析的艰辛不值得。但我要说的是,性能分析就是这样,当你不知道问题在哪里的时候,有一个思路可以引导着你走向最终的原因,那才是最重要的。希望通过本文可以让你领悟到,趋势这个词对曲线分析的重要性。原创 2024-03-12 15:16:03 · 953 阅读 · 0 评论 -
25丨SkyWalking:性能监控工具之链路级监控及常用计数器解析
对微服务来说,链路监控工具是标配。在性能分析中,需要查看微服务的性能状态时必须用到链路监控工具。我们用 APM 工具要实现的就是以下四点:1. 查看微服务节点的健康状态。2. 判断响应时间的消耗点。3. 通过我们前文中提到的定向监控手段进行详细地问题定位,细化到组件的配置、代码行和 SQL 层级。4. 最后根据定位的根本原因,提出具体的性能瓶颈解决方案。从上面的步骤就可以看出,从性能瓶颈的判断逻辑上,APM 工具给我们提供了很多便利。原创 2024-03-12 14:29:06 · 995 阅读 · 0 评论 -
24丨Kafka:性能监控工具之队列级监控及常用计数器解析
严格来说,这一篇文章是为了告诉你一个逻辑,那就是对一个组件不了解的时候,如何用你的基础技术知识把对组件的性能优化方向整理出来,以及如何通过自己的基础知识来做一个非常合理的分析。这个逻辑就是:1. 先了解这个组件的基本知识:包括架构、实现原理等信息。2. 再整理出这个组件的配置参数。3. 找到合适的全局监控工具。4. 做压力测试时给出明显的判断。原创 2024-03-12 11:52:00 · 1010 阅读 · 0 评论 -
23丨MySQL:数据库级监控及常用计数器解析(下)
有关数据库的知识实在是太多了,在这两篇文章中,我重点想告诉你的,就是分析数据库应该具有的思路。至于其他的知识点,我想应该是你打开文章之前就应该储备的东西。我们再来总结一下,在数据库的分析中,最有可能在三个方面出现问题:1. 硬件配置2. 数据库配置3. SQL 语句对于硬件配置来说,我们只能在解决了 2 和 3 的问题之后,再来评估到底多少硬件够用的。而面对数据库配置问题,这个实在没什么好招,只能去了解数据库架构等一系列的知识之后,再学着解决。原创 2024-03-12 10:53:12 · 797 阅读 · 0 评论 -
22丨MySQL:数据库级监控及常用计数器解析(上)
好了,我们拿一个 mysqlreport 报表从上到下看了一遍之后,你是不是觉得对 MySQL 有点感觉了?这里我给一个结论性的描述吧:1. 在这个性能场景中,慢日志太多了,需要定向监控看慢 SQL,找到慢 SQL 的执行计划。2. 在这个插入多的场景中,锁等待太多,并且等待的时候又太长,解决慢 SQL 之后,这里可能会解决,但还是要分析具体的原因的,所以这里也是指向了 SQL。这里为什么要描述得这么细致呢?主要是因为当你看其他一些工具的监控数据时,分析思路是可以共用的。原创 2024-03-12 09:59:53 · 965 阅读 · 0 评论 -
21丨Tomcat:中间件监控及常用计数器解析
至于其他的 Tomcat 调优参数,你可以在自己的场景中实际操作一下。总之,Tomcat 的优化就是这么几个关键环节:协议、运行模式(尽管现在我认为它已经不再有争议了,但是当你用老版本的 Tomcat 时还是要注意一下)、线程池(关键中的关键)等。不止是 Tomcat 这样,其他类似的应用服务器也是一样。尽管这些应用服务器在架构设计上会不同,但是在我的调优生涯中,针对这样的应用服务器,可调优的关键点真的就这么几个。可见这样的应用服务器本身可调优的点并不多。原创 2024-03-12 09:18:43 · 991 阅读 · 0 评论 -
20丨Java & C ++:代码级监控及常用计数器解析(下)
不管是什么语言的应用,在性能分析的过程中,都是分析两个方法。1. 执行速度够不够快。只有够快才能满足更高的 TPS。2. 执行过程中内存用得多不多。内存用得少,才可以同时支持更多的请求。我觉得对性能测试过程中的分析来说,这两点足够你解决代码上的问题了。有人说,为什么不说 I/O 的事情呢。其实 I/O 仍然是读写量的多少,也会反应用内存中。至于磁盘本身性能跟不上,那是另一个话题。原创 2024-03-11 23:52:38 · 906 阅读 · 0 评论 -
19丨Java & C ++:代码级监控及常用计数器解析(上)
大部分时间里,性能测试和分析都在和时间打交道,而在时间的拆分逻辑中,我们在前面也提到过思路,如何一步步把时间拆解到应用当中,那就是分段。当拆解到应用当中之后,就是抓函数方法的执行时间了。这是保证我们从前到后分析逻辑的关键一环,请你注意,是关键一环,而不是最初的一环。通过这篇文章我想告诉你,在大部分的开发语言中,都有手段直接将方法的执行时间消耗抓出来,你可能现在还不知道是什么方法,没关系,因为跟踪的手段有很多,可以临时去学习如何操作。原创 2024-03-11 23:51:41 · 768 阅读 · 0 评论 -
18丨CentOS:操作系统级监控及常用计数器解析(下)
对操作系统的监控及常用计数器的分析会涉及到很多的内容,所以两篇文章可能也是覆盖不全的,我只把在性能测试分析工作中经常见到的计数器解析了一遍。总体来说,需要记住以下三点:1. 监控平台再花哨,都只是提供数据来给你分析的。只要知道了数据的来源、原理、含义,用什么工具都不重要。2. 性能分析的时候,不会只看操作系统一个模块或哪几个固定计数器的。这些动态的数据,需要有分析链把它们串起来。3. 操作系统提供的监控数据是分析链路中不可缺少的一环,除非你能绕过操作系统,又能很确切地定位出根本原因。原创 2024-03-11 18:17:17 · 909 阅读 · 0 评论 -
17丨CentOS:操作系统级监控及常用计数器解析(上)
在操作系统的分析过程中,CPU 绝对是一个重点分析的对象,它的一举一动都牵动着性能分析的人,所以我们需要在 CPU 的高低上花很多的时间去分析判断。幸运的是,当 CPU 使用率高的时候,我们可以有很多的手段来找到对应的根本原因。这个过程不仅分析思路完整,而且工具繁多。它不像网络那么绕,也不像内存那么复杂,逻辑上还是很清楚的。原创 2024-03-11 17:40:23 · 946 阅读 · 0 评论 -
16丨案例:性能监控工具之Grafana+Prometheus+Exporters
为什么要解释数据的逻辑呢?因为最近在工作中遇到一些情况,有人觉得有了 Prometheus+Grafana+Exportor 这样的组合工具之后,基本上都不再用手工执行什么命令了。但我们要了解的是,对于监控平台来说,它取的所有的数据必然是被监控者可以提供的数据,像 node_exporter 这样小巧的监控收集器,它可以获取的监控数据,并不是整个系统全部的性能数据,只是取到了常见的计数器而已。这些计数器不管是用命令查看,还是用这样炫酷的工具查看,它的值本身都不会变。原创 2024-03-11 16:58:46 · 1279 阅读 · 0 评论 -
15丨性能测试场景:如何进行监控设计?
在本篇中,描述了监控设计的思维逻辑。对架构中的组件进行了分析之后,通过全局—定向的思路列出要看的计数器,再通过相应的监控工具去实现,拿到要分析的数据。这就完成了要做的监控设计和具体实施。至于你是用什么工具去实现的,这并不重要,因为拿到监控数据,可供分析证据链最重要。原创 2024-03-11 16:07:28 · 836 阅读 · 0 评论 -
14丨性能测试场景:如何理解业务模型?
在这一篇中,我描述了业务模型的来源和计算过程。其实就是一些常规的求和平均计算,只要判断出哪一段业务是我们需要的就可以了。另外也强调了,不管用什么炫酷的手段来实现生产环境的流量模拟,最终的目标是实现和线上比较接近的业务模型。不是说一定用生产流量回放才是正确的,只有适合自己企业的手段才是最正确的。原创 2024-03-11 15:03:45 · 459 阅读 · 0 评论 -
13丨性能测试场景:如何进行场景设计?
在对基准场景、容量场景、稳定性场景和异常场景做了详细的,有逻辑的描述之后,相信你已经能体会到场景的博大精深了。在本篇中,由于字数有限,只对场景的具体执行过程中的关键点做了细致地描述。但是场景绝对不止这些哦,还有很多细节的内容。同时,为了让理解更为清晰,这里只描述了场景本身,场景包括的其他内容,比如说参数设计、监控设计等等,在本篇中都没有描述。从这里,你大概能明白说的场景对性能有多么重要了吧。希望今天的这篇文章能给你在设计性能场景时提供参考。原创 2024-03-11 14:22:13 · 1239 阅读 · 0 评论 -
12丨性能场景:做参数化之前,我们需要考虑什么?
在今天的文章中,需要领悟到的是,参数化数据的合理性对性能场景有着举足轻重的作用。通常,我们在做参数化数据之前,需要先分析实际业务的逻辑。比如说:1. 什么数据是唯一的?什么数据是可重复使用的?2. 数据是客户主动输入,后端只保存即可,还是客户输入后,后端需要比对?这些都是我们在做参数化之前要分析的部分。而参数化的数据量的重要性,不仅和业务需求相关,也和数据存储和查询的方式相关。这个话题我们在后面也会讨论到。原创 2024-03-11 11:42:13 · 1297 阅读 · 0 评论 -
11丨性能脚本:用案例和图示帮你理解HTTP协议
对于 HTTP 协议来说,我们在性能分析中,主要关心的部分就是传输字节的大小、超时的设置以及压缩等内容。在编写脚本的时候,要注意 HTTP 头部,至于 Body 的内容,只要能让业务跑起来即可。原创 2024-03-11 11:04:07 · 887 阅读 · 0 评论 -
10丨案例:在JMeter中如何设置参数化数据?
通过今天的内容,我们对性能测试中的参数化做了一次解析,在执行性能测试时,我们需要根据实际的业务场景选择不同的数据量和参数设置组合。不同的压力工具在参数化的实现逻辑上也会不同,但是参数化必须依赖业务逻辑,而不是工具中能做到什么功能。所以在参数化之前,我们必须分析真实业务逻辑中如何使用数据,再在工具中选择相对应的组合参数的方式去实现。这里总结一下性能工作中参数化的逻辑,希望对你有所启发。1. 分析业务场景;2. 罗列出需要参数化的数据及相对应的关系;原创 2024-03-11 09:41:04 · 954 阅读 · 0 评论 -
09丨关联和断言:一动一静,核心都是在取数据
实际上,关联和断言的前半部分是一样的,都是从服务器返回信息中取出数据。但不同的是,关联取来的数据每次都会不同;而断言取出来的数据基本上都是一样的,除非出了错。对服务端生成的,并且每次生成都不一样的动态变化的数据,那么将其取回来之后,在后续的请求中使用,这种逻辑就是关联。对服务端返回的,可标识业务成功与否的数据,将其取回来之后,做判断。这种逻辑就是断言。原创 2024-03-11 08:53:22 · 967 阅读 · 0 评论 -
08丨案例: 手把手教你编写最简单的性能脚本
其实这篇文章只想告诉你一件事情,手工编写脚本,从基础上说,是非常简单的,只是有三点需要特别强调:1. 涉及到业务规则和逻辑判断之后,编写脚本就复杂了起来。但是了解业务规则是做脚本的前提条件,也是性能测试工程师的第一步。2. 编写脚本的时候,要知道后端的逻辑。这里的意思不是说,你一开始写脚本的时候,就要去读后端的代码,而是说你在遇到问题的时候,要分析整个链路上每个环节使用到了什么技术,以便快速地分析判断。3. 写脚本是以最简为最佳,用不着故意复杂。原创 2024-03-10 23:12:17 · 1089 阅读 · 0 评论 -
07丨性能测试工具:如何录制脚本?
这篇文章,应该是我写的所有的文章中,最最基础的一篇了,并且,从操作上,一步步地描述,也比较清晰。如果你有性能工具使用经验,肯定会觉得这篇过于简单。可是为什么还要写呢?因为在性能测试的过程中,有很多新手对录制的逻辑并不清楚。代理录制的这个动作他们也可以很快学会。但是很快就忘记了,我曾经给一些人手把手教过如何做代理录制。结果第二天就不记得了。其实并不是不记得动作,而是出了问题,脑子里没有判断问题的逻辑,所以根本无从下手排查。另外,你需要注意的是,录制功能并不是性能测试工具必备的功能。原创 2024-03-10 22:27:31 · 1057 阅读 · 0 评论 -
06丨倾囊相授:毕生所学的性能分析思路都在这里了
在这一篇中,说到了瓶颈的精准判断、线程递增的策略、性能衰减的过程、响应时间的拆分、构建分析决策树以及场景的比对,这几个环节,是性能分析过程中非常重要的环节。从经验上来说,这一篇文章可能是工作几年的精华所在了。而这里的每一个环节,又有非常多的细分,特别是构建分析决策树这一块,它需要太多的架构知识、系统知识、数据库知识等等。鉴于本文只是想起到一个提纲挈领的作用,所以无法展开描述,希望在后续的篇幅中,我们尽量细致拆解。原创 2024-03-10 22:26:50 · 962 阅读 · 0 评论 -
05丨指标关系:你知道并发用户数应该怎么算吗?
下面我们就来说一下“并发”这个概念。我们假设上图中的这些小人是严格按照这个逻辑到达系统的,那显然,系统的绝对并发用户数是 4。如果描述 1 秒内的并发用户数,那就是 16。是不是显而易见?但是,在实际的系统中,用户通常是这样分配的:也就是说,这些用户会分布在系统中不同的服务、网络等对象中。这时候”绝对并发“这个概念就难描述了,你说的是哪部分的绝对并发呢?要说积分服务,那是 2;要说库存服务,那是 5;原创 2024-03-10 22:18:36 · 1108 阅读 · 0 评论 -
04丨JMeter和LoadRunner:要知道工具仅仅只是工具
总体来说,性能测试工具的市场中,可以说现在的工具已经种类繁多了,并且各有优点。在项目中,根据具体的实施成本及企业中的规划,选择一个最适合的就可以了。也可以用它们来组建自己的平台。但是请注意, 不要觉得做平台可以解决性能测试的问题,其实平台只是解决了人工的成本。如果单纯为了追潮流而把性能测试工具的使用成本升得特别高,那就不划算了。原创 2024-03-10 22:14:12 · 796 阅读 · 0 评论 -
03丨性能综述:怎么理解TPS、QPS、RT、吞吐量这些性能指标?
今天的这一篇和前两篇文章是一个体系,我利用这三篇文章对当前的性能测试市场上的一些关键概念进行一些拆解。性能测试策略、性能测试场景、性能测试指标,这些关键的概念在性能测试中深深地影响着很多人。我们简化它的逻辑,只需要记住几个关键字就可以,其他的都不必使用。1. 性能测试概念中:性能指标、性能模型、性能场景、性能监控、性能实施、性能报告。2. 性能场景中:基准场景、容量场景、稳定性场景、异常场景。3. 性能指标中:TPS、RT。(记住 T 的定义是根据不同的目标来的)原创 2024-03-10 19:04:49 · 1530 阅读 · 0 评论 -
02丨性能综述:TPS和响应时间之间是什么关系?
总之,在具体的性能项目中,性能场景是一个非常核心的概念。因为它会包括压力发起策略、业务模型、监控模型、性能数据(性能中的数据,我一直都不把它称之为模型,因为在数据层面,测试并没有做过什么抽象的动作,只是使用)、软硬件环境、分析模型等。有了清晰的、有逻辑的场景概念之后,在后面的篇幅当中,我们将从场景的各个角度去拆解。在本专栏中,我们将保持理念的连贯性,以示我不变的职业初心。原创 2024-03-10 18:56:52 · 1066 阅读 · 0 评论 -
01丨性能综述:性能测试的概念到底是什么?
今天的内容只讲了一点,那就是性能测试的概念。请不要再使用像性能测试、负载测试、容量测试这样的词来概括性能执行策略,这是对实施过程没有任何指导价值的。在性能测试的概念中,性能指标、性能模型、性能场景、性能监控、性能实施、性能报告,这些既是概念中的关键词,也可以说是性能测试的方法和流程。而这些概念我们在实际的工作中,都是非常重要的。因为它们要抹平沟通的误解。让不同层级,不同角色的人,可以在同样的知识背景下沟通,也可以让做事情的人有清晰的逻辑思路,同时对同行间的交流,也有正向的促进作用。原创 2024-03-10 18:55:06 · 788 阅读 · 0 评论 -
开篇词丨“老板,之前咱TPS是100,我优化完是10000”
我一开始也和大多数人一样,以为做性能测试,就是做些脚本、参数化、关联,压起来之后,再扔出一个结果。随着时间的增长,我越做越多。慢慢地,我发现,性能测试好像远不止这些内容。当把性能分析也加入到工作中之后,性能工作一下子变得丰富起来。现在,我更关注一个性能测试项目在分析调优了之后,响应时间有多大的提升,TPS 有多大的提高,资源有多少的节省。曾经在一个零售业大厂做过一个性能咨询。原创 2024-03-10 18:53:15 · 466 阅读 · 0 评论