性能测试：压测中TPS上不去的几种原因分析&案例分析_压测tps上不去

一、常见原因

在进行压测时，如果遇到 TPS（Transactions Per Second，每秒事务处理量）无法达到预期的情况，可能有以下几个常见的原因：

1、服务器资源限制：

服务器的硬件资源（如 CPU、内存、磁盘）可能不足以处理大量的请求。在高负载情况下，服务器可能无法及时响应所有的请求，导致 TPS 上不去。解决方法可以考虑升级硬件资源或通过负载均衡将请求分散到多台服务器上。

2、网络带宽限制：

服务器的网络带宽可能成为瓶颈，在高负载压力下无法支持大量请求的传输。这会导致请求的传输速率受限，从而影响 TPS。此时可以考虑扩大网络带宽或优化网络传输方式，如使用 CDN、压缩数据等。

3、数据库性能问题：

如果应用程序依赖数据库，数据库性能问题也可能导致 TPS 不能达到预期。例如，数据库读写瓶颈、索引不合理、数据库连接池配置不当等都可能影响并发处理能力。可以通过优化 SQL 查询语句、增加数据库缓存、调整连接池大小等手段来提升数据库性能。

4、代码逻辑问题：

应用程序中存在低效、死循环、资源竞争等问题，都可能导致并发处理能力下降。检查代码逻辑是否存在性能瓶颈，优化关键路径，避免不必要的锁竞争和资源浪费。

5、压测配置问题：

压测工具的配置可能影响 TPS 的表现。例如，并发数设置过低、请求时间间隔不合理、持续时间过短等都可能导致 TPS 表现不稳定。确保压测配置合理，并根据实际情况进行调整。

6、第三方服务延迟：

如果应用程序依赖外部的第三方服务（如支付接口、消息队列、数据库等），这些服务的延迟或故障也可能导致 TPS 降低。可以通过监控和日志分析来确定是否存在第三方服务问题，并与服务提供商联系解决。

在分析 TPS 上不去的原因时，可以使用系统监控工具、日志分析、性能剖析工具等来收集相关数据，并结合压测结果进行综合分析。根据具体情况采取相应的优化措施，优化关键路径、增加资源、调整配置等都有助于提升 TPS 的性能。

二、案例讲解

2.1 压测配置/压测脚本问题

2.1.1 背景：

在一个登录的压测场景，登录接口，需要对登录密码在本地进行加密，同时在header里生成验签。

处理这一系列的逻辑，是一个js脚本。

在压测时发现：
在压测的时候，查看jmeter聚合报告，发现rt很小，但是tps也很小。

讲道理来说，响应时间越小，tps应该越大。

一共压测10分钟，发现jmeter请求的样本数量非常小，才8500个请求。

10分钟内，才打出了8500个请求。

tps= 总样本数量/总时间。

时间是固定的600s，总样本数量小，导致tps很小。

为什么10分钟才打出了8500个请求。

2.1.2 原因：

发现有一个前置处理器，处理验签的。

这个前置处理器这么复杂吗？这么消耗性能吗？

这个前置处理器，做验签处理，做加密都是用的js脚本。

我将前置处理器，换成了java语言。做了一个实现。

2分钟内，100并发，js脚本，打出了 8306 个请求。

2分钟内，100并发，java脚本，打出307,336 个请求。

结果相差了37倍。

2.1.3 解决办法：

将js脚本，换成了java脚本。

2.2 其他案例

并发连接数过高：在某个压测场景中，你可能设置了非常高的并发连接数，但服务器的最大并发连接数限制低于此数量。因此，当压测开始时，服务器无法处理所有的连接请求，导致 TPS 达不到预期。解决方法可以是增加服务器的最大并发连接数限制或者调整压测配置中的并发连接数。

数据库查询效率低下：在某个压测场景中，你的应用程序执行了大量的数据库查询操作。然而，这些查询语句未经过优化，导致数据库响应时间过长。由于每次请求都需要等待数据库响应才能继续处理，TPS 会受到影响。解决方法可以是通过索引优化、查询重构或者使用数据库缓存来提高数据库查询效率。

网络延迟和带宽限制：在某个压测场景中，你的应用程序需要从远程服务获取大量数据。由于网络延迟较高或带宽受限，数据传输速度变慢，导致应用程序的处理能力下降，从而影响 TPS。解决方法可以是优化网络传输方式、使用更高带宽的网络连接或者缓存远程数据。

过度频繁的日志记录：在某个压测场景中，你的应用程序进行了大量的日志记录操作，每次记录都需要进行文件 I/O 操作，导致磁盘负载过高。随着并发增加，磁盘性能无法跟上，进而影响应用程序的处理能力和 TPS。解决方法可以是减少不必要的日志记录、通过异步日志写入或者将日志记录到内存缓冲区等方式来降低对磁盘的负载。