• 也不是很清楚,修改一下

  • 您好,转载请注明文章来源和作者

  • 可以,请注明作者(团队)、来源等

  • 1 问题:系统层面的 cpu、内存大小、网络带宽,主要是硬件的资源不用太关注了,主要指的是被压机器的 cpu 的配置调优、内存的调优、带宽的速度这些都已经是配置好了。
    在压测的时候,需要看下被压机器的 cpu、内存、IO 指标,如文章写了,压测时被压 cpu 是 10%,被压机器的 cpu 是正常的,同时也要监控 tps、tp99 等指标,这场景是 tps 不满足预期、tp99 偏高、cpu 正常。
    2 问题:并不是直接来看 jvm 的,对于这场景是 tps 不满足预期、tp99 偏高、cpu 正常。对于这个现象首先排查可能会存在一些阻塞了,被压机器处理的流量不是预期的流量导致现象 tps 不高,cpu 也不高,从头开始排查首先网络带宽方面不是瓶颈,然后猜想是否打个线程 dump 文件排查哪里阻塞。
    同时也排查这个接口的调用链路,调用了哪些服务,排查下游服务是否存在瓶颈,如文章所下排查到下游的领券接口(这个服务部署在另外的机器上)超时,并且 cpu 偏高,继而转到这个下游接口的场景 tp99 偏高,cpu 偏高的排查,可能会存在哪些原因。对于这个场景可能原因也会有很多,
    对于这个接口超时首先想到了这个接口调了过滤器,猜测是不是这个原因,其实也可以看这个服务的日志。但是最后验证不是这个原因,又查看了 jvm 的日志,然后发现了根源。

  • 这里要分两种情况:
    1、这个如果是别人给你的静态库是不支持,因为代码覆盖率是基于源码基础上,利用编译器在代码的 BB(basic block)基础上插桩实现的,别人给的静态库一般不会插桩,你也没有对应的源码,无法做到代码覆盖率统计;
    2、如果是自己通过源码生成的静态库是支持的,实现方式就是源码生成静态库的时候,就进行插桩实现。然后结合源码支持代码覆盖率了。

  • 您好,方便留一个联系方式或者加一下我(微信 puyapeng)吗~

  • 利用 binlog 触发或者主动更新缓存保证最终一致性就好,缓存刷新时机需要根据实际业务来选择

  • 不好意思历史背景没有说全,公司的业务应监管要求无法再引入新闻类内容,导致内容量骤降,公司业务转型恰好结合原有基建能力,快速上线一个新业务,所以优惠内容就以文章为载体出现了。如果从 0 开始设计架构,您说的有道理,文中所说的所有底层技术均是公司成熟的基建,无需重新搭建

  • 代码影响范围工具探索 at 2023年01月19日

    这个工具是辅助性的工具,是协助测试及代码 review 工作

  • 代码影响范围工具探索 at 2023年01月19日

    暂无开源计划

  • 精准测试之覆盖 at 2023年01月12日

    图片有的,您刷新下看看?

  • 精准测试之覆盖 at 2023年01月11日

    1、如何获取后端接口和前端功能的对应关系:
    手工思路,前、后端都需要人工记录,然后梳理对应关系,如:前端触发某控件,控件会调用某个(前端)路由文件,然后通过前端的路由地址调到后端 control 层,再逐一往后跟踪,一般可以 debug 操作,这些过程都需要记录,然后一条一条总结出对应关系;
    工具思路,前端需要建立控件(组件)、路由文件、路由地址的关系表,这样触发哪个控件可以被记录下来,后端可以通过 hook 掉 http(servlet),就能得接口地址了,最后前、后端要有一个对应关系表作为记录。要让控件与接口对应起来,一般是通过唯一线程之类的。

    2、产品开发前期没有这方面积累的情况下,想通过前端代码去做分析扒出接口和前端控件对应关系:
    控件与功能不是太明白,功能的链路可以理解是业务方面的么?要这样的话,所有相关的应用服务都需要,调用链路要了解,每经过一个链路节点就要记录下来,可以了解下 APM。

    看回复是否对你有帮助,哪里有问题可以再聊

  • 没有😩

  • 京东云也是有新人优惠滴,11.11 云主机 2C4G3M,0.8 折 1 年 178;轻量云主机 2C2G4M,1 年 50
    2C4G 到 8C16G,10M 以内不同型号云主机价格 3 年 3 折-3.5 折不等哈

  • 京东云也是有新人优惠滴,11.11 云主机 2C4G3M,0.8 折 1 年 178;轻量云主机 2C2G4M,1 年 50
    2C4G 到 8C16G,10M 以内不同型号云主机价格 3 年 3 折-3.5 折不等哈