说起性能测试,很多人并不陌生,接下来就跟着小编一起看看我们做性能测试要考虑到哪些方面和有哪些常用的工具吧。
1、架构模型了解
1.1、为什么要了解被测服务的架构模型?
服务的架构模型基本表示出两种重要信息。
第一:被测服务内部基本的服务调用流程和大致实现原理是什么样的。
第二:被测服务需要和哪些外部系统进行交互。
了解到了以上两点有什么好处呢?
了解到了第一点我们就可以大致知道,被测服务是一个CPU密集型的服务还是一个IO密集型的服务,服务内部的架构大致是什么样子的,服务的输入数据是怎样被处理然后输出的。
了解到了第二点我们就可以大致知道,被测服务有没有数据库依赖、缓存依赖、RPC框架依赖、消息系统依赖、其他业务系统依赖,当然硬件规格对服务性能影响也是必不可少的。
如上图所示,是一个网关系统的大致服务调用流程模型,我们的测试经验,在了解了服务的架构模型之后,我们就能判断出,在性能测试过程中应该使用哪些监控工具。比如这是一个主要由tomcatWEB服务器提供的一个服务,常用的监控工具有Java VisualVM,我们就可以着手准备监控工具了。
2、性能测试手段高度还原业务场景
2.1、理清业务脉络
对于被测业务场景,我们要能够清楚它的代码流程图,和哪些业务业务系统有交互,上游系统是谁、下游系统是谁,上下游之间怎么交互。
2.2、真实业务场景和流量监控
要清楚被测场景,是属于一个完整业务流程的哪个环节,他承担的实际的业务量有多大,这就需要我们对生产的流量进行监控和分析。
比如网购的支付环节,提供给用户三种支付方式,我们通过对前三年的大促数据的分析发现,第一种支付方式占总的支付方式的60%,那我我们在性能测试过程中就要保证我们的测试脚本在支付方式的选择上也占比60%,甚至高于60%
2.3、性能测试手段能还原生产场景
针对不同的业务系统和需求我们选择的性能测试的场景不同,性能测试的方法也不同。比如一个大促系统,我们就要对其进行瞬时加压模拟流量洪峰,使用RPS发压方式测试其吞吐量,使用稳定性测试方法测试其长时间维持在大负载情况下服务的稳定性,使用可靠性测试方法测试其在软硬件易发故障下的可靠性。也要考虑数据库存量数据、数据库架构、业务系统自身的软件配置、硬件规格其他系统对被测业务系统的影响程度。
总之,我们性能测试的方法、手段、数据、配置、场景必须要和真实生产环境高度一致。
3、风险评估与应对措施
3.1、风险
针对不同业务系统的风险是不一样的,重要的是我们要有预先进行风险评估的意识。
大致出现的风险有:
资金类:使用了客户的账户或资金
系统类:造成服务宕机、造成数据库、缓存系统崩溃、造成下游业务崩溃
业务类:产生大量的垃圾数据、操作了客户的一些真实数据
以上列举不全,针对不同的业务场景有不同的风险。
3.2、措施
环境隔离、数据隔离、性能测试时选择一个业务量少的时间段、提前告知上下游负责人、提前通知使用到的公共服务值班人员、制定风险应对方案。
4、数据准备环境准备
数据:测试数据的数据结构需要和生产数据结构保持相对一致,比如JSON数据层级个数、数据库存量数据规模,必要的账号信息等等,都应该在性能测试方案制定好后马上准备。
环境:对于复杂的测试脚本我们需要在测试环境去调试脚本、实际执行性能测试过程中最好能在和生产机器规格一致的预发环境进行测试。
5、脚本编写
性能测试所用的测试工具不同,所使用的脚本编写语言也不同,但是不同的编程语言间有很大的相似性,只需要遵守工具定义的规则去编写就可以了。
6、发压与监控(监控方法有常用性能测试指标TPS、TP99、错误率,JVM监控、LINUX系统监控)
6.1、发压
发压有两种比较大的策略,一种是并发用户数模式、一种是RPS模式,具体的区别大家可以看看并发模式与 RPS 模式之争,性能压测领域的星球大战 - 知乎本文是《如何做好性能压测》系列专题分享的第四期,该专题将从性能压测的设计、实现、执行、监控、问题定位和分析、应用场景等多个纬度对性能压测的全过程进行拆解,以帮助大家构建完整的性能压测的理论体系,并提…https://zhuanlan.zhihu.com/p/74631073使用并发用户数模式可以对系统的性能进行定性分析,使用RPS模式可以对系统的性能进行定量分析。
我想说的是对于没有历史发压数据参考的系统,不论是并发用户数模式还是RPS发压方式,压力量都应该是从小到大的。
6.2、监控
基本的性能指标可以从发压平台上提现,但是要注意考量TPS、TP90等数据是否真实有效,如果公司有其他性能监控平台的话可以同时监控。
JVM监控工具:Jconsole、Java VisualVM
7、瓶颈点分析和调优
JVM的性能分析三板斧:
1、使用 ps =ef | grep 服务名称找出进程ID。
2、使用 top -Hp pid 找出使用CPU最多的线程ID,并使用 printf "%x\n" 线程ID 将其ID转换为16进制
3、使用 jstack 进程ID | grep 16进制的线程ID 打印线程的栈信息方便分析。
使用visualVM工具可以找到最消耗CPU的代码行,和更加直观的查看JVM的GC情况,推荐几篇文章。
06丨倾囊相授:我毕生所学的性能分析思路都在这里了-极客时间今天我们就来说说性能测试分析的几个重要环节,这些内容是我觉得最有价值的内容了。https://time.geekbang.org/column/article/182912java中WAITING状态的线程为啥还会消耗CPU - 掘金刚刚过去的双十一, 公司订单量又翻了一倍. 就在老板坐在办公室里面偷偷笑的同时,坐在工位上的我们却是一直瑟瑟发抖. 面对zabbix里面时不时蹦出来的一条条CPU告警,默默地祈祷着不要出问题. 当然, 祈祷是解决不了问题的, 即使是开过光的服务器也不行. CPU告警了, 还得老…https://juejin.cn/post/6844904001067040781理解CPU使用率和CPU上下文切换 - 知乎1、CPU使用率1.1 CPU使用率查看当发现服务或机器卡的时候,我们都是先通过top命令查看服务器CPU使用率 默认每3秒刷新一次 top top - 18:10:58 up 1216 days, 7:38, 4 users, load average: 23.06, 24.54, 23.72 Ta…https://zhuanlan.zhihu.com/p/446799316?utm_id=0一篇文章掌握整个JVM,JVM超详细解析!!!_小杰要吃蛋的博客-CSDN博客_jvmJVM先想想一些问题1 我们开发人员编写的Java代码是怎么让电脑认识的2 为什么说java是跨平台语言3 Jdk和Jre和JVM的区别4 为什么要学习JVM深入学习JVM1 JVM运行时数据区2 解析JVM运行时数据区2.1 方法区(Method Area)2.2 Java堆(Java Heap)2.3 程序计数器(Program Counter Register)2.4 Java虚拟机栈(Ja...https://blog.csdn.net/weixin_43122090/article/details/105093777?ops_request_misc=%257B%2522request%255Fid%2522%253A%2522166290240716782428624458%2522%252C%2522scm%2522%253A%252220140713.130102334..%2522%257D&request_id=166290240716782428624458&biz_id=0&utm_medium=distribute.pc_search_result.none-task-blog-2~all~top_positive~default-1-105093777-null-null.142^v47^new_blog_pos_by_title,201^v3^add_ask&utm_term=JVm&spm=1018.2226.3001.4187
8、测试报告
性能测试完成后就需要测试报告来呈现性能测试结果,性能测试报告主要包含以下几部分
性能测试结论
主要描述性能测试通过与否。
性能测试结果分析
未通过的性能场景进行瓶颈分析或者原因分析。
性能测试场景
主要描述进行了哪些性能测试场景和场景描述,比如:基准测试、稳定性测试、可靠性测试、容量测试、并发测试、配置测试等等。
性能测试结果
主要描述针对不同的性能场景的一些峰值性能指标,比如:最大TPS、一段时间内的TP90,TP99,TP999、CPU使用率、磁盘使用率、GC情况等等,给出具体数值。
性能监控图表
最大TPS、一段时间内的TP90,TP99,TP999、CPU使用率、磁盘使用率、GC情况等等必要的能呈现压测过程和结果的图表。