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