记得最近一次性能测试的问题; 测试一个对外接口，服务A作用解析数据，查询内部一个系统C获取用户信息，再转发另一个服务B，服务B推送到kafka。有拓扑图如下:

问题现象: 对push接口进行性能测试，TPS只能达到20笔/秒,性能比较低

场景：使用100个并发，100秒加载完，运行5秒，查看接口性能情况。

结果如下

TPS

响应时间

并发线程

（1）对比线程数加载情况，发现TPS在10秒后，平稳在20TPS; 并且其中服务A的CPU资源使用不高，并且通过skywalking链路跟踪发现服务A主要耗时调用系统C中的一个接口。

（2）单独对系统C的接口进行测试，发现此接口确实TPS只能达到20并且，系统C的一个服务的CPU使用率非常高，并且发现在系统没有进行系统测试也是比较高。

目前系统C中没有很多监控和定位工具，只能根据现象进行怀疑。怀疑有2点：a.系统目前配置内存为2G,jvm参数配置的1G，是否有因为内存太小引起呢？b.其它系统或者服务其实一直进行大量访问呢？排除怀疑a点，调整内存为4G,并且jvm参数配置为2G;发现系统CPU使用还是比较高;说明不是内存原因。只能是第b个原因，目前其它的系统在访问系统进行处理。目前需确定哪个服务到底是什么原因引起，对系统C的服务增加skywalking的跟踪定位，分析发现确定存在服务在不停的消费kafka进行访问。并且停止此访问服务后，CPU资源马上恢复正常。

暂时解决了系统C中不进行压测试异常高的问题，再进行测试，发现TPS还只有20；只时通过skywalking工具发现链接中耗时比较长，都是数据库getconnection和Close方法。如下图：

怀疑数据库池配置是否有问题，与开发一起检查连接参数。是否设置不合理参数或者连接数不合理呢？检查发现连接参数其中2个值，

spring.datasource.druid.testOnBorrow=true

spring.datasource.druid.testOnReturn=true

修改这2个参数为false后，重新再压测，直接访问系统C的接口，TPS直接达到400左右。并且再次原来接口进行测试结果如下，TPS直接提升20倍。

测试结果

分析：spring.datasource.druid.testOnBorrow和spring.datasource.druid.testOnReturn主要用来验证连接有效和回收连接会执行额外语句验证。建议生产使用时，此2个参数设置为false

druid连接原理解析，建议参考：https://blog.csdn.net/weixin_42132763/article/details/124762940