精华内容
下载资源
问答
  • nGrinder压力测试平台安装及脚本介绍

    千次阅读 2018-10-26 15:19:57
    nGrinder是一个压力测试平台,使您可以同时执行脚本创建,测试执行,监视和结果报告生成器。开源nGrinder通过消除不便并提供集成环境,提供简单的方法来进行压力测试。 特征 使用Jython或Groovy脚本创建测试场景并...

    nGrinder

    nGrinder简介

    nGrinder是一个压力测试平台,使您可以同时执行脚本创建,测试执行,监视和结果报告生成器。开源nGrinder通过消除不便并提供集成环境,提供简单的方法来进行压力测试。

    特征

    • 使用Jython或Groovy脚本创建测试场景并使用多个代理在JVM中生成压力。
    • 使用自定义库(jar,py,maven依赖项)扩展测试。它是无限的。
    • 为项目管理,监控,结果管理和报告管理提供基于Web的界面。
    • 在IDE中开发和测试Groovy脚本,并在分布式代理中运行它。
    • 同时运行多个测试。分配预先安装的多个代理以最大化每个代理的利用率。
    • 在多个网络区域上部署代理。在各种网络位置执行测试
    • 嵌入Subversion来管理脚本。
    • 允许监控产生压力的代理状态和接收压力的目标机器
    • 经过验证的解决方案,用于测试拥有超过1亿用户的大型系统。

    下载

    您可以通过以下链接下载最新版本

    文档

    您可以在以下链接中找到安装指南。

    您可以在以下链接中找到用户指南。

    总体架构

    nGrinder 是一款在一系列机器上执行 Groovy 或 Jython 测试脚本的应用,内部引擎是基于 Grinder。 nGrinder 使用 controller 和 agent 分别包装了 Grinder 的 console 和 agent ,而且扩展了多种功能使其能够支持并发测试。

    组件介绍

    Controller

    • 提供性能测试的web接口。
    • 协调测试进程。
    • 整理和显示测试的统计结果
    • 让用户创建和修改脚本。
    • nGrinder 从 3.1 版本开始支持 controller 集群
      主要就是我们下载的war包使用tomcat容器运行的平台 ,相当于前端控制器。

    Agent

    • 在代理服务器上加载运行测试进程和线程
    • 监控目标机器的系统性能(例如:CPU/MEMORY)

    由前端控制器操作实际支配的肉鸡,命运较惨,主要执行前端控制器下达的各种任务。

    运行在肉鸡系统中有一定先决条件,需要安装Jdk1.8

    测试服务器安装Controller

    • 在下载地址下载最新版本ngrinder-controller-3.4.2.war
    • 修改war包名称为ngrinder(或者其他 你开心就好)
    • 准备tomcat运行环境服务器、保证安装Jdk1.8和tomcat 并正常运行。
    • 将ngrinder.war包拷贝至服务器tomcat下/webhapps目录下
    • 启动tomcat服务器
    • 访问http://localhost:8080/ngrinder

    测试肉鸡服务器安装Agent

    • 准备Agent肉鸡服务器 若干台需要安装Jdk1.8;
    • 登录Controller控制器网站登录
    • 用户名下展开后点击下载Agent(代理)
    • 将Agent代理拷贝至肉鸡服务器
    • 解压缩后运行run.agent.bat.

    被测服务器安装Monitor

    • Agent服务器安装好Agent后是不需要安装Monitor的自动集成了
    • 需要在被测试的机器中安装Monitor以监控在测试期间被测服务器的性能表现;
    • 登录Controller控制器网站登录、用户下展开后点击下载监控(Monitor)
    • 拷贝至被测试服务器运行run.monitor.bat

    快速入门测试

    • 登录系统后有个快速开始的框,在此输入http://www.baidu.com,点击开始测试。
    • 这时候进入第二个页面配置运行参数 agent(?需要几台机器) 持续多长时间
    • 点击保存并开始,立即运行;
    • 查看运行后的测试报告;

    脚本开发介绍

    import HTTPClient.Cookie
    import HTTPClient.CookieModule
    import HTTPClient.HTTPResponse
    import HTTPClient.NVPair
    import net.grinder.plugin.http.HTTPPluginControl
    import net.grinder.plugin.http.HTTPRequest
    import net.grinder.script.GTest
    import net.grinder.scriptengine.groovy.junit.GrinderRunner
    import net.grinder.scriptengine.groovy.junit.annotation.BeforeProcess
    import net.grinder.scriptengine.groovy.junit.annotation.BeforeThread
    import org.junit.Before
    import org.junit.Test
    import org.junit.runner.RunWith
    
    import static net.grinder.script.Grinder.grinder
    import static org.hamcrest.Matchers.is
    import static org.junit.Assert.assertThat
    
    
    @RunWith(GrinderRunner)
    class TestRunner {
    
        public static GTest test
        public static HTTPRequest request
        public static NVPair[] headers = []
        public static NVPair[] params = []
        public static Cookie[] cookies = []
    
        @BeforeProcess
        public static void beforeProcess() {
            HTTPPluginControl.getConnectionDefaults().timeout = 6000
            test = new GTest(1, "www.baidu.com")
            request = new HTTPRequest()
    
            // 设置请求头数据
            List<NVPair> headerList = new ArrayList<NVPair>()
            headerList.add(new NVPair("test_header", "test_header_value"))
            headers = headerList.toArray()
    
            // 设置请求参数
            List<NVPair> paramList = new ArrayList<NVPair>()
            paramList.add(new NVPair("paramname", "vaule"))
            params = paramList.toArray()
    
            // 设置 cookie 信息
            List<Cookie> cookieList = new ArrayList<Cookie>()
            cookieList.add(new Cookie("username", "testname", "www.baidu.com", "/", new Date(), false))
            cookies = cookieList.toArray()
    
            // 记录日志
            grinder.logger.info("before process.")
        }
    
        @BeforeThread
        public void beforeThread() {
            test.record(this, "test")
            // 配置延迟报告统计结果
            grinder.statistics.delayReports = true
            // 记录日志
            grinder.logger.info("before thread.")
        }
    
        @Before
        public void before() {
            // 设置本次请求头
            request.setHeaders(headers)
            // 设置本次请求的 cookies
            cookies.each { CookieModule.addCookie(it, HTTPPluginControl.getThreadHTTPClientContext()) }
            // 记录日志
            grinder.logger.info("before thread. init headers and cookies")
        }
    
        @Test
        public void test() {
            HTTPResponse result = request.GET("http://www.baidu.com", params)
    
            if (result.statusCode == 301 || result.statusCode == 302) {
                grinder.logger.warn("Warning. The response may not be correct. The response code was {}.", result.statusCode)
            } else {
                assertThat(result.statusCode, is(200))
            }
        }
    }
    

    静态变量说明

    public static GTest test
    public static HTTPRequest request
    public static NVPair[] headers = []
    public static NVPair[] params = []
    public static Cookie[] cookies = []
    
    
    1. 定义 GTest 静态变量 test
    2. 定义 HTTPRequest 静态变量 request,用于发送 HTTP 请求
    3. 定义 NVPair 数组 headers ,用于存放通用的请求头数据
    4. 定义 NVPair 数组 params ,用于存放请求参数数据
    5. 定义 Cookie 数组 cookies ,用于存放通用的 cookie 数据

    初始化进程级数据

    使用 @BeforeProcess 注释的方法,定义了在 进程 被调用之前应执行的行为

    @BeforeProcess
    public static void beforeProcess() {
        // HTTP请求超时时间,单位毫秒
        HTTPPluginControl.getConnectionDefaults().timeout = 6000
        test = new GTest(1, "www.baidu.com")
        request = new HTTPRequest()
    
        // 设置请求头数据
        List<NVPair> headerList = new ArrayList<NVPair>()
        headerList.add(new NVPair("test_header", "test_header_value"))
        headers = headerList.toArray()
    
        // 设置请求参数
        List<NVPair> paramList = new ArrayList<NVPair>()
        paramList.add(new NVPair("paramname", "vaule"))
        params = paramList.toArray()
    
        // 设置 cookie 信息
        List<Cookie> cookieList = new ArrayList<Cookie>()
        cookieList.add(new Cookie("username", "testname", "www.baidu.com", "/", new Date(), false))
        cookies = cookieList.toArray()
    
        // 记录日志
        grinder.logger.info("before process.")
    }
    
    
    1. 首先设置了HTTP请求超时时间,单位毫秒.
    2. GTest是对测试记录进行统计的单元,脚本内,每个 GTest 对象都使用唯一的编号定义,可以有描述信息,使用 GTest 的构造方法 GTest(int number, String description) 创建。如果创建了多个编号一样的对象,最后只会选用第一个
    3. 使用 new HTTPRequest() 创建 HTTPRequest 对象,用于发起 HTTP 请求
    4. 请求头和请求参数,都是键值对对象 NVPair 类型的数组
    5. 可以通过 Cookie(String name, String value, String domain, String path, Date expires, boolean secure) 构造 cookie 对象,然后存放到相应的数组中,方便后面使用
    6. 最后打印了执行日志

    初始化线程级数据

    使用 @BeforeThread 注释的方法,定义了在 线程 被调用之前应执行的行为

    @BeforeThread
    public void beforeThread() {
        test.record(this, "test")
        // 配置延迟报告统计结果
        grinder.statistics.delayReports = true
        // 记录日志
        grinder.logger.info("before thread.")
    }
    
    
    1. 使用 GTest 的 record(Object target, String methodName) 给 GTest 配置需要进行统计的方法,target 只脚本对象,这里是 this, methodName 是需要统计的方法名,通常都是被 @Test 注释的方法。如果未配置,方法会正常执行,但是没有统计结果数据,每一个被 @Test 注释的方法都是一个整体事务,在运行测试时,即便里面有 多次 HTTP 请求也只做一次统计。
    2. 配置延迟报告统计结果
    3. 最后打印了执行日志

    初始化测试级别数据

    使用 @Before 注释的方法,定义每个被 @Test 注解的方法被执行前应执行的行为

    @Before
    public void before() {
        // 设置本次请求头
        request.setHeaders(headers)
        // 设置本次请求的 cookies
        cookies.each { CookieModule.addCookie(it, HTTPPluginControl.getThreadHTTPClientContext()) }
        // 记录日志
        grinder.logger.info("before thread. init headers and cookies")
    }
    
    1. 设置本次请求头
    2. 设置本次请求的 cookies
    3. 最后打印了执行日志

    定义测试行为

    使用 @Test 注释的方法,定义测试行为,被执行多次

    @Test
    public void test() {
        // 发起 GET 请求
        HTTPResponse result = request.GET("http://www.baidu.com", params)
    
        if (result.statusCode == 301 || result.statusCode == 302) {
            grinder.logger.warn("Warning. The response may not be correct. The response code was {}.", result.statusCode)
        } else {
            assertThat(result.statusCode, is(200))
        }
    }
    
    1. 通过 request.GET 方法发起 HTTP 的 GET 请求,也可以使用它的重载方法,在次数执行请求头
    2. 根据请求的返回结果分别进行处理,如果是 HTTP 的返回状态码为重定向,则打日志,当然您可以做其他处理,否则,使用断言 assertThat 方法进行结果验证,会自动进入统计结果中。
    3. HTTPRequest 对象还有其他的请求方法:POSTPUTDELETE 等。
    展开全文
  • 构建企业级自动化压力测试平台

    千次阅读 2017-04-06 12:42:20
    构建企业级自动化压力测试平台,一方面能够减少测试工程师花费在测试准备和重复性工作上的时间,另一方面能让测试工程师从繁复的低价值工作中解放出来,专注于发现性能问题。

    企业要求软件交付的时间越来越短,用户对软件产品体验的要求越来越高,软件性能作为决定用户体验的关键要素,性能测试这道坎必须坚持不懈,不能放松。

    如果还是采用传统的性能测试方式,每次版本迭代由测试工程师准备环境和数据、开发脚本,进行测试,至少要花费好几天甚至好几周的功夫,效率上明显是跟不上的。采用自动化的压力测试策略,将测试环境和数据准备工作自动化,每次只对增量功能由测试工程师进行脚本开发和测试,存量功能由测试平台自动进行测试,能够显著提高测试效率和质量。

    构建企业级自动化压力测试平台,一方面能够减少测试工程师花费在测试准备和重复性工作上的时间,另一方面能让测试工程师从繁复的低价值工作中解放出来,专注于发现性能问题。

    如何构建企业级自动化压力测试平台呢?

    自动化压力测试平台至少需要包含3个部件:脚本开发客户端,自动调度和管理服务端,大数据统计分析端。

    脚本开发客户端:快速完成可复用、兼容和扩展性强的脚本开发。

    自动调度和管理服务端:管理测试脚本和测试任务,管理负载机和测试结果,自动生成测试报告

    大数据统计分析端:聚合所有测试相关数据,对测试结果进行图表分析和穿透查询分析。

    如何选择脚本开发客户端?

    脚本开发客户端有很多商业或开源的工具可供选择,如Loadrunner、Jmeter、Gatling、Grinder、Locust、HyperPacer等,具体选择哪一个可以从以下方面考虑:

    • 灵活强大的脚本编程能力:具备丰富和函数库和数据处理组件,具备强大的扩展开发能力,具备灵活调用外部组件库的能力。
    • 指标化的结果数据转储能力:能够将测试结果以指标化的数据格式转储到大数据统计分析系统。
    • 具备脚本后端执行调度能力:能在服务器上通过命令行或后端进程的方式解析和执行脚本。

    自动调度和管理服务端,一般都需要自行开发,商业产品很昂贵,扩展应用难度高,开源的产品几乎没有。一般来说,自动调度和管理服务端至少要具有以下功能:

    • 脚本管理功能:能够将客户端开发的脚本进行统一存储和管理。
    • 任务管理功能:能够新建测试任务,支持立即执行和按计划任务执行,支持通过接口调度触发执行。
    • 负载机管理:执行负载机的增删改查和负载能力配置。
    • 测试报告管理:能够自动通用生成测试报告。

    由于压力测试过程中会产生大量的测试统计数据,自行开发统计分析平台难度较高,幸运的是目前有很多开源的产品可供选择,比如ELK Stack。选择大数据统计分析端,可以从以下方面考虑:

    • 强大的数据汇总和聚合分析能力
    • 多样化的图表展示能力

    HyperPacer自动化压力测试平台实现架构

    展开全文
  • 背景 当你的系统流量有大的增长,比如类似“双十一”的流量,那么你在...压力测试(简称为压测)这个名词儿,相信你在业界的分享中一定听过很多次,当然了,你也可能在项目的研发过程中做过压力测试,所以,对于你来

    背景

    当你的系统流量有大的增长,比如类似“双十一”的流量,那么你在面临性能问题时就可能会手足无措。为了解决这个问题,你会需要去了解,当在流量增长若干倍的时候,系统中的哪些组件或者服务会成为整体系统的瓶颈点,这时你可能就需要做一次全链路的压力测试了。

    在我过去的互联网项目经验中(电商),流量成倍的增长遇到了很多次,比如十倍的增长,做了很多次全链路的压力测试,也的确经历了一些坑,所以本文主要介绍怎样去设计一个全链路压力测试平台的经验,希望对你有用。

    内容

    首先,到底什么是压力测试呢?要如何来做全链路的压测呢?

    什么是压力测试

    压力测试(简称为压测)这个名词儿,相信你在业界的分享中一定听过很多次,当然了,你也可能在项目的研发过程中做过压力测试,所以,对于你来说,压力测试并不陌生。

    不过,我想让你回想一下,自己是怎么做压力测试的?是不是像很多同学一样:先搭建一套与正式环境功能相同的测试环境,并且导入或者生成一批测试数据,然后在另一台服务器,启动多个线程并发地调用需要压测的接口(接口的参数一般也会设置成相同的,比如,想要压测获取商品信息的接口,那么压测时会使用同一个商品 ID)。最后,通过统计访问日志或者查看测试环境的监控系统,来记录最终压测 QPS 是多少之后,直接交差?

    这么做压力测试其实是不正确的,错误之处主要有以下几点:

    • 首先,做压力测试时,最好使用线上的数据和线上的环境。因为,你无法确定自己搭建的测试环境与正式环境的差异,是否会影响到压力测试的结果。
    • 其次,压力测试时不能使用模拟的请求而是要使用线上的流量。你可以通过拷贝流量的方式,把线上流量拷贝一份到压力测试环境。因为模拟流量的访问模型和线上流量相差很大,会对压力测试的结果产生比较大的影响。比如,你在获取商品信息的时候,线上的流量会获取不同商品的数据,这些商品的数据有的命中了缓存,有的没有命中缓存。如果使用同一个商品 ID 来做压力测试,那么只有第一次请求没有命中缓存,而在请求之后会将数据库中的数据回种到缓存,后续的请求就一定会命中缓存了,这种压力测试的数据就不具备参考性了。
    • 不要从一台服务器发起流量,这样很容易达到这台服务器性能瓶颈,从而导致压力测试的 QPS 上不去,最终影响压力测试的结果。而且,为了尽量真实地模拟用户请求,我们倾向于把流量产生的机器放在离用户更近的位置,比如放在 CDN 节点上。如果没有这个条件,那么可以放在不同的机房中,这样可以尽量保证压力测试结果的真实性。

    之所以有很多同学出现这个问题,主要是对压力测试的概念没有完全理解,以为只要是使用多个线程并发的请求服务接口,就算是对接口进行压力测试了。

    那么究竟什么是压力测试呢?

    压力测试指的是在高并发大流量下进行的测试,测试人员可以通过观察系统在峰值负载下的表现,从而找到系统中存在的性能隐患。

    压力测试是一种常见的发现系统中存在问题的方式,也是保障系统可用性和稳定性的重要手段。而在压力测试的过程中,我们不能只针对某一个核心模块来做压测,而需要将接入层、所有后端服务、数据库、缓存、消息队列、中间件以及依赖的第三方服务系统及其资源,都纳入压力测试的目标之中。因为,一旦用户的访问行为增加,包含上述组件服务的整个链路都会受到不确定的大流量的冲击。因此,它们都需要依赖压力测试来发现可能存在的性能瓶颈,这种针对整个调用链路执行的压力测试也称为“全链路压测”

    由于在互联网项目中,功能迭代的速度很快,系统的复杂性也变得越来越高,新增加的功能和代码很可能会成为新的性能瓶颈点。也许半年前做压力测试时,单台机器可以承担每秒 1000 次请求,现在很可能就承担每秒 800 次请求了。所以,压力测试应该作为系统稳定性保障的常规手段,周期性地进行。

    但是,通常做一次全链路压力测试,需要联合 DBA、运维、依赖服务方、中间件架构等多个团队,一起协同进行,无论是人力成本还是沟通协调的成本都比较高。同时,在压力测试的过程中,如果没有很好的监控机制,那么还会对线上系统造成不利的影响。为了解决这些问题,我们需要搭建一套自动化的全链路压测平台来降低成本和风险

    如何搭建全链路压测平台

    搭建全链路压测平台,主要有两个关键点:

    一点是流量的隔离。由于压力测试是在正式环境进行,所以需要区分压力测试流量和正式流量,这样可以针对压力测试的流量做单独的处理。

    一点是风险的控制。也就是尽量避免压力测试对于正常访问用户的影响。因此,一般来说全链路压测平台需要包含以下几个模块:

    • 流量构造和产生模块
    • 压测数据隔离模块
    • 系统健康度检查和压测流量干预模块

    整体压测平台的架构图可以是下面这样的:

    为了让你能够更清晰地了解每一个模块是如何实现的,方便你来设计适合自身业务的全链路压测平台,我会对压测平台的每一个模块做更细致的介绍。先来看看压力测试的流量是如何产生的。

    压测数据的产生

    一般来说,我们系统的入口流量是来自于客户端的 HTTP 请求。所以,我们会考虑在系统高峰期时,将这些入口流量拷贝一份,在经过一些流量清洗的工作之后(比如过滤一些无效的请求),将数据存储在像是 HBase、MongoDB 这些 NoSQL 存储组件或者云存储服务中,我们称之为流量数据工厂。

    这样,当我们要压测的时候,就可以从这个工厂中获取数据,将数据切分多份后下发到多个压测节点上了。在这里,我想强调几个,你需要特殊注意的点:

    • 首先,我们可以使用多种方式来实现流量的拷贝。
    1. 最简单的一种方式:直接拷贝负载均衡服务器的访问日志,数据就以文本的方式写入到流量数据工厂中。但是这样产生的数据在发起压测时,需要自己写解析的脚本来解析访问日志,会增加压测时候的成本,不太建议使用。
    2. 另一种方式:通过一些开源的工具来实现流量的拷贝。这里,我推荐一款轻型的流量拷贝工具GoReplay(或tcpcopy),它可以劫持本机某一个端口的流量,将它们记录在文件中,传送到流量数据工厂中。在压测时,你也可以使用这个工具进行加速的流量回放,这样就可以实现对正式环境的压力测试了。
    • 其次,如上文中提到,我们在下发压测流量时,需要保证下发流量的节点与用户更加接近,起码不能和服务部署节点在同一个机房中,这样可以尽量保证压测数据的真实性。

    另外,我们还需要对压测流量染色,也就是增加压测标记。在实际项目中,我会在 HTTP 的请求头中增加一个标记项,比如说叫做 is stress test,在流量拷贝之后,批量在请求中增加这个标记项,再写入到数据流量工厂中。

    数据如何隔离

    将压测流量拷贝下来的同时,我们也需要考虑对系统做改造,以实现压测流量和正式流量的隔离,这样一来就会尽量避免压测对线上系统的影响。一般来说,我们需要做两方面的事情。

    一方面,针对读取数据的请求(一般称之为下行流量),我们会针对某些不能压测的服务或者组件,做 Mock 或者特殊的处理,举个例子。

    在业务开发中,我们一般会依据请求记录用户的行为,比如,用户请求了某个商品的页面,我们会记录这个商品多了一次浏览的行为,这些行为数据会写入一份单独的大数据日志中,再传输给数据分析部门,形成业务报表给到产品或者老板做业务的分析决策。

    在压测的时候,肯定会增加这些行为数据,比如原本一天商品页面的浏览行为是一亿次,而压测之后变成了十亿次,这样就会对业务报表产生影响,影响后续的产品方向的决策。因此,我们对于这些压测产生的用户行为做特殊处理,不再记录到大数据日志中。

    再比如,我们系统会依赖一些推荐服务,推荐一些你可能感兴趣的商品,但是这些数据的展示有一个特点就是展示过的商品就不再会被推荐出来。如果你的压测流量经过这些推荐服务,大量的商品就会被压测流量请求到,线上的用户就不会再看到这些商品了,也就会影响推荐的效果。

    所以,我们需要 Mock 这些推荐服务,让不带有压测标记的请求经过推荐服务,而让带有压测标记的请求经过 Mock 服务。搭建 Mock 服务,你需要注意一点:这些 Mock 服务最好部署在真实服务所在的机房,这样可以尽量模拟真实的服务部署结构,提高压测结果的真实性。

    另一方面,针对写入数据的请求(一般称之为上行流量),我们会把压测流量产生的数据写入到影子库,也就是和线上数据存储完全隔离的一份存储系统中。

    针对不同的存储类型,我们会使用不同的影子库的搭建方式。

    1. 如果数据存储在 MySQL 中,我们可以在同一个 MySQL 实例,不同的 Schema 中创建一套和线上相同的库表结构,并且把线上的数据也导入进来。
    2. 而如果数据是放在 Redis 中,我们对压测流量产生的数据,增加一个统一的前缀,存储在同一份存储中。
    3. 还有一些数据会存储在 Elasticsearch 中,针对这部分数据,我们可以放在另外一个单独的索引表中。

    通过对下行流量的特殊处理以及对上行流量增加影子库的方式,我们就可以实现压测流量的隔离了。

    压力测试如何实施

    在拷贝了线上流量和完成了对线上系统的改造之后,我们就可以进行压力测试的实施了。在此之前,一般会设立一个压力测试的目标,比如说,整体系统的 QPS 需要达到每秒 20 万。

    不过,在压测时,不会一下子把请求量增加到每秒 20 万次,而是按照一定的步长(比如每次压测增加一万 QPS),逐渐地增加流量。在增加一次流量之后,让系统稳定运行一段时间,观察系统在性能上的表现。如果发现依赖的服务或者组件出现了瓶颈,可以先减少压测流量,比如,回退到上一次压测的 QPS,保证服务的稳定,再针对此服务或者组件进行扩容,然后再继续增加流量压测。

    为了能够减少压力测试过程中人力投入成本,可以开发一个流量监控的组件,在这个组件中,预先设定一些性能阈值。比如,容器的 CPU 使用率的阈值可以设定为 60%~70%;系统的平均响应时间的上限可以设定为 1 秒;系统慢请求的比例设置为 1% 等等。

    当系统性能达到这个阈值之后,流量监控组件可以及时发现,并且通知压测流量下发组件减少压测流量,并且发送报警给到开发和运维的同学,开发和运维同学就迅速地排查性能瓶颈,在解决问题或者扩容之后再继续执行压测。

    业界关于全链路压测平台的探索有很多,一些大厂比如阿里、京东、美团和微博都有了适合自身业务的全链路压测平台。在我看来,这些压测平台万变不离其宗,都无非是经过流量拷贝、流量染色隔离、打压、监控熔断等步骤,与本文中介绍的核心思想都是相通的。因此,你在考虑自研适合自己项目的全链路压测平台时,也可以遵循这个成熟的套路。

    最后总结

    我带你了解了做压力测试常见的误区,以及自动化的全链路压测平台的搭建过程,这里你需要了解的重点是:

    1. 压力测试是一种发现系统性能隐患的重要手段,所以应该尽量使用正式的环境和数据;
    2. 对压测的流量需要增加标记,这样就可以通过 Mock 第三方依赖服务和影子库的方式来实现压测数据和正式数据的隔离;
    3. 压测时,应该实时地对系统性能指标做监控和告警,及时地对出现瓶颈的资源或者服务扩容,避免对正式环境产生影响。

    这套全链路的压力测试系统对于我们来说有三方面的价值:

    • 其一,它可以帮助我们发现系统中可能出现的性能瓶颈,方便我们提前准备预案来应对;
    • 其次,它也可以为我们做容量评估,提供数据上的支撑;
    • 最后,我们也可以在压测的时候做预案演练,因为压测一般会安排在流量的低峰期进行,这样我们可以降级一些服务来验证预案效果,并且可以尽量减少对线上用户的影响。

    所以,随着你的系统流量的快速增长,你也需要及时考虑搭建这么一套全链路压测平台,来保证你的系统的稳定性。

     

    推荐资料

    我的专栏

     

     

    至此,全部介绍就结束了

     

     

    -------------------------------

    -------------------------------

     

    我的CSDN主页

    关于我(个人域名,更多我的信息)

    我的开源项目集Github

     

    期望和大家一起学习,一起成长,共勉,O(∩_∩)O谢谢

    欢迎交流问题,可加个人QQ 469580884,

    或者,加我的群号 751925591,一起探讨交流问题

    不讲虚的,只做实干家

    Talk is cheap,show me the code

    展开全文
  • DDOS压力测试平台源码

    2021-04-09 23:15:49
    介绍: 二开的脚本,能打300G,源码里带卖发包机的联系方式。 买个发包机就可以用了,支持卡密支付,解决收款问题 网盘下载地址: http://kekewangLuo.cc/qFbw09gFSA9 图片:

    介绍:

    二开的脚本,能打300G,源码里带卖发包机的联系方式。
    买个发包机就可以用了,支持卡密支付,解决收款问题


    网盘下载地址:

    http://kekewangLuo.cc/qFbw09gFSA9


    图片:


    展开全文
  • 压力测试环境搭建繁琐 流程手工部署,易出错 鉴于以上问题,团队决定搭建一套压测平台。 2.目标 产品质量组建立20000并发压测环境,为日投放100万的APP产品提供支持,要求: 灵活扩展压测资源 易于部署,易于使用...
  • https://www.jianshu.com/p/07cc702069ec https://www.cnblogs.com/jwentest/p/7136727.html
  • nGrinder是一个用于在多台机器上运行用jython(在JVM上运行的python)编写的测试脚本的应用程序。它的内部引擎是基于Grinder。nGrinder分别用控制器和agent将Grinder的控制台和agent包装起来,并扩展了支持多个并发...
  • 为验证平台实现的可行性,利用COTS工具并结合自主开发构建了一个小规模的压力测试服务平台,与一般压力测试平台进行了对比测试。实验结果表明,基于Vlab的压力测试服务平台能保证测试结果的有效性,同时提高测试效率...
  • Azure平台 Netty压力测试

    千次阅读 2016-04-19 10:58:08
    Azure平台 Netty压力测试测试环境: Azure Paas平台作为Server,一个 Azure Iaas平台作为Client,多个 Netty Nio作为Server的代码 Java.net.Socket最为Client的代码 测试经过1、原因 公司没有多余的服务器进行测试...
  • 基于renren-fast开源框架的,二次开发搭建的性能、接口测试平台,同时集成三方工具的启停操作,便于管理。本项目基于csdn博主smooth00的文章及其开源的代码进行二次开发,文章链接:...
  • nGrinder是一个免费的、开放源代码的Web性能测试平台。运行在应用中间件服务器中运行。它由一个控制端和多个代理端组成。通过控制端(浏览器访问)建立测试场景,然后通过分发到代理端进行压力测试,是一个分布式的...
  • 新手机12G的RAM,比自用的本子内存都大,如果只是玩游戏感觉不能完全发挥出全部机能,但又因为怕影响日常使用没有进行root,经过一番折腾,发现即使不root也不影响把它变成一款测试利器,有同类需求的可以参考此文。...
  • 1、LAMP平台,虚拟机Centos7.4操作系统,2G内存。Apache版本为Apache/2.4.6 (CentOS),Mysql版本为Mysql-5.17.7,PHP版本为PHP 5.4.16 IP地址为172.17.2.199 2、LNMP平台,虚拟机Centos7.4操作系统,2G内存。...
  • 交通部压力测试工具操作手册,用于部标808GPS平台过检的时候,使用此手册作为压测的技术规范,指导开发人员进行压力测试
  • Cloud Performance Test 云压力测试平台(以下简称:CPT)可以提供一站式全链路云压力测试服务,通过分布式压力负载机,快速搭建系统高并发运行场景,按需模拟千万级用户实时访问,并结合系统资源状态,评估系统承载...
  • 基准测试可以理解为针对系统的一种压力测试。但基准测试不关心业务逻辑,更加简单、直接、易于测试,数据可以由工具生成,不要求真实;而压力测试一般考虑业务逻辑(如购物车业务),要求真实的数据。 系统环境:...
  • 找完工作之后好久没上博客园了 终于如愿成为一名后台程序员 自己这一年多的努力得到了...论文第五章对网站进行了压力测试 但是由于阿里云那边最近在审核网站 之前的域名没法用了 所以网站测试遇到了问题 1.下载本...
  • 之前讨论了如何完成一次云压力测试,也介绍了如何利用睿象云旗下产品:云压力测试平台(CPT)完成云压力的测试,这次我们就来详细的介绍下测试报告。 测试报告可以说是测试工作中最重要组成部分,通过测试报告可以...
  • Cloud Performance Test 云压力测试平台(以下简称:CPT)可以提供一站式全链路云压力测试服务,通过分布式压力负载机,快速搭建系统高并发运行场景,按需模拟千万级用户实时访问,并结合系统资源状态,评估系统承载...
  • 市面上流行的压力/负载/性能测试工具多是来自国外,近年来国内的性能测试工具也如雨后春笋般崛起,但大部分产品是基于Jmeter开源内核包装起来的性能测试工具,其中也不乏佼佼者,如:kylinTOP测试与监控平台,它是一...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 1,454
精华内容 581
关键字:

压力测试平台