精华内容
下载资源
问答
  • ****项目压测方案
    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次。从这里就可以看出这就是分布式的好处,高并发可以均匀的给每台机器设置一定的负载,加在一起就是总负载。
    在这里插入图片描述

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

    千次阅读 2019-06-10 15:13:43
    全链路压测的概念挺火的,想做成却没有机会(毕竟不是互联网巨头类的公司),所以在这里也不想纸上谈兵,可能过段时间它就会被更新更高大上的概念给替换了,但是我们可以收集一下相关资料(目前可以开展全链路压测的...

           全链路压测的概念挺火的,想做成却没有机会(毕竟不是互联网巨头类的公司),所以在这里也不想纸上谈兵,可能过段时间它就会被更新更高大上的概念给替换了,但是我们可以收集一下相关资料(目前可以开展全链路压测的公司真的很少,所以资料有限),将来对自己的性能测试项目可能也会有帮助:

    相关链接:

    阿里全链路压测    全链路压测3.0    智能全链路压测

    有赞全链路压测实战    全链路压测方案设计与实施详解     全链路压测引擎的设计与实现

    京东全链路压测

    饿了么全链路压测

    滴滴全链路压测解决之道

    美团全链路压测自动化实践

    全链路压测平台(Quake)在美团中的实践

    逻辑思维在全链路压测方面的实践

    全链路压测的大概思路

    全链路压测定义

    全链路压测平台主要有两个核心的也是最顶级的要求:

    • 全业务
    • 全链路

    这导致了,必须线上搞压测,必须用线上的真实数据搞压测。
    那么线上搞就容易搞出事情,所以技术含量还是要有的,还是很高的。

    压测关键前提

    1、业务模型梳理

    首先应该明确的是:全链路压测针对的是现代越来越复杂的业务场景和全链路的系统依赖。所以首先应该将核心业务和非核心业务进行拆分,确认流量高峰针对的是哪些业务场景和模块,

    针对性的进行扩容准备,而不是为了解决海量流量冲击而所有的系统服务集群扩容几十倍,这样会造成不必要的成本投入。

    2、数据模型构建

    数据构建和准备,应该考虑这几点问题:

    ①、数据的真实性和可用性

    可以从线上环境(生产环境)完全移植一份当量的数据包,作为压测的基础数据,然后基于基础数据,通过分析历史数据增长趋势,预估当前可能的数据量;

    据说美团的做法是:

    • http服务的,通过nginx日志把请求内容导出来,处理一下,放到数据库池子里。
    • rpc服务的,通过美团内部已有的rpc框架录制功能,把请求数据导出来,处理一下,放到数据库池子里。

    然后压测流量从数据库池子里来。

    ②、数据脱敏

    基于生产环境的全链路压测,必须考虑的一点是不能产生脏数据,以免对生产造成影响,影响用户体验等,因此在数据准备时需要进行数据脱敏。

    ③、数据隔离

    同样,为了避免造成脏数据写入,可以考虑通过压测数据隔离处理(根据测试标识区分),落入影子库,mock对象等手段,来防止数据污染;另外比如http请求,可以直接将测试标识加在header里(不污染代码,仅测试引擎添加即可),这样可以把隔离出来的(带测试标识的)流量,只访问隔离出来的服务器,这样就不会污染整个线上服务器集群。

    压测核心

    全链路压测基本上和原生Jmeter没关系,因为Jmeter用的是BIO(基于Jmeter的云平台化,足够规模的分布式压测也是可选的一个方向),美团用的是NIO,阿里的PTS也用到NIO,好处不解释了。
    采用的方式有:

    • 使用一些脚本语言如:Python、Ruby 等,读取线上日志构建请求,用多线程模拟用户请求进行压测
    • 类似Netty NIO 框架 + apache ab 组合模式
    • 采用Twitter/iago、 Gatling、Grinder、Locust等开源压测工具
    • 大厂都会自主研发压测平台,避开了开源工具的一些问题

    压测监控

    一般会采用 InfluxDB 来完成数据的聚合工作,所有聚合指标都是一行 SQL 搞定,非常快速。或基于开源二次开发的监控,比如CAT,Falcon,Skywalking等。

    关于监控这块,美团的开源精神值得肯定(虽然内部的好东西未必能开源出来),而像饿了么监控系统 EMonitor 说是比CAT好,但目前为止也没见开源,阿里的云监控更别提了,天天推销让你花钱买服务。

    什么公司要搞全链路压测

    至少目前来看,得是有追求,有余力的公司吧。
    阿里,滴滴,饿了么,云集微店,美团,这些公司有一个共性,都是支付场景比较高并发的公司,就是对钱非常敏感的公司。
    支付场景,也就是支付相关的各个服务(订单,派送,入库出库等很多),相连密切,这样的场景比较复杂,还是高并发,自然对性能测试有高要求。
    同时支付场景,是会改变库的数据的,这也要求线上测试必须做数据隔离,这也是全链路压测的核心。

    什么阶段的公司搞全链路压测

    • 微服务的架构。
    • 需要架构组,得有Mtrace的这种微服务RPC消息跟踪体系架构,能改中间件。
    • 各部门能配合全链路压测调试及部署,运维的机器资源部署。
    • 简单性能测试要通过,即单点的性能测试要没问题。
    • 有更高的技术追求。

    什么时间搞全链路压测

    • 压力小的白天就行,要错过高峰期,这也是得益于数据隔离,服务器隔离。
    • 压力大的一般凌晨进行,要错过高峰期。

    谁来搞

    肯定不是测试,也不是一般的性能测试工程师和测试开发工程师,基本上是一个研发团队在搞。

    据说美团的压测平台前身也是测试开发工程师搞的,推广的也不错,在美团趟出了一条压测的路,但是存在了不少有待改进的地方。后来种种原因,平台移交给了开发团队,现在看起来,平台的压测性能、可用性等各方面有了很大的提升。不是说测试开发的同学做不了,而是效率和速度确实还是有差距的。开发同学的效率和速度就是特别大的优势,能加班,可以快速的让产品成型并且快速迭代。

    以上内容部分参考自 https://testerhome.com/topics/16498

    展开全文
  • 一、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
    在这里插入图片描述

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

    千次阅读 2018-08-23 16:53:08
    所以必须要引入一些压测机制,我们引入一些商业的压测工具来做压测。 当时有两个目的:第一个是系统上线之前要做压测,判断响应时间、负载能否达到上线的要求;第二个目的是希望能够根据线下的压测情况,准确地...
  • 压测时间:正式上线两个月测试环境:正式环境测试条件:测试时间选在平台使用时间段较少的时候,通过观察数据库一段时间内数据的增长情况确定在周六的晚上。数据量:目前数据库有51个部门、62个管理员、短信发送总量...
  • Elasticsearch 压测方案— esrally 简介

    千次阅读 2019-05-31 20:05:32
    然而在引入新的解决方案前,不免要做一番调研和测试,本文便是介绍官方的一个 es 压测工具 esrally,希望能为大家带来帮助。 为什么要压测? 关于压测,我们先来看下百度百科上的一个定义。 压测,即压力测试,...
  • 本文将讲解如何在centos上配置jmeter压力机以及其压测方案。本文默认读者已经掌握了jmeter的基础使用方法。 在centos上安装jmeter 下载jmeter tgz版本 Apache JMeter - Download Apache JMeter 注意5.4.3...
  • jmeter压测指南

    2019-05-06 17:35:12
    jmeter性能测试指南,采用Jmeter工具,该文档为阿里巴巴全链路性能测试工具方案
  • 电商全链路压测平台方案设计.docx
  • 有赞在双十一之前完成了全链路压测方案,并把它用于大促的扩容和容量验证,取得了不错的成果。 \u0026#xD;\u0026#xD; 在电商公司待过的技术同学都知道,在大促来临时,整个集群的最高峰压力将是正常时间的几十倍,最...
  • 大促之前全链路压测原理篇大促之前全链路压测原理篇全链路压测的意义链路压测方案刨析线下压测预生产环境压测引流压测全链路压测四种压测方案对比全链路压测概述什么是全链路压测解决什么问题精确的容量规划进行全...
  • 文章目录为什么要压测压测工具rally安装rally 相关术语被压测 ES 硬件资源压测执行压测结果总结 为什么要压测 俗话说"知己知彼,百战不殆",当我们上线一个新的系统或应用的时候,至少要知道这个系统或应用的上线在...
  • ④是否提供压测方案以及计划,PS:几乎也是没有的,此时用大部分项目通用的方案 ⑤压测执行的时间 ⑥如有特殊要求的,则另行处理(如需要高并发—超过1500,需要PM单独向运维申请额外的测试机,进行分布式压测) 2、...
  • 点击上方“朱小厮的博客”,选择“设为星标”后台回复"书",获取后台回复“k8s”,可领取k8s资料在阿里淘宝 双11 的过程中,长期以来都是在生产环节做全链路压测的,通过实...
  • rally文档:http://esrally.readthedocs.io/en/latest/quickstart.html由于 ...然而在引入新的解决方案前,不免要做一番调研和测试,本文便是介绍官方的一个 es 压测工具 esrally,希望能为大家带来帮助。为什...
  • 生产压测必要条件:生产压测选择生产压测必要条件,具体”生产压测必要条件“章节 其他参考性能指标:可以是默认的几项,也可是其他自定义项。 环境机型:填写被测环境应用机型,非生产环境压测,填写生产环境及...
  • 基于TCPCopy的仿真压测方案 一、tcpcopy工具介绍 tcpcopy 是一个分布式在线压力测试工具,可以将线上流量拷贝到测试机器,实时的模拟线上环境,达到在程序不上线的情况下实时承担线上流量的效果...
  • 通过实践我们发现在生产环境中做压测,实际上会和一个 IT 组织的结构、成熟度、流程等紧密相关,所以我们把全链路压测从简单的制作范围内脱离出来,变成整个业务连续性的方案。本文分四个方面为大家阐述:第一,整个...
  • 压测方案文档1、目标2、压测目标3、压测范围4、准则4.1 启动准则4.2 结束准则4.3 暂停 / 再启动准则5、业务指标 / 性能指标6、系统架构图6.1 1、目标 2、压测目标 3、压测范围 4、准则 4.1 启动准则 4.2 结束准则 ...
  • http://www.51testing.com/html/19/n-4457519.html
  • 有赞在双十一之前完成了全链路压测方案,并把它用于大促的扩容和容量验证,取得了不错的成果。 在电商公司待过的技术同学都知道,在大促来临时,整个集群的最高峰压力将是正常时间的几十倍,最高峰持续的时间会特别...
  • 压测和防止压测方案

    千次阅读 2017-12-15 09:42:21
    压测、防止压测方案 1. 压测 (1) 压测工具:ab (2) 压测请求方式:get (3) 压测域名:url (4) 压测方案:10万请求,500并发 (5) 压测脚本 ab -n 100000 -c 500 url (6) 展示压测结果   从上面分析...
  • jmeter后台http压测使用方法

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 23,048
精华内容 9,219
关键字:

压测方案