主要内容
- ui 框架（playwright）添加新的步骤和断言
- 发布佛山集群和新加坡 aws 集群的性能对比结果
ui 部分
上个季度忙于做全链路压测，本来是打算 Q2 本人介入新 ui 改造的，奈何时间上冲突。然后新的 ui 的进度又得保证，所以其他人接手做了第一版。在添加新的需求的时候，代码的实现逻辑整体而言倒是容易理解，添加新的步骤或者断言的话，只需要在添加新的枚举类型以及对应的步骤实现类即可，这种设计对于当事人和其他接手的同学也比较友好，称赞一下。
另外有几个比较重要的地方：
- ui 断言类型需要支持正则匹配，所以需要 Java 语言的正则来匹配源字符串是否属于 JS 正则表达式
- 旧的替换字符串的逻辑中，如果没有变量，则会在字符串最前和最后添加 ` 以确保在 JS 语言环境中是一个字符串。但我个人添加的需求中，如果是正则就不需要加 ` , 是正则则需要加；
数据对比
项目样本
在现有的条件下，仅能选取 Java 项目，并且由于需要单独在新加坡集群下步骤一套独立的应用，成本偏高。成本包括：梳理依赖（下游需要 mock），跟现有预发环境的配置隔离（nacos/mysql/redis 等等）。所以项目的样本仅一个。
接口样本
为了数据更有说服力，对 IO 密集型 和 CPU 密集型的接口都有做压测对比，并且不同资源条件的结果也有对比。比方说：1核4G 以及 2核8G 都有测试到。除此之外，其他所有的硬件，软件配置都保持一致。
结果说明
- 通常都是将资源压到 100% 之后在做对比，并且压测前半段周期内的资源占用其实是不满的，这也是造成结果的波动的可能原因；
- 不同线程数配置下， CPU 可能最终都会能到 100，但是聚合报告中的吞吐量其实是不一样的，这个比较好理解：如果 4 个线程数可以到 100，增加线程数会造成更多的线程池阻塞，有更多的请求排队，导致请求的耗时变长，从而吞吐量降低；
- 对于 2 而言，最好的做法应该是多压测几次，不同集群都取最优解然后再做对比
- 压测的结果比理想中的值要低很多，从CPU对比网站上查询了两个对比集群下的 CPU 分数，相差好几倍。但是实际结果中，好的比差的仅多了 20% ~ 50%