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 开始设计架构，您说的有道理，文中所说的所有底层技术均是公司成熟的基建，无需重新搭建

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

暂无开源计划

图片有的，您刷新下看看？

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

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

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

没有