信创软件性能优化测试三步法

有关信创软件性能优化测试究竟是要去测试些什么内容、又该如何进行测试呢其得出的结论十分直白地讲就是应当首先去定位硬件与基础软件之间适配时所存在的瓶颈之处接着针对中间件以及数据库展开调优工作最终将重点落实到应用代码的并发处理以及资源管理方面。这三者是按照逐层推进的方式来进行的其中任何一个环节都不能够缺失。为何非要依照这个顺序呢是由于信创环境跟成熟的x86加上Windows生态不一样国产CPU像是龙芯,飞腾的指令集以及内存控制器特性差别大操作系统像麒麟,UOS的调度策略与I/O栈也有自身的实现要是在硬件层还没稳固就直接优化代码极有可能反复做无意义的事。1. 针对硬件与操作系统予以适配性的测试应当优先去对比具备相同规格的信创机器以及主流非信创机器的基准性能着重关注CPU主频敏感型的计算、内存带宽、磁盘随机读写延迟这三项指标存在一个常见的误区是仅仅只跑总吞吐量却忽略了响应时间所产生的波动比如某一个政务应用在转移之后总TPS下降的情况并不显著然而95分位延迟却从50ms飙升到300ms最终经过定位是国产OS的默认中断亲和性配置并不合理在整改之后延迟回落至80ms。2. 中间件跟数据库的连接池以及事务日志。在信创环境当中Tomcat或者东方通的线程池参数可别像原来那样照搬数值。这是由于国产数据库像是达梦、人大金仓的锁机制与MVCC实现存在差异得通过实测来调整最小空闲连接数以及超时回收时间。与此同时呐数据库的redo日志缓冲区大小跟刷盘策略对写入型业务影响是极大的。有个实际的案例某金融系统把日志缓冲区从8MB扩充到64MB还启用了异步提交导致写入性能提高了三倍。3. 应用代码存在资源竞争以及锁粒度的情况在经历前两层优化之后压力测试常常会暴露出代码层的阻塞点要优先排查同步块范围排查第三方序列化序列化化序列化库的使用方式排查大对象频繁创建致使的GC压力对于多线程密集场景而言把重量级锁替换成读写锁或者使用原子变量通常能够有显著改善另外要留意信创JDK的某些实现情况比如毕昇JDK其对虚线程的支持还不完善建议先使用传统线程池进行压测验证。全面考量之下信创软件的性能优化测试得从底层朝着上层逐次进行验证每一回把一个层级的问题给处理好了之后都得倒退到全链路开展压测。你当下碰到的最为棘手的性能瓶颈是处于CPU/OS层、数据库层还是代码层呢欢迎在评论区写下你的实战场景一块儿探讨更为具体的调优方案。要是这篇文章对你有所启发不妨点赞并且分享给同样正进行信创迁移的同事。