千万级日志回放引擎设计稿
现在压测系统一直用的方案是 goreplay 进行二次开发完成的。因为整体是 Java 技术栈的,使用 goreplay 有存在两方面问题:一是兼容性,语言和开发框架上,增加了用例创建执行的复杂度;二是维护成本,goreplay 二次开发方案已经无法满足现在的性能测试需求。如果维护两套压测引擎会带来更多工作量。
所以为了尽可能解决这两方面问题,接到了一个活儿,调研一下 Java 实现日志回放功能。主要就是读了 goreplay 的源码以及它设计思路,用 Java 重现实现一遍。
这里用到了前两天分享的Disruptor高性能队列常用API演示、高性能队列Disruptor在测试中应用,有兴趣的可以再翻一翻。另视频版还在制作中,年后会和大家相见。
思路
总体设计思路如下:
PS:流量递增和动态增减尚未实现,还在研究 goreplay 的源码。
日志拉取和解析
日志的拉取和初步解析依旧采取原来项目中的逻辑,通过 SQL 语句网关日志中拉取日志,并对日志内容进行初步解析,放入云 OSS 中,并将链接存入数据库(此步骤放在录制流量成功之后)。
PS:目前日志解析保留的有用信息只有 URL
日志格式如下:
实现步骤
首先将日志中有用信息(URL)以及 token 放到内存中
通过配置 host,读取 URL,以及响应 header(token,压测标识,常用 header,模拟盘标识)组装 HTTP 请求。
创建 Disruptor 对象,使用异步创建生产者
通过消费者消费(发出请求)消息(HTTP 请求对象),达到 HTTP 接口日志流量回复功能。
性能指标
本机 6C16G 配置测试数据
实测 1 千万 URL 读取速度约为 9s ~ 13s,内存无压力,如果后续更大日志量需求,可以通过 stream 方式异步读取日志,实测日志读取速度在 80 万/s 以上,满足目前需求。
单生产者速度 25 万 QPS
单机测试 QPS 8.8 万,CPU 跑满,触及物理极限,此数据与之前工具对比压测差异不大。
风险
消费者异步对消息进行存储,超过一定数量将会丢弃消息。这个问题在消费者速度小于生产者速度时会触发。
消费者数量需要在启动前设定,如果参数设置不合理,会导致消费者压力瓶颈,无法动态增加消费者。
PS:这些风险后续会逐个解决。
代码实现
生产者 Demo:
读取文件代码
演示 Demo
PS:这里用到了多个 group,原因在设计稿中标记了。
Have Fun ~ Tester !
版权声明: 本文为 InfoQ 作者【FunTester】的原创文章。
原文链接:【http://xie.infoq.cn/article/244b5e8ef162feb57f347963c】。文章转载请联系作者。
评论