性能测试的TPS（每秒事务数）是最直观的标准。在JMeter中压测时发现TPS始终上不去甚至远低于预期目的，你会从哪里入手？很多人第一反应是脚本有问题，或者JMeter本身配置不够。但实际上，短板往往不在工具本身，而在被测系统的底层。湖南卓码软件测评有限公司（有CMA和CNAS双资质，可出具全国通用的软件测试报告）的工程师在实践中总结了一套排查思路，按网络、服务器、数据库三个方面逐层深入，能快速定位问题根源。

第一层网络：看不见的管道拥堵

TPS上不去，先得确定数据能不能顺畅地从客户端流到服务器。网络问题虽然隐蔽，但一旦存在，就会成为压测的天花板。可以在压测的同时，用ping命令观察网络延迟和丢包率。如果延迟超过几十毫秒，或者有丢包现象，TPS自然会受限。更精确的方法是使用 iperf 等工具测试网络带宽，看看是不是达到了物理链路的极限。有时候，问题出在防火墙或负载均衡器上，可能会对并发连接数做限制，导致请求被丢弃。在排除网络问题之前，盲目优化应用是没有意义的。

第二层服务器：CPU、内存、磁盘

如果网络通畅，下一步就要看服务器的资源消耗了。压测期间，登录服务器执行 top 或 htop 命令，观察CPU使用率。如果CPU已经接近100%，并且大部分消耗在用户态，说明应用代码在拼命计算，需要优化算法或增加机器；如果CPU消耗在系统态，可能是系统调用频繁，比如文件I/O或网络I/O过多。内存方面，用 free -m 检查物理内存和Swap的使用情况。如果Swap占用很高，说明物理内存不足，系统开始使用磁盘交换，性能会急剧下降。磁盘I/O也是容易被忽略的短板，用iostat -x 1可以监控磁盘的读写等待时间。如果 await 或 %util 居高不下，说明磁盘太慢，可以考虑更换SSD或调整数据库的缓存方法。

第三层数据库:锁、慢查询和连接池

当应用服务器看起来游刃有余，TPS依然上不去时，矛头就要指向数据库。数据库往往是整个系统的最后一道防线，也是最容易出问题的步骤。压测期间，开启数据库的慢查询日志，观察是不是有大量慢SQL出现。一个查询执行几秒钟，TPS必然被拉低。第二，检查数据库的连接数是不是达到上限。如果应用连接池配置过小，请求会在连接池排队等待，导致TPS上不去。你可以登录数据库，用 show processlist 查看当前连接状态，看是不是有大量连接处于“Sleep”或“Locked”状态。另外，数据库的锁竞争也是常见原因，特别是InnoDB的行锁或表锁。如果压测脚本涉及大量写操作，并且表结构设计不当，锁等待时间会急剧增加。你可以用 show engine innodb status 查看锁信息，定位冲突严重的SQL。

TPS上不去，很少是单一原因造成的，往往是网络、服务器、数据库三方面相互影响的结果。湖南卓码软件测评有限公司建议你按照从外到内、从硬件到软件的思路逐一排查：先保证网络通畅，再分析服务器资源，深入数据库内部。当掌握了这套排查方法，就能在性能测试中快速定位短板，而不是盲目调整JMeter的线程数。如果问题实在复杂，也可以委托有CMA和CNAS资质的专业机构进行检测，他们出具的软件测试报告书可在国家市场监督管理局官网查询，权威可靠。