heracles压测平台介绍-阿里云开发者社区

开发者社区> 搜索与推荐技术> 正文
登录阅读全文

heracles压测平台介绍

简介: heracles压测平台介绍 Heracles音译为赫拉克勒斯或意译为大力神.希腊语:Ηρακλής,Hēraklēs,引申自Hēra“赫拉”和kleos“荣耀”,也即赫拉的荣耀 背景 搜索和推荐的应用越来越多的时候,我们常常面临着下面几个问题: 如何能随时的了解每个应用的最大容量,当前资源可支.

heracles压测平台介绍

Heracles音译为赫拉克勒斯或意译为大力神.希腊语:Ηρακλής,Hēraklēs,引申自Hēra“赫拉”和kleos“荣耀”,也即赫拉的荣耀

背景

搜索和推荐的应用越来越多的时候,我们常常面临着下面几个问题:

  • 如何能随时的了解每个应用的最大容量,当前资源可支持多长时间的自然增长?
  • 如何评估什么样的容器规格申请是最合理的且同时满足容量需求?
  • 如何方便的进行大促的容量资源评估?

这些容量相关指标的获取,都需要压测的支持,而之前abench单机的压测工具使用起来多有不便,我们期望的压测工具能够提供以下功能:

  • 可以每日定时启动,压测到指定指标稳定住即停
  • 压力可即时调整,且能持续不间断不等待,调整到非常大的施压能力
  • 日志来源和处理要方便, 那么多应用,手工处理日志不能接受
  • 支持多种服务发现和多种访问方式

heracles压测平台应搜索和推荐应用的上述需求而生,目前已很好的支持了单服务,全链路,日常,大促等压测场景.下面简单介绍下部分实现细节.

流程与功能

总体的流程如下:
heracles

java服务和admin

  • java服务

    • 依据配置模板产出相应的任务配置,可以选择heracles后端版本,多版本共存.
    • 设置airflow定时任务
    • 控制施压qps的调整步长,以逐步达到停止阈值.
  • admin

    • 负责和hippo交互;向worker下发命令;获取worker状态
    • 依据施压压力调整worker的个数和压力. (每个worker的能力设有上限)
    • admin因发布或者机器漂移等,重启后的任务恢复
    • worker容器漂移后,重新发出指令.

worker

worker的主要数据流程如下:
heracles_worker

以下每一句话虽然简练但都包含丰富:

  • query的读取

    • 支持hdfs/odps/http数据源的实时读取.
    • 支持将hdfs/odps/http数据下载到本地再进行压测.download到本地以gz格式保存,以减少磁盘需求
    • 直接从数据源读取的速度,local速度最快且稳定,hdfs次之,odps/http再次之.
    • 支持读取目录下所有文件和指定文件列表.
    • 目前日志的读取是轮转方式,读完之后从头重新开始,反复循环直至结束.
    • 日志平均分割,每个worker获取其中一段连续的日志,各不相同.
  • query的处理

    • 提供ha3,sap,tpp,json格式的query解析
    • 提供query filter processor,可过滤不需要的日志
    • 提供query append processor,添加需要的参数,比如关闭cache,添加每日token
    • 提供query replace processor,修改已有参数,目前仅支持原文替换,不支持正则匹配替换
    • 提供query urlencode processor,对query进行urlencode
    • 提供query idle processor,支持用户自己进行query处理,直接进入发送状态
  • query的中转

    • 使用queue进行query的中转缓存,如果文件较小,可以自适应的全部cache在queue内,停止reader部分读取,直接从queue内循环发送
  • query的发送

    • 支持cm2,vip,hsf的服务发现
    • 支持http的get,post,以及轮转http header功能.
    • 支持通用pb rpc接口调用
    • 支持通用hsf服务访问,使用hsfcpp支持.默认所有访问带压测标.
    • 支持在1s内均匀的发送请求,而不是在1s开始短时间内脉冲发送完毕. (该方法思想借鉴于abench的实现)

      • 脉冲发送会在1s时间内的前面集中发送请求,不符合实际请求的现状,也容易造成服务端的堆积,监控指标容易形成锯齿状.
  • result的解析

    • 目前result processor仅进行了metric的汇报,未提供结果的解析.但留有接口,可支持xml,json,pb格式的解析.
  • worker性能

    • 常备的容器申请规格是,4core,8g mem, 50g disk.
    • sp性能测试,以评价应用为目标,2wqps,cpu利用率较低,未到瓶颈,最大发送能力可能略大一点.
    • tpp性能测试,未开启全部cache功能,1.9wqps,cpu利用率较高.如果开启全部cache可小幅提高能力.hsf的发送,由于hsfcpp对query的序列化和结果的反序列化比较耗时,所以普遍hsf接口的压测cpu利用率都很高.
    • ha3性能测试,因为query长度比较大,受限于读取性能,当时测试的发送能力在4k.
    • 单个worker的发送上限,主要受限于机型,query大小,超时时间大小.所以一般实际使用中,为保证发送能力,我们都下调worker的发送能力.

产品支持

  • sqi压测平台: 服务大促全链路压测,大促压测更简单,sqi压测平台总结
    sqi
  • tpp每日自动回归压测: 支持tpp智能调度,资源调度更放心
    tpp
  • 容量平台: 评估资源利用率,用户资源增长不害怕.
    capacity
  • tisplus console: 日常手工压测,上线验证不发愁
    console
  • 还能用我们做什么?

    • 模拟异常流量验证降级等系统表现
    • 多条链路混合比例的query请求,以查看不同比例下的性能表现
    • 24h持续不断的最新日志回放,收集输出的算法输出,用以分析算法收益.

未来规划

  • https支持
  • 离线系统的压测支持
  • 应用真实流量曲线的仿真压测
  • 推动周边系统支持高负载时丢弃压测流量,实现全天候压测

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享: