前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
社区首页 >专栏 >性能测试中标记每个请求

性能测试中标记每个请求

作者头像
FunTester
发布于 2020-01-17 01:58:35
发布于 2020-01-17 01:58:35
41300
代码可运行
举报
文章被收录于专栏:FunTesterFunTester
运行总次数:0
代码可运行

在做性能测试过程中,遇到一个棘手的问题,开发让我们复现几个请求时间较长的请求,他们看日志进行链路追踪,查找瓶颈所在。

这里说一下框架中的处理逻辑:每个请求有一个唯一的requestid,由几部分组成,还有一些算法保证其唯一性。然后这个requestID贯穿整个请求过程的日志,服务间的相互调用,与数据库中间件的交互都依赖于这个requestID。

以往压测都是写了一个请求ID,并未对这个header做处理,现在得搞起来了。

首先我先新建了一个Java interface,用于使用闭包直接完成这个功能,还有就是其他标记方法:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
package com.fun.base.interfaces;

import org.apache.http.client.methods.HttpRequestBase;

import java.io.Serializable;

/**
 * 用来标记request,为了记录超时的请求
 */
public interface MarkRequest extends Serializable {

    /**
     * 用来标记base,删除header其中一项,添加一项
     *
     * @param base
     * @return
     */
    public String mark(HttpRequestBase base);


}

然后我再ThreadLimitTimesCountThreadLimitTimeCount实现类中使用这个接口对象,两个实现类的代码已经发过了性能测试框架第二版,这里只写一个:

  • 中间用到了深拷贝的方法,在之前也记录过了拷贝HttpRequestBase对象,目前是每一个线程对应一个mark对象,而不是多线程共享,下面会看到效果。
代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
package com.fun.frame.thead;

import com.fun.base.constaint.ThreadLimitTimesCount;
import com.fun.base.interfaces.MarkRequest;
import com.fun.config.Constant;
import com.fun.config.HttpClientConstant;
import com.fun.frame.Save;
import com.fun.frame.excute.Concurrent;
import com.fun.frame.httpclient.FanLibrary;
import com.fun.frame.httpclient.FunRequest;
import com.fun.frame.httpclient.GCThread;
import com.fun.utils.Time;
import org.apache.http.client.methods.HttpRequestBase;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

import java.util.ArrayList;
import java.util.List;
import java.util.Vector;

/**
 * http请求多线程类
 */
public class RequestThreadTimes extends ThreadLimitTimesCount {

    private static final long serialVersionUID = -2751325651625435070L;

    static Logger logger = LoggerFactory.getLogger(RequestThreadTimes.class);

    /**
     * 记录总的请求超时的情况
     */
    public static Vector<String> requestMark = new Vector<>();

    /**
     * 请求
     */
    public HttpRequestBase request;

    /**
     * 标记对象
     */
    public MarkRequest mark;

    /**
     * 记录当前线程超时请求
     */
    public List<String> marks = new ArrayList<>();

    /**
     * 单请求多线程多次任务构造方法
     *
     * @param request 被执行的请求
     * @param times   每个线程运行的次数
     */
    public RequestThreadTimes(HttpRequestBase request, int times) {
        this.request = request;
        this.times = times;
        this.mark = new MarkRequest() {

            private static final long serialVersionUID = 5599842482575655279L;

            @Override
            public String mark(HttpRequestBase base) {
                return EMPTY;
            }
        };
    }

    /**
     * 应对对每个请求进行标记的情况
     *
     * @param request
     * @param times
     * @param mark
     */
    public RequestThreadTimes(HttpRequestBase request, int times, MarkRequest mark) {
        this(request, times);
        this.mark = mark;
    }

    protected RequestThreadTimes() {
        super();
    }

    @Override
    public void before() {
        super.before();
        GCThread.starts();
    }

    /**
     * @throws Exception
     */
    @Override
    protected void doing() throws Exception {
        FanLibrary.excuteSimlple(request);
    }

