精华内容
下载资源
问答
  • 2021-08-06 17:42:51

    项目优惠券压测方案
    压测目的:
    验证A系统大批量发券同步到
    系统中是否正常,****接收处理是否正常。
    基础目标:每小时可以正常同步10W张券
    1.1、测试工具
    jMeter
    1.2、压测环境
    服务器配置:

    1.3、压测方案
    1.3.1、模拟真实场景验证是否达标
    通过发券宝活动,针对5000个客户(会员数据已完成),分别进行发5种券每种发2张共5W张券,5种券,每种发10张共25W张券。观察处理时间和成功率。
    1.3.2、针对生态融合编写发券接口进行压测
    通过jmeter,直接调用中间层发券接口进行压测。参数化用户wid和券码code,数据量为5000个客户,共25W个券码code。观察对方接口的处理时间和成功率,监控CPU、内存、TPS、QPS等指标

    涉及到的接口URL:
    http://path/message
    入参:
    {
    “id”: “1bb1cc92-cece-4246-becc-a2ff1c08885b”,
    “topic”: “cc_coupon”,
    “event”: “getCoupon”,
    “business_id”: 12,
    “public_account_id”: 1254,
    “msg_body”: {
    “code”: “920072918376021543”,
    “wid”: 1112,
    “pid”: 12212121,
    “source”: 3,
    “type”: 0
    },
    “version”: 1
    }

    1.4、压测准备:
    1.4.1压测数据准备
    1.5000个客户,保障A系统和CRM都存在对应的客户,以手机号做桥接(已完成)
    2.CRM需同步到A系统10张优惠券,库存充足,领取不限量。

    1.4.2 环境准备
    应用名:
    A系统需要把发券宝,圈人,涉及到的应用迁移到压测集群,对应的数据库也要考虑在内
    与王辉沟通确认,QA环境可以直接模拟发券宝的场景
    (针对5000个客户(会员数据已完成),分别进行发5种券每种发1张,5种券,每种发10张)

    调中间层接口涉及到的应用名:
    *********-coupon-management
    *********-coupon-service
    *********-merchant-setting-service
    *********-coupon-service
    *********-base-core-service
    *********-b-core-web
    *********bc-base-core
    *********-b-core-web

    中间层应用:*****-erp--service

    数据库:
    直接调接口压测对数据库造成一定的压力。
    *********-db-*****qa01.i.com ec_erp_

    1.5、压测结果:
    1.5.1、场景压测:
    5W:成功数,失败数,成功率,RT,ART,TPS
    10W:成功数,失败数,成功率,RT,ART,TPS

    1.5.2、接口压测:
    25W:成功数,失败数,成功率,RT,ART,TPS

    更多相关内容
  • Jmeter分布式压测方案

    2021-12-15 17:54:26
    本地电脑通过Jmeter图形化界面(GUI方式)控制本机及其他远程机器,以它们为压力机,对被测的服务器进行压力测试,并将压测的结果同步到Jmeter图形化界面中,进行分析。 准备: 1、作为压力机的本地电脑和远程机器...

    背景:
    本地电脑通过Jmeter图形化界面(GUI方式)控制本机及其他远程机器,以它们为压力机,对被测的服务器进行压力测试,并将压测的结果同步到Jmeter图形化界面中,进行分析。
    准备:
    1、作为压力机的本地电脑和远程机器安装jdk、jmeter,版本要一致,并且配置好环境变量,配置完毕后,执行java -version和jmeter -v进行验证,如果返回了版本信息等内容,说明环境配置ok!
    2、远程机器进入jmeter的bin目录下,打开jmeter.properties文件,remote_hosts和server_port保持默认不变即可。
    在这里插入图片描述
    修改下面参数为true,禁用掉。
    server.rmi.ssl.disable=true
    注意:如果有多台远程压力机,所有远程机器都重复上面的操作:jdk、jmeter、jmeter.properties文件,保持统一。
    3、所有远程压力机器上分别执行 jmeter-server -Djava.rmi.server.hostname=压力机的ip地址(ifconfig中可查)
    4、进入控制机的jmeter的bin目录下,打开jmeter.properties文件,remote_hosts配置所有远程压力机的ip+端口号,多个压力机之间用英文逗号隔开,如果把控制机也当成压力机使用,则将控制机也添加;server_port保持默认不变即可,保存后即可。
    在这里插入图片描述
    5、控制机(本地机器)上打开Jmeter图形化界面,编写压测脚本,点击菜单中的运行按钮即可看到远程机器清单,选择某个压力机即可在该机器上执行压测脚本,对被测服务器产生压力。
    在这里插入图片描述
    注意:如果把控制机也当成压力机执行脚本,则控制机上也要启动jmeter-server服务,否则会报错连接失败。

    演示:设置100个线程,远程启动所有。
    在这里插入图片描述
    运行控制机和压力机的运行server日志如下:
    在这里插入图片描述
    聚合报告显示结果:每个请求执行了200次,上面设置的线程数100,意味着每台机器执行100次,在两台机器上执行,相当于每个请求执行了200次。从这里就可以看出这就是分布式的好处,高并发可以均匀的给每台机器设置一定的负载,加在一起就是总负载。
    在这里插入图片描述

    展开全文
  • 全链路压测方案

    千次阅读 2018-08-23 16:53:08
    我们了一个工具,拉取出前一天的日志直接在线上做回放。比如,根据响应时间和负载设定一个的预值,达到预值触发的时候看它QPS的多少值。 其次我们做了一个分流。因为阿里整个架构还是比较统一的,全部是基于一...

    双十一的技术准备在做两件事情:第一是系统的准备尽可能的接近真实,包括容量确定性和资源的确定性;第二是整个过程中的效率,包括人和单位资源效率。

    < 演讲视频 >

    class="video_iframe" allowfullscreen="" height="408" width="544" src="https://v.qq.com/iframe/preview.html?vid=n03597ffzp1&width=500&height=375&auto=0">

    本视频来自阿里巴巴研究员蒋江伟在ArchSummit北京2016的演讲。

    公众号后台回复关键词「双十一」下载演讲PPT。

    亲历双十一

    从2009年到2016年,参与了8届双十一技术备战工作。2009年的双十一,印象并不深刻,主要原因是当时整个淘宝的体量已经很大,每天的交易额已经有几亿的规模,而当时的淘宝商城双十一交易额只有5000万左右,和几亿比体量还是非常小的,所以感觉还没开始就过去了。

    到了后面几年,每年都要花费好几个月的时间去精心准备,要做监控、报警的梳理,要做容量的规划,要做整个依赖的治理等等,也整理了各种各样的方法论。这是一个过程,当然在这个过程里面也沉淀出了很多非常有意义的事情。今天有人问我怎么做双十一,怎么做大促活动,我会告诉他一个非常简单的方法,就是做好容量规划,做好限流降级。

    2008年,我加入淘宝,直接参与淘宝商城的研发工作。淘宝商城就是后来的天猫,当时整个淘宝商城的技术体系,和淘宝网是完全不一样的,是完全独立的体系。它的会员、商品、营销、推荐、积分、论坛,都和淘宝网没有任何的关系。两套体系是完全独立的,唯一有关系的是整个会员的数据是共享的。

    2008年末启动了「五彩石项目」,把两套体系的数据打通、业务打通,最核心的点就是业务的发展变得非常灵活。这个项目的完成给淘宝商城的发展带来非常大的飞跃,后来淘宝商城也升级品牌为天猫。

    另外,这个项目里还有一个很大的意义,就是比较优雅的实现了架构的扩展性、业务的扩展性和技术的扩展性。我们实现了整个服务的全部服务化,抽取了所有与电商相关的公共元素,包括会员体系、商品中心、交易中心、营销、店铺、推荐等。基于这个体系,构建后来像聚划算、电器城、航旅等的业务就非常快了。打破原来的架构,将整个公共的服务抽取出来之后,上层的业务跑得非常快,这就解决了业务扩展性的问题。第一次大规模使用中间件是在这个项目里,中间件3剑客,HSF、Notify、TDDL得到了很大的创新沉淀,并被大规模的使用。分布式带来的问题是一个系统被拆成了很多的系统,这其中也涉及到了扩展性的问题。这个项目也带来了技术的进步,从业务的发展到技术的扩展性,都达成了非常好的目标。

    为什么要做容量规划?

    2012年,我开始带中间件产品线和高可用架构的团队。那么为什么要做容量规划呢?双十一推动了阿里巴巴技术上非常大的创新,容量规划也是双十一在这个过程中非常好的创新。

    今年做双十一的时候,老板问我今年还有什么风险?我告诉他风险肯定很多,但是最终如果系统出问题了,肯定发生在交易相关的系统里。阿里巴巴的系统分两部分:一部分系统是促进交易的,比如推荐、导购、搜索、频道等都是促进交易的,会做各种各样的营销;另外一部分系统做交易、红包、优惠等相关系统。

    原因非常简单,导购类的系统留给你足够的时间去做判断,它流量的上涨不是瞬间上涨,而是一个曲线慢慢上升,它留给你30分钟做出判断。但是交易系统没有留出任何时间判断,一旦流量开始,没有给人反应时间,没有任何决策的时间,所有的行为只有系统会自动化执行。这个过程里面容量规划变的非常重要。

    在早些年的时候,我们业务的自然增长本身就非常快。印象非常深刻的是,当时大家购物的时候打开的商品详情页面,有一段时间这个页面的负载比较高,公司召集了一些对于虚拟机调优、性能优化比较擅长的人来进行优化,调优了几天之后系统终于挂掉了。还好也在做一些扩容的准备,扩容完成,重启之后系统恢复了。这说明了什么?在早些年的时候,淘宝网也是一样,对容量的准备和预估是没有概念的,不知道多少容量能支撑整个系统需要的能力。

    新业务不断地上线,业务运营、促销类的活动也非常频繁,记得有一次做一个促销规模非常大。会员系统非常重要,因为所有的业务基本上都会访问会员中心用户的数据,包括买家的数据还有卖家的数据。那时物理机单机缓存的能力大概在每秒处理八万请求的规模,今天来看是远远不止。但当时还没有到高峰期的时候就达到了六万,这是非常大的一个数字。

    我们就把所有访问会员的系统全部拉出来,看哪些与交易无关就通知需要停掉,或者停掉一半。比如把与商家相关的,与开放相关的,与社区相关的系统停掉。在这个过程里面发生了各种各样的问题,总结来说就是我们根本不知道容量怎么去做,或者说根本就没有概念需要去做容量。所以容量规划归根结底就是:在什么时候什么样的系统需要多少服务器?需要给出有确定性,量化的数字。

    容量规划的三个阶段

    容量规划整个过程大概经历了七八年的时间,总共三个阶段。
    这里写图片描述

    第一个阶段在非常早期,我们评估的方法就是「拍脑袋」(经验判断)。根据负载的情况、系统的响应时间,各种各样的表现去拍一个数字出来。当时我问一个高管,到底怎么去判断服务器够还是不够,要支撑多少流量?他告诉我一个经验值,每台服务器支持100万的PV。

    当时一天的流量曲线会有三个峰值,九点到十点,中午两、三点到五点,晚上八点到十点之间都是峰值。为什么是100万呢?这也是一个经验值,当然也有一点科学根据。我们希望做到一半的服务器停下来后能够去支撑线上的流量,同时在峰值的情况下,全部能够支撑住。实际上单机能支撑320万的PV,这是当时的经验值。

    当然这个经验值当时是起作用的,原因非常简单,因为当时的系统架构简单。可以理解为把整个淘宝所有的逻辑和模块都集中在一个系统里面,所以各个模块之间的热点有时间差,通过一台服务器内部CPU的抢占或者调度在OS层面就解决了。

    到了第二个阶段是线上压测阶段。因为一旦到了分布式之后,就会出现问题。举个例子,本来是会员的调用和交易的调用在一台服务器上,但是分开之后,流量比例就不清楚了。所以必须要引入一些压测机制,我们引入一些商业的压测工具来做压测。

    当时有两个目的:第一个是系统上线之前要做压测,判断响应时间、负载能否达到上线的要求;第二个目的是希望能够根据线下的压测情况,准确地评估出线上大概需要多少服务器。第二个目的做起来就比较困难一些,记得当时性能压测团队还做了一个项目,叫线下线上容量之间的关系。因为线上的环境和数据与线下完全不一样,这里面没有规律可寻,没办法通过线下压测的指标反馈到线上去。这时候怎么办?首先是直接在线上压测。当时来看我们做这个决定是非常疯狂的,因为没有一家公司,包括阿里巴巴自己也没有人在线上直接做过压测。我们写了一个工具,拉取出前一天的日志直接在线上做回放。比如,根据响应时间和负载设定一个的预值,达到预值触发的时候看它QPS的多少值。

    其次我们做了一个分流。因为阿里整个架构还是比较统一的,全部是基于一整套的中间件,所以通过软负载,通过调整配比,比如把线上的流量按照权重调整到一台服务器上,通过调整到应用端和服务端不断地调整到一台服务器上去,增加其权重,这时候它的负载也会上升,QPS也会上升,把这个过程记录下来。

    这里已经是两种场景了,一种是模拟,回放日志。第二种是真实的流量,把做成自动化让它每天自动跑产生数据。这个事情做完之后,它从一个维度来说,替代了线下性能压测的过程。因为它可以让每个系统每天自己获得性能的表现情况。项目发布,或是日常需求的发布的性能有没有影响的指标都可以直接看出来。后来性能测试团队就解散了。

    这里有个问题,它还没有基于场景化。场景化非常重要,比如我买一件衣服,平时买东西的流程可能是在购物的搜索框里面搜索,或者是在类目的导航里搜索,从搜索到购物车,再到下单这样的一个过程。双十一推的是商品的确定性,很多频道页面会把卖家比较好的促销商品直接拿出来作为一个频道页。双十二的时候推的是店铺,KPI不一样,推的东西也不一样。

    双十一商品相关的服务器系统的流量会高,它所需要的服务器也会更多一些。双十二和店铺相关的系统服务器所需要也会更多一些。这与平时的流量表现是不一样的,用平时的容量去计算场景化流量,这也是不准确的。

    我们也做了一件非常重要的事情:全链路压测。这是我们在2013年完成的事情,之前从没有对外讲过,这是一个核武器,它有个分界线。2009年是最顺利的一次双十一,因为没有什么流量,我们忽略不计。2010年、2011年、2012年,其实每年的双十一总是有那么一些小问题,其实心里也没底。

    在2013年的时候,我们做了全链路压测这个产品之后,发生了一个本质的变化。2013年的表现非常好,2014年也非常好,这就是一个核武器的诞生。对于做营销和促销类的,它是有峰值的,在这个时间点之前峰值非常低,这个时间点之后峰值突然上去了。这就是处理这种情况非常有效的一种方法。

    从线下到线上:单机压测的容量评估

    这里写图片描述

    重点分析一下线上压测和场景化的全链路压测。线上压测主要是由于淘宝的业务形态多样化。分布式之后各种各样的业务都出现了,它帮助解放了生产力。以前一百多个人在做一个系统,非常糟糕,但是通过分布式改造之后,整个业务服务抽象出来之后,生产力被解放了。

    其次,每个业务的机器规模非常大,每个业务应用数量非常大。我们其实是做了一个分层,根据一个系统具备的容量不断计算,最后计算出来阿里巴巴的集群容量。我们先做一个应用系统,通过分流,流量通过负载导入,把负载跑到最高之后计算。把这个APP整个集群,比如100台服务器能支撑多少量计算出来。当然数据库非常难算,数据库都是提前规划的,一般来说数据库分库分表之后,都是留了好几年的量,比较困难一些。

    通过这样把整个集群的量和规模全部做出来是有问题的,为什么呢?因为系统一旦开始拆分之后一发而不可收拾,拆得越来越多。系统的依赖关系虽然是有工具能够梳理出来的,但是我们没有经历看到底哪些系统会因为这个场景下面什么原因导致整个集群出现了一个小问题。一旦出现了一个小问题,整个集群全部崩溃掉,这种问题是没法避免的。

    在2013年之前都是基于这套体系去做,想想也是挺合理的,每个系统算出容量,一个个集群算出来,再算出整个大集群也是可以的,但是它还不是一个非常好的解决方案。它非常好的一点是可以自动化运行,可以每天跑出系统的容量,并且可以保证系统不腐化,日常的性能、指标不腐化。

    压测平台的架构

    这里写图片描述

    2013年的双十一是通过这套系统做的。通过几种方式,通过模拟以及流量的复制,转发的引流,还有负载均衡的流量去实现。整个系统做成自动化,每周都会跑,根据发布前后的一天跑出来数据之后生成一个报表反馈性能有没有下降可以得出。根据计算值准备整个活动流量大概要多少。这里有一些数据,每个月有5天自动做压测,这种情况下靠人工做性能压测是做不到的,因为它是自动化的。

    刚才也讲了一些缺陷,它是以点到面,通过一个点的容量评估,扩展到一条线,扩展到一个面。最大的问题是没有一个人搞得清楚整个架构到底怎么样,整个系统依赖关系里有遗漏之后会形成整体的崩溃。

    这里写图片描述

    为什么要做场景化的容量评估?

    我们需要场景化压测的另外一个原因是因为整个背景的流量大部分用的是分流,分流意味着是用真实的流量去做的,所谓真实的流量其实是很低的,和做活动相比流量非常低,没有背景流量整个机房的网络设备和交换机的流量无法跑满,所以这些问题是没办法暴露出来的。第二个问题是场景化的确定性,每个人购物流程是不一样的,在不同的流程下面整个系统的资源必须确定下来,要用最少的服务器支撑最大的量。

    基于此,当时有一套争论,要怎么做场景化压测这个事情?第一种方法,把整个淘宝网隔离出一个小的环境里面布100多个系统。整个流量引进来,把集群跑满,流量跑满。它比较好地解决了依赖关系的问题,如果依赖出现问题的时候,在这个环境是能够验证的。但是没办法解决环境的问题,那一年我们公司有一个业务,就是因为没有采用这套方案,采用了类似于小环境的流量去验证的方案,导致入口交换机的整个流量跑满。

    场景化容量评估

    这里写图片描述

    所以需要有一个更简单可靠的评估工具,这就是基于场景化的全链路压测。2013年之后我们全部基于这套体系在做,首先要造数据,流量希望能够更接近真实的情况造出来。刚才提到临近峰值是没办法做决策的,唯一能做的是什么?能够提前模拟一次零点的峰值是什么样子的吗?我们希望把整个流量模拟出来,这是一个理想的架构,但是它也有很多困难的地方。

    我们要尽可能把数据造得精确,各种场景都要模拟出来,比如优惠券如何使用,购物车里商品比例是多少,一次下单有多少商品,最后多少商品提交到支付宝等等。数据量每年越来越大,比如以2015年为例,数据量接近1T,把这1T的数据传到中心,通过中心传到压测节点上去,这就是压测集群。它是一个压测工具,但是它本身又是一个集群性的压测工具,它可以产生非常巨大的流量,与双11一模一样规模的数据。

    把集群部署到CDN节点上,产生巨大的流量。这里有一些技术点,压测的工具要支持多种协议,比如HTTPS协议,需要提升性能。还要做流量的控制,根据业务场景的不同调节流量。第三点流量需要染色,右图反映了真实的流量,这些全部是在线跑的,没办法在线下模拟这个环境,否则会影响线上正常的流量,所以要把正常的流量和压测的流量完全区分开来。第四点是流量的隔离。没有流量隔离之前,我们只能在零点以后流量很低的时候,每个人都盯着自己的系统有没有出现什么问题,非常辛苦。第二年提了一个目标,希望能改善大家的幸福指数,所以我们推出了流量隔离。

    这里写图片描述

    流量隔离是把整个集群从原来在线的集群,比较快地通过负载均衡隔离出一个集群出来。当然隔离出的集群规模是非常大的,它可以占原来集群的从90%到10%。比如原来有10万台服务器,可以隔离到9万台服务器。因为准备做大促的时候,比如双十一的流量是平时的20倍以上,所以平时流量非常低是可以隔离出来的,并且不会影响现有的流量。

    整个过程是怎么样的?以图为例,ABCD这4个系统是日常的流量,原始的场景C所需要的服务器多,但是压测之后发现B和D需要的服务器比较多。整个过程都是自动化的,如果C不需要这么多服务器,它的服务器就会被下线,这些服务器就被自动加到B和D。由于都是自动化跑,效率非常高,而且不需要到凌晨跑。最后需要把隔离出来的集群还到原来在线的集群,变成服务器的比例,就可以准备第二天的大考了。

    容量评估的流程

    这里写图片描述

    整个容量评估的流程,从数据构造到流量环节,我们都有一个指挥部。比如我们要做一次活动,这次活动大概要5万笔每秒的交易量,输入5万笔每秒这个数字之后,整套系统开始运作,做压测、做弹性调度、做隔离,这就是整个自动化的过程。容量是可以预测的,但是没办法规划,只能做限流。我们可以非常精确地预测出双十一大概会来多少量,会来多少用户,以及当时的峰值,都可以完全精确预测出来。

    但预测出来也没有太多的意义,能做的就是限流笔数,比如2016年我们做到了17.5万笔,限流的值设定到了17.2万,所有的系统先设定到这个值。这也是没办法的,因为真实的流量比这个大得多,要支持真实的流量成本会非常高。

    日常占有的服务器是非常低的,在大促的时候我们基本上都采用阿里云的服务器,所以成本下降明显。所以说整个容量规划限定了一个值,比如说17万,明年可能是20万,或者25万,在这个值的基础上,通过基于场景化的全链路压测工具,然后把整个系统的容量压测出来,计算出来,把整个服务器资源占用拉平。这样做的好处是用了最少的资源做了一次最成功的活动。

    场景化容量评估的表现

    这里写图片描述

    从2013年开始,我们通过这套技术发现了大量的问题,而且这些问题经过日常的测试,功能测试,或者一些工具的测试,是没办法发现这些问题。硬件、网络、操作系统的问题,从来没有发现的问题全部暴露出来,在大负载情况下表现出各种诡异的问题。

    任何一个问题在双十一发生,可能都是灾难性的。2013年我们做完这些事情之后,回头看2012年、2011年,不出问题还怪,肯定会出问题。凡是峰值流量是平时峰值超过多少倍以上的活动肯定会出问题,因为很多的问题没办法通过一些逻辑,通过一些思考找出来的,它必须借助一个真实的环境,模拟出所有场景的流量把它营造出来。

    容量评估的总结

    这里写图片描述

    容量规划是一个领域、一个长时间的过程。最初利用商业软件做性能压测,当时觉得这个软件应用挺好的,也能够支撑整个容量的一些计算,甚至今天很多的公司还在用类似的软件做性能的评估,它也是不断引进的过程。后来发现,其实与真实压测评估的容量还相差非常远,所以我们引入了线上的压测,引入了分流、复制流量、及日志的回放,通过一个个节点把自己的流量评估出来。

    当时觉得这套系统很厉害,因为当时做了这套系统获得了整个技术部的创新大奖,所以觉得有了这套系统以后,以后做双十一就不用愁了,做任何活动就不用愁了,觉得这是非常了不起的系统。实际情况还是需要不断地发展,做了全链路压测,整个链路基于场景化的真实场景模拟,把整个集群压测出来。

    回过头来看,在一个领域里面,当自己满足于当前现状的时候,比如说CSP“日常的压测平台”能够完全满足于当前现状,而且已经领先于国内很多产品的时候,其实你还是可以继续往前走一步。

    我们只是做了双十一创新里容量规划这个点。阿里巴巴整个技术架构非常统一,因为做了全链路压测之后,很多的业务单元,像支付宝等等都可以采用这种方式做,它可以非常简单地复制出去,这也给我们带来了非常低的成本。从研发开始到学习,以及运维的过程,运维的产品线,带给了我们非常低的成本。所以我们整个团队人非常少,做全线路压测就4、5个人,但是它服务了整个集团100多个业务方,这也是因为整个架构的统一性。

    今年双十一做完了之后,我们的CTO也给我们提出了新的挑战:双十一的整个过程可以投入更少的成本,全链路压测是对日常系统的一种验证,而不是找问题本身,同时希望我们的系统更加的自动化和智能化。我们正在思考如何实现。
    原文传送门:http://www.yopai.com/show-2-113932-1.html

    展开全文
  • 一、MQ性能压测脚本准备 Rocket官方源码提供的有代码——benchmark,详见下图。mq官方下载 源码见图: 打包项目为jar包 此处做个打包讲解吧。最推荐方式: <build> <!-- 打包后的名字 --> <...

    成功的脚本压测图:
    在这里插入图片描述

    一、MQ性能压测脚本准备

    Rocket官方源码提供的有代码——benchmark,详见下图。mq官方下载
    在这里插入图片描述
    源码见图:
    在这里插入图片描述
    打包项目为jar包
    此处做个打包讲解吧。最推荐方式:
    在这里插入图片描述

      <build>
            <!-- 打包后的名字 -->
            <finalName>benchmark-1.0-SNAPSHOT-consumer</finalName>
                <plugins>
                    <plugin>
                        <groupId>org.springframework.boot</groupId>
                        <artifactId>spring-boot-maven-plugin</artifactId>
                        <configuration>
                            <!-- 指定程序入口 (需要注意的地方)-->
                            <mainClass>org.apache.rocketmq.Consumer</mainClass>
                        </configuration>
                        <executions>
                            <execution>
                                <goals>
                                    <goal>repackage</goal>
                                </goals>
                            </execution>
                        </executions>
                    </plugin>
                </plugins>
    <!--        </pluginManagement>-->
        </build>
    

    其他的如点击或自行百度吧,不过都没这个简单哈。有工具用就要学会发挥其作用,不要一味地追求没效率的学习。
    接下来就是在linux虚机中编写脚本运行这个代码了。
    下方的脚本编写比较简单,重点学习一下 java -jar 和java -cp的不同。前半部分都是jvm调优,启动参数,重点就最后一行。

    期间遇见的问题:

    问题一:找不到主类

    在这里插入图片描述
    解决方案和知识点:

    if [ -z "$JAVA_HOME" ]; then
      JAVA="java"
    else
      JAVA="$JAVA_HOME/bin/java"
    fi
    
    # Memory options
    if [ -z "$ROCKETMQ_HEAP_OPTS" ]; then
      ROCKETMQ_HEAP_OPTS="-Xmx256M"
    fi
    
    # JVM performance options
    if [ -z "$ROCKETMQ_JVM_PERFORMANCE_OPTS" ]; then
      ROCKETMQ_JVM_PERFORMANCE_OPTS="-server -XX:+UseG1GC -XX:MaxGCPauseMillis=20 -XX:InitiatingHeapOccupancyPercent=35 -XX:+DisableExplicitGC -Djava.awt.headless=true"
    fi
    
    exec $JAVA $ROCKETMQ_HEAP_OPTS $ROCKETMQ_JVM_PERFORMANCE_OPTS -jar benchmark-1.0-SNAPSHOT.jar "$@"
    
    exec java -jar benchmark-1.0-SNAPSHOT.jar "$@"
    

    和下方的做下区别。

    exec java -cp benchmark-1.0-SNAPSHOT.jar org.apache.rocketmq.Producer "$@"
    

    核心区别:
    在这里插入图片描述

    如果再遇见,Error: Could not find or load main class *** 那就看看包名正确否,路径是相对路径还是绝对路径,都不行自行百度解决吧,或者就换方式吧直接使用java -jar 不使用java -cp。
    

    参考链接: https://blog.csdn.net/weixin_38653290/article/details/84647019
    https://blog.csdn.net/abcdu1/article/details/86693800

    问题二:脚本执行失败**

    在这里插入图片描述
    解决方案:
    在这里插入图片描述
    参考链接:
    https://blog.csdn.net/u013948858/article/details/79637851

    到此处即可使用命令行进行Rocketmq的生产和消费了。

    找到安装包进入bin目录:
    生产消息正常,使用的是代码中默认的topic:BenchmarkTest -n 集群地址ip:端口
    在这里插入图片描述

    问题三
    此处新问题出现,消费不到数据。均使用的是默认消费组和默认topic

    在这里插入图片描述
    尝试解决方案:

    1. 命令行明确指定消费者组,不行,查看是否建立成功?结果成功了;
      在这里插入图片描述

    2. 新建新的消费者组和Topic,再次执行消费,还是老问题。
      新建消费者组在这里插入图片描述查看Topic列表
      在这里插入图片描述

    3. 查看消费组情况:
      在这里插入图片描述
      在这里插入图片描述

    4. 没有路由信息,问题明天接着跟踪。两个方向:
      一、在启动mqbroker的时候需要指定 autoCreateTopicEnable=true 验证否,但是还是要根据具体问题分析的。
      二、客户端版本和服务器版本不一致,经验证否
      三、查看官方代码,没有路由信息,外加消费不到数据,那肯定是nameserver的事情了。但是生产没有问题,说明nameserver正常啊,那就是消费脚本问题了。本人使用的是mq 4.5.0源码中的消费代码,你会发现消费代码中并没有设置nameserver地址。尝试修改:

    报错信息在这里插入图片描述
    在这里插入图片描述

    4.7.1版本官方已经修复,点击查看4.7.1消费代码
    在这里插入图片描述
    此时自己建立的消费者和topic可以了,但是默认的benchmark的还是不行。
    在这里插入图片描述

    经查阅,消费时想使用默认的消费者组、Topic(BenchmarkTest),请设置(上图中p参数会默认为消费者组名称加后缀,如果是自己建立的消费者组请加参数 -p false):
    在这里插入图片描述
    在这里插入图片描述
    以下内容涉及MQ压测命令或者排查问题的其他命令:

    使用默认消费者消费消息需要加-p false
    在这里插入图片描述

    查看具体消费组消费的topic、消息位移、消费位点、消费客户端ip 、消息积压 Diff、最后消费时间

    在这里插入图片描述

    生产发送消息
    在这里插入图片描述
    设置队列数,注意记得同时设置
    在这里插入图片描述
    在这里插入图片描述
    查看nameserver连接的消费者情况,或者某消费者的具体情况
    在这里插入图片描述
    查看某topic的状态
    在这里插入图片描述

    创建更新Topic

    在这里插入图片描述

    查看结果

    在这里插入图片描述

    发送消息

    在这里插入图片描述

    压测脚本的返回信息字段解析

    生产者返回字段信息
    在这里插入图片描述
    消费者返回字段信息解析
    在这里插入图片描述
    消息堆积情况

    在这里插入图片描述

    插入点容器知识
    查看容器的指标:
    docker images 查看pod的使用的镜像,登录节点部署所在的主机查找
    docker stats 镜像id 在这里插入图片描述
    ![在这里插入图片描述](https://img-blog.csdnimg.cn/8c1b072ea93f41febdc332fa84e43a20.png

    容器指标查看完整命令

    在这里插入图片描述

    压测方案参考文章

    mq常用命令

    总结做的不错 差一点没考虑,压测脚本会不会是其瓶颈。
    在这里插入图片描述

    性能测试报告,也有参考之处

    压测时候的脚本默认值请参考

    在这里插入图片描述

    在这里插入图片描述

    下方的可以选择不看,这些都是排查问题时候见到的,简单记录下。

    这个可以借鉴下此处改的是idea中的配置,想想消费的时候是不是也要配置下nameserver,解决问题请分析问题最终的出处,根据原理一步一步排查,终究会解决的。

    这个我倒是没有遇见和复现,有问题的也可以看下这个文章

    查看消费组情况的命令

    命令行创建Topic
    在这里插入图片描述

    展开全文
  • 压测时间:正式上线两个月测试环境:正式环境测试条件:测试时间选在平台使用时间段较少的时候,通过观察数据库一段时间内数据的增长情况确定在周六的晚上。数据量:目前数据库有51个部门、62个管理员、短信发送总量...
  • 通过实践我们发现在生产环境中做压测,实际上会和一个 IT 组织的结构、成熟度、流程等紧密相关,所以我们把全链路压测从简单的制作范围内脱离出来,变成整个业务连续性的方案。本文分四个方面为大家阐述:第一,整个...
  • 生产压测必要条件:生产压测选择生产压测必要条件,具体”生产压测必要条件“章节 其他参考性能指标:可以是默认的几项,也可是其他自定义项。 环境机型:填写被测环境应用机型,非生产环境压测,填写生产环境及...
  • 导读压测是目前科技企业及传统企业进行系统容量评估、容量规划的最佳实践方式,本文将基于京东ForceBot平台在大促(京东618、京东双11)备战中的实践历程,给大家分享平台在压测方面的技术...
  • kafka压测

    千次阅读 2022-02-22 11:09:37
    实时大数据平台压测方案 1. 压测目的 本次性能测试在正式环境下单台服务器上Kafka处理消息能力及Flink承载能力进行压力测试。测试包括对Kafka写入消息和消费消息进行压力测试,根据不同量级的消息处理结果,评估...
  • 点击上方“朱小厮的博客”,选择“设为星标”后台回复"书",获取后台回复“k8s”,可领取k8s资料在阿里淘宝 双11 的过程中,长期以来都是在生产环节做全链路压测的,通过实...
  • rally文档:http://esrally.readthedocs.io/en/latest/quickstart.html由于 ...然而在引入新的解决方案前,不免要做一番调研和测试,本文便是介绍官方的一个 es 压测工具 esrally,希望能为大家带来帮助。为什...
  • Elasticsearch 压测方案— esrally 简介

    千次阅读 2019-05-31 20:05:32
    然而在引入新的解决方案前,不免要做一番调研和测试,本文便是介绍官方的一个 es 压测工具 esrally,希望能为大家带来帮助。 为什么要压测? 关于压测,我们先来看下百度百科上的一个定义。 压测,即压力测试,...
  • 对数据库进行压测

    2021-08-24 16:29:25
    思路:压测软件sysbench,这个软件需要安装在虚拟机上,而且虚拟机需要安装mysql,xshell窗口输入命令进行测试 我们先安装虚拟机,这里我用的是VMware 需要注意的就是需要开启NAT的网络模式(本次所使用的虚拟机为4核8g) ...
  • 学习redis压测

    2021-11-03 16:26:13
    实现命令行对redis压测 并发,请求量 业务接口压测,消耗redis性能 其实第一反应是请求redis的接口,对其进行压测,因为比较数据http压测。现实的问题是,压测量级上去了,测试环境部署的redis也是集群,都有哨兵...
  • 为什么要压测? 关于压测,我们先来看下百度百科上的一个定义。 压测,即压力测试,是确立系统稳定性的一种测试方法,通常在系统正常运作范围之外进行,以考察其功能极限和隐患。 从定义不难看出压测的目的,是...
  • 这次选用的jmeter压测工具,压测思路如图: 二.日志入参 日志选取的adsearch的getads部分 思路:rd线上获取该部分入参下载到本地,我们读取该部分生成入参对象。(这个套路用到很多工具上,比较省事不用拼...
  • 电商大促作战指南之全链路压测

    千次阅读 2022-02-06 17:25:10
    电商大促作战指南、全链路压测、营销
  • 性能压测–压力测试 压力测试考察当前软件硬件环境下系统所能承受的最大负荷并帮助找出系统的瓶颈所在。压测都是为了系统在上线的处理能力和稳定性维持在一个标准的范围内,做到心中有数。 使用压力测试,我们有希望...
  • 谷粒商城-性能压测

    2022-04-20 18:31:56
    gc的时间会缩短不少,吞吐量就又上去了 简单服务压测 web包下编写接口 压测开始 ,查看结果 压测Gateway+简单服务 配置网关 压测开始,查看结果 全链路压测 总结:中间件越多,性能损失越大,大多都损失在网络...
  • 压力测试可以暴露系统性能问题,如高并发下访问缓慢,服务宕机等,但是通过压测不能具体到哪里存在瓶颈,必须要在压测同时配合适当的资源监控,帮助我们定位问题。 1.配置合理的资源监控方案 (1) 使用nmon...
  • Sysbench 基准压测

    2021-10-13 15:40:01
    1.1、压测环境 配置 信息 主机 Dell PowerEdge R730xd CPU 24 * Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz 内存 64G (16G * 4) RAID RAID1 硬盘 7.2K RPM, 6000G SAS, 12G/s 文件...
  • 今天,我们就一起基于MySQL 5.7做一个实际的主键性能压测。让大家切实感受下使用UUID做MySQL的主键和int数字做MySQL的主键,性能到底有多少差异。
  • 性能测试方案

    2022-01-21 11:05:56
    】 示例:编写JMeter脚本,通过CPS进行压测,由于本次压测的查询活动和开奖接口均无参数化需要,所以参数死即可。 3.6.压测执行 【确认压测之心步骤,若数据何时刷进去,对应脚本何时执行】 3.7.压测结果及报告...
  • 文章目录为什么要压测压测工具rally安装rally 相关术语被压测 ES 硬件资源压测执行压测结果总结 为什么要压测 俗话说"知己知彼,百战不殆",当我们上线一个新的系统或应用的时候,至少要知道这个系统或应用的上线在...
  • [TOC]Jmeter简介Jmeter是Apache开源的一个使用纯Java编写的压力测试工具,它最初是为测试web应用程序而设计的,但后来扩展到了其他测试功能。...如今Jmeter是一个主流的、功能完善且强大的压测工具,由于...
  • 我们将从性能压测的设计、实现、执行、监控、问题定位和分析、应用场景等多个纬度对性能压测的全过程进行拆解,以帮助大家构建完整的性能压测的理论体系,并提供有例可依的实战。 01 性能环境要考虑的要素 系统逻辑...
  • 整个压测优化的思路其实和高并发架构设计的思路是一致的,接下来也会一些关于高并发架构的文章,本篇的全链路压测只是给大家做个入门介绍,其中涉及到的问题远远不止文中提到的这些,而且问题的解决办法也远远不是...
  • 介绍市面上的常见压测工具(ab、locust、Jmeter、go实现的压测工具、云压测),对比这些压测工具,教大家如何选择一款适合自己的压测工具,本文还有两个压测实战项目: 单台机器对HTTP短连接 QPS 1W+ 的压测实战 单台...
  • 全链路压测

    2022-03-02 16:51:34
    压测目标主要包括压测范围、策略、目的,往往与业务、技术目标息息相关。例如: 压测范围:用户注册加登录,为大规模拉新做准备。 压测策略:高仿真生产环境压测,提前经历真实的业务高峰。 压测目的:探测业务...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 15,435
精华内容 6,174
关键字:

压测方案怎么写