打酱油

还未发布过话题
  • mitmproxy grpc 代理抓包 at 2020年10月09日

    赞~~
    grpc 感觉越来越火~

  • 优秀的文章~
    这几年身边的项目都由朝着这个方向改造的趋势,不管是对 APP 生态对影响还是基于后台服务化对接 mqtt
    核心思想都是基于长连接的状态下实现业务多样化的动态支持扩展,带来效率的提升

  • 前段时间有点忙,今天才看到回复
    1、可以分享一下你的 case 转化为性能脚本吗,提供一下核心思路和做法
    -- 后续可以撸个文章,个人觉的这个问题最本质的是快速实现压测接口,然后接口组合压测场景,想要从 1 人/天 10 接口提升到 100 个,确实需要改造,还有第二点,是接口模版的改动,可以最小代价落地

    2、你目前的做法在能 web 端能统计到相关的请求数据吗
    -- locust 虽然提供了图表,但是只是一个辅助手段,压测数据都是要以服务环境数据指标做第一优先;而且分布式 slave 多,数据会有几秒的滞后,但是不影响整体的准确性,现在监控体系都非常成熟了,从普罗米修斯到 elk+grf 日志分析 各个组件的监控,各种云上面都有自建都指标,如果是自建的,本身就有监控数据视图,locust 本身最重要的功能还是提供一个压测能力,相比 jmt 分布式部署会很便捷,而且对扩展协议压测支持很便捷,最是最大的优点

    第 1 个问题,只有相对解最优解;而且在实际压测过程中,需要控制分布式参数唯一性的问题,自动化 case 过来的数据,需要做一轮抽象,然后组合初始化压测数据满足动态大并发要求。

  • 深入浅出 Locust 实现 at 2020年09月29日

    棒~

  • locust 本身对协议扩展支持是非常灵活和便捷的
    看下来,只是为了怎么更优雅的整合 api 接口压测场景封装和调用。最好是复用接口平台里面的 case。
    核心思路,不在于 request
    用 locust 也有一段时间,从之前一天 5~6 个接口支持,现在经过改装一天可以撸个 50+ 接口也很快,也可以很灵活的对接从自动化平台过来的场景 case

  • 接口的设计 对应是业务实现的抽象
    接口的测试的核心;是检查业务变更点是否全面生效以及业务相关影响点检查
    接口的返回,特别是 msg 描述 不是接口测试的核心内容
    想法很好~用在搜索算法匹配上面测试很好

  • 优秀~~
    用真实的业务参数 + 决策算法组合生成了检查数据权限场景
    不知道用户角色多 token 的匹配怎么落地的

  • 支持 http2.0 或则 响应式返回接口不~

打酱油