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

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

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

  • 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日

    暂无开源计划