    @Override
    protected void after() {
        requestMark.addAll(marks);
        GCThread.stop();
        synchronized (RequestThreadTimes.class) {
            if (countDownLatch.getCount() == 0) Save.saveStringList(requestMark, Constant.DEFAULT_STRING);
        }
    }

    @Override
    public void run() {
        try {
            before();
            List<Long> t = new ArrayList<>();
            long ss = Time.getTimeStamp();
            for (int i = 0; i < times; i++) {
                try {
                    String m = this.mark.mark(request);
                    long s = Time.getTimeStamp();
                    doing();
                    long e = Time.getTimeStamp();
                    long diff = e - s;
                    t.add(diff);
                    if (diff > HttpClientConstant.MAX_ACCEPT_TIME) marks.add(diff + CONNECTOR + m);
                    excuteNum++;
                    if (status()) break;
                } catch (Exception e) {
                    logger.warn("执行任务失败!", e);
                    errorNum++;
                }
            }
            long ee = Time.getTimeStamp();
            logger.info("执行次数:{},错误次数: {},总耗时:{} s", times, errorNum, (ee - ss) / 1000 + 1);
            Concurrent.allTimes.addAll(t);
        } catch (Exception e) {
            logger.warn("执行任务失败!", e);
        } finally {
            if (countDownLatch != null)
                countDownLatch.countDown();
            after();
        }

    }

    @Override
    public RequestThreadTimes clone() {
        RequestThreadTimes threadTimes = new RequestThreadTimes();
        threadTimes.times = this.times;
        threadTimes.request = FunRequest.cloneRequest(request);
        threadTimes.mark = deepClone(mark);
        return threadTimes;
    }

}

我自己写了一个使用Demo:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
 def "测试并发情况下记录响应标记符的"() {
        given:
        HttpGet httpGet = FanLibrary.getHttpGet("https://cn.bing.com/");
        MarkRequest mark = new MarkRequest() {

            String m;

            @Override
            public String mark(HttpRequestBase base) {
                base.removeHeaders("requestid");
                m = m == null ? RString.getStringWithoutNum(4) : m
                String value = "fun_" + m + CONNECTOR + Time.getTimeStamp();
                base.addHeader("requestid", value);
                return value;
            }

        };
        FanLibrary.getHttpResponse(httpGet);
        HttpClientConstant.MAX_ACCEPT_TIME = -1
        RequestThreadTimes threadTimes = new RequestThreadTimes(httpGet, 2, mark);
        new Concurrent(threadTimes, 2).start();

        output(RequestThreadTimes.requestMark)

    }

下面是记录的结果如下,可以看到,一共出现了两个m的值,后面跟的是时间戳,这样既保证了requestID唯一性,也可以对线程进行归类。

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
80_fun_QkhQ_1578367527661
103_fun_QkhQ_1578367527742
101_fun_zwtk_1578367527661
107_fun_zwtk_1578367527763

  • 郑重声明:文章首发于公众号“FunTester”,禁止第三方(腾讯云除外)转载、发表。
本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2020-01-11,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 FunTester 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
暂无评论
推荐阅读
编辑精选文章
换一批
性能测试框架第三版
本次主要更新了标记、记录功能,以及初始化连接池的方法。具体实现请参考之前的文章:性能测试中标记每个请求、如何性能测试中进行业务验证、如何在匿名thread子类中保证线程安全、- 性能测试中记录每一个耗时请求。
FunTester
2020/02/17
6170
性能测试中记录每一个耗时请求
在之前的文章性能测试中标记每个请求中提到,把每一个接口都进行requestID的标记,接下来的工作就简单了,就是设置各种超时配置,然后进行压测,会记录超时的请求ID和响应时间(采取“响应时间_requestID”形式),结果如图:
FunTester
2020/02/17
4630
单点登录性能测试方案
项目登录系统升级,改为单点登录:英文全称Single Sign On。SSO是在多个应用系统中,用户只需要登录一次就可以访问所有相互信任的应用系统。 之前有的统一登录方式被废弃,由于单点登录比较之前的登录系统复杂很多。之前的方案请求一个接口即可获得用户校验令牌。 先分享一下单点登录的技术方案的时序图:
FunTester
2019/10/08
1.6K0
单点登录性能测试方案
性能测试框架第二版
依照领导要求区分了两种压测模式:固定次数压测和固定时间压测。此前一直沿用的都是固定次数,所以本次第二版剥离了固定次数的模式增加了固定时间的模式。
FunTester
2019/12/05
4170
浅谈单元测试
很早之前在学习使用Java做测试的时候,得到过一个神秘大佬的帮助,在一起聊过单元测试,基本结论就是:单元测试大概率没啥鸟用。
FunTester
2020/02/17
6170
单机12万QPS——FunTester复仇记
在文章10万QPS,K6、Gatling和FunTester终极对决!中,最后测试结果FunTester除了在在CPU方面有一丁点优势以外,内存和QPS均略逊一筹,特别是内存方面劣势尤为明显。当时立了一个flag:
FunTester
2021/08/18
4150
如何对N个接口按比例压测
随着微服务盛行,公司的服务端项目也越来越多。单一的接口性能测试并不能准确反映某个服务的总体处理能力,在服务功能划分比较清晰的架构下,对于某一服务的总体性能测试也相对变得简单。下面分享一个对于某个模块对应的服务的N个接口按照固定比例(来源于线上监控)进行性能测试,基于自己写的性能测试框架第二版。
FunTester
2020/01/17
5510
Java&Go高性能队列之LinkedBlockingQueue性能测试
在写完高性能队列Disruptor在测试中应用和千万级日志回放引擎设计稿视频版之后,我就一直在准备Java & Go 语言几种高性能消息队列的性能测试,其中选取了几种基准测试场景以及在性能测试中的应用场景。
FunTester
2022/02/08
1.4K3
拷贝HttpRequestBase对象
在实践性能测试框架第二版的过程中,我实现了一个单个HttpRequestBase对象的concurrent对象创建,单之前都是用使用唯一的HttpRequestBase对象进行多线程请求,目前来看是没有问题的,但为了防止以后出现意外BUG和统一concurrent的构造方法使用,故尝试拷贝了一个HttpRequestBase对象。原因是因为之前封装的深拷贝方法对于HttpRequestBase对象的实现类如:httpget和httppost并不适用,因为没有实现Serializable接口。所以单独写了一个HttpRequestBase对象的拷贝方法,供大家参考。
FunTester
2019/12/31
5740
链路压测中如何记录每一个耗时的请求
前文回顾:性能测试中记录每一个耗时请求,做完了单接口耗时请求的记录功能,近期又迎来了一批多接口链路压测的需求。刚好趁着这个机会,多实现一些不同场景的链路压测需求,锻炼一波,也能提高自己写的「FunTester」测试框架的兼容性,可谓一石多鸟,何乐而不为。
FunTester
2020/12/24
8500
动态模型之增压暂停【FunTester测试框架】
距离上次对FunTester测试框架功能规划之后,已经很久没有更新过功能规划了,主要因素是FunTester测试框架目前支持的功能已经完全满足工作需求。无论是分布式性能测试框架,还是全链路性能测试支持,以及量化模拟线上流量,基本技术验证都完成了,余下的都是在技术方案的上进行调整以更适应现在工作需求,不存在技术障碍。
FunTester
2021/10/20
4240
分布式性能测试框架用例方案设想(二)
书接上文分布式性能测试框架用例方案设想(一),方案二进行更加复杂的测试用例,以jar包类方法形式的用例进行测试,下期会基于docker进行技术验证。
FunTester
2021/06/23
4190
如何在Linux命令行界面愉快进行性能测试
本人在做性能测试的过程中,遇到一个问题,测试机选了一台Linux服务器,只有命令行界面。执行测试用例不是非常的灵活,有时候我需要改一两个参数添加一些日志,都需要重新打包部署,虽然自动化构建比较方便,但感觉绕了一大圈,在经过一些简单尝试之后做好了两个方案,一个是针对单接口的压测,以配置文件形式完成每一个request的组装,然后通过调节并发的参数执行不同的测试用例,且支持多个请求一起压测;另外一个以groovy脚本形式执行用例,则需要在服务器上配置好groovy环境以及把项目打包后的jar包推送到groovy的lib目录下。
FunTester
2019/07/27
1.3K0
基于HTTP请求的多线程实现类--视频讲解
上期将了定时和定量两种压测模式的虚拟类,本期分享一下基于单个HTTP请求对象HTTPrequestbase的两个压测模式的具体实现类。比较关键的就是GCThread的启动和结束,还有就是doing()方法的实现,就是把HTTPrequestbase对象发送请求然后解析响应,这里并没有去管响应结果的校验和断言,原因就是比较复杂,需要具体情况具体处理,难以通过一个通用的方法校验,还有一个原因就是很多时候没必要,可以通过监控服务端日志和其他统计方式统计相关业务数据来达到判断所有请求是否有报错和不成功的请求。其中应该着重注意就是对象拷贝,不管是多线程类对象还是HTTPrequestbase对象,如果不实现clone()方法,可能会有BUG。
FunTester
2020/05/01
4620
定时和定量压测模式实现--视频讲解
上期将了多线程基类和执行类,本期分享一下两种压测模式。一种是定量,即单线程循环次数固定;另一种是定时,即单线程执行时间固定。两种方式各有优劣,实际工作中个人偏向定量,好处多多,比较好做任务管理,参数定制等等,缺点就是误差相比定时较大,这一点可以通过适当延长压测次数达到。
FunTester
2020/04/15
3180
性能测试框架
之前写过一个性能测试框架,只是针对单一的HTTP接口的测试,对于业务接口和非HTTP接口还无非适配,刚好前段时间工作中用到了,就更新了自己的测试框架,这次不再以请求为基础,而是以方法为基础,这样就可以避免了单一性,有一个base类,然后其他的各种单一性请求在单独写一个适配类就好了,如果只是临时用,直接重新实现base即可。下面分享:
FunTester
2019/07/27
7030
固定QPS压测初试
之前写过一篇固定QPS压测模式探索文章,个人认为这个模型相比「固定线程数」并发请求压测服务的模型更加贴近实际情况,比较适合做负载测试。在最近的工作中尝试使用「固定QPS」的压测方案,有了一些实践成果(大部分还是修复了BUG),分享一下。
FunTester
2020/11/09
1.7K0
泛型类的正确用法
在准备下次直播Java基础的内容中,偶然看到Java泛型这个知识点,突然有了点想法,之前一直纠结的一个问题有了解答的思路。
FunTester
2020/10/29
8740
Java&Go高性能队列之Disruptor性能测试
之前写过Java&Go高性能队列之LinkedBlockingQueue性能测试之后,就一直准备这这篇文章,作为准备内容的过程中也写过一些Disruptor高性能消息队列的应用文章:高性能队列Disruptor在测试中应用和千万级日志回放引擎设计稿。
FunTester
2022/04/01
8910
固定QPS压测模式探索
在早前跟测试同行在QQ群聊天的时候,聊过一个固定QPS压测的问题,最近突然有需求,想实现一下,丰富一下自己的性能测试框架,最新的代码请移步我的GitHub,地址:https://github.com/JunManYuanLong/FunTester,gitee地址:https://gitee.com/fanapi/tester。
FunTester
2020/10/19
8370
相关推荐
性能测试框架第三版
更多 >
领券
社区富文本编辑器全新改版!诚邀体验~
全新交互,全新视觉,新增快捷键、悬浮工具栏、高亮块等功能并同时优化现有功能,全面提升创作效率和体验
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档
查看详情【社区公告】 技术创作特训营有奖征文
本文部分代码块支持一键运行,欢迎体验
本文部分代码块支持一键运行,欢迎体验