TPS、QPS 和 RPS 的定义与区别

在系统性能测试和评估中，TPS、QPS 和 RPS 是常用的指标，用于衡量系统的吞吐量和处理能力。它们分别表示不同层面的请求处理能力，以下是详细介绍：

---

1. TPS（Transactions Per Second）

定义

• TPS 表示系统每秒能够处理的事务数（Transactions Per Second）。

• 一个事务（Transaction）通常是一个完整的业务操作，可能由多个请求组成。例如：

  • 用户登录（包括用户名验证、密码校验、生成会话等）。
  • 提交订单（包括库存检查、支付处理、订单生成等）。

特点

• 事务的粒度较大：

  • 一个事务可能包含多个 HTTP 请求或数据库操作。

• 业务相关：

  • TPS 通常与具体的业务逻辑绑定，不同的业务事务可能有不同的复杂度。

计算公式

TPS = 总事务数 / 测试时间（秒）

示例

• 如果在 10 秒内完成了 500 个订单事务，则 TPS 为：

TPS = 500 / 10 = 50

2. QPS（Queries Per Second）

定义

• QPS 表示系统每秒能够处理的查询数（Queries Per Second）。
• 查询（Query）通常是指对系统的一个请求，可能是 HTTP 请求、RPC 调用或数据库查询。

特点

• 粒度较小：

  • QPS 通常用于衡量系统的请求处理能力。

• 与请求直接相关：

  • 每个请求对应一个 QPS 计数。

计算公式

QPS = 总请求数 / 测试时间（秒）

示例

• 如果在 10 秒内处理了 1000 个 HTTP 请求，则 QPS 为：

QPS = 1000 / 10 = 100

3. RPS（Requests Per Second）

定义

• RPS 表示系统每秒能够处理的请求数（Requests Per Second）。
• RPS 和 QPS 的概念非常相似，通常可以互换使用，但在某些场景下，RPS 更强调HTTP 请求或API 调用的数量。

特点

• 与 QPS 的区别：

  • RPS 更常用于描述 Web 系统的 HTTP 请求处理能力。
  • QPS 更常用于描述数据库查询或搜索引擎的查询能力。

计算公式

RPS = 总请求数 / 测试时间（秒）

示例

• 如果在 10 秒内处理了 2000 个 HTTP 请求，则 RPS 为：

RPS = 2000 / 10 = 200

TPS、QPS 和 RPS 的关系

1. TPS 和 QPS/RPS 的关系：

   • 一个事务（TPS）可能包含多个请求（QPS/RPS）。

   • 例如，一个订单事务可能包含以下请求：

     • 查询商品库存（1 个请求）。
     • 提交订单（1 个请求）。
     • 支付接口调用（1 个请求）。

   • 如果一个事务包含 3 个请求，那么：

QPS = TPS × 每个事务的请求数

2. QPS 和 RPS 的关系：

   • 在大多数场景下，QPS 和 RPS 是等价的，表示系统每秒处理的请求数。

---

如何反映系统性能

1. 吞吐量

• TPS、QPS 和 RPS 都是衡量系统吞吐量的重要指标。
• 吞吐量越高，说明系统能够处理的事务或请求越多，性能越好。

2. 系统瓶颈

• 如果 TPS 或 QPS 达到一定值后无法继续提升，说明系统可能存在瓶颈：

  • CPU 瓶颈：CPU 使用率接近 100%。
  • 内存瓶颈：内存不足，导致频繁的 GC 或内存溢出。
  • 网络瓶颈：网络带宽不足，导致请求延迟增加。
  • 数据库瓶颈：数据库查询速度慢或连接池耗尽。

3. 系统稳定性

• 在高 TPS/QPS/RPS 下，系统是否能够保持稳定运行是衡量系统性能的重要指标。
• 如果系统在高负载下出现错误（如超时、连接失败），说明系统需要优化。

---

如何测试 TPS、QPS 和 RPS

1. 测试工具

• 压力测试工具：

  • Apache JMeter
  • Locust
  • Gatling
  • ab（Apache Benchmark）
  • wrk

• 监控工具：

  • Prometheus + Grafana
  • ELK（Elasticsearch + Logstash + Kibana）

2. 测试方法

• TPS 测试：

  • 模拟完整的业务流程（如下单、支付等），统计每秒完成的事务数。

• QPS/RPS 测试：

  • 模拟大量并发请求，统计每秒处理的请求数。

3. 测试环境

• 测试环境应尽量接近生产环境，包括硬件配置、网络环境等。

---

优化系统性能的方法

1. 提升 TPS

• 优化业务逻辑，减少事务的复杂度。
• 使用分布式事务或异步处理，减少事务的锁定时间。

2. 提升 QPS/RPS

• 应用层优化：

  • 使用缓存（如 Redis、Memcached）减少数据库查询。
  • 优化代码逻辑，减少不必要的计算。

• 数据库优化：

  • 添加索引，优化查询语句。
  • 使用读写分离或分库分表。

• 网络优化：

  • 使用 CDN 缓存静态资源。
  • 减少 HTTP 请求的大小（如启用 GZIP 压缩）。

3. 提升并发能力

• 增加线程池大小，提升并发处理能力。
• 使用异步编程模型（如 CompletableFuture、Reactive Programming）。
• 扩展系统架构（如负载均衡、微服务拆分）。

---

总结

指标	定义	特点	适用场景
TPS	每秒完成的事务数	粒度较大，通常包含多个请求	业务逻辑的整体性能评估
QPS	每秒处理的查询数	粒度较小，通常与请求直接相关	数据库查询、搜索引擎性能评估
RPS	每秒处理的请求数	与 QPS 类似，通常用于 HTTP 请求或 API 调用	Web 系统或 API 性能评估

• TPS、QPS 和 RPS 是衡量系统吞吐量的重要指标，能够反映系统的性能和瓶颈。
• 在实际测试中，应根据业务场景选择合适的指标，并结合其他性能指标（如响应时间、并发数）进行综合评估。

TPS 是怎么统计的

TPS（Transactions Per Second）  通常不能直接通过压测工具（如 k6、JMeter 等）获取到，因为压测工具主要统计的是请求级别的指标（如 QPS/RPS），而 TPS 是一个业务级别的指标，需要结合具体的业务逻辑来统计。

---

为什么 TPS 不能直接通过压测工具获取？

1. TPS 是业务相关的指标：

   • TPS 表示系统每秒完成的事务数，而事务通常是一个完整的业务操作，可能由多个请求组成。
   • 压测工具通常统计的是请求级别的指标（如每秒的 HTTP 请求数，即 QPS/RPS），而不会直接理解或统计业务事务的完成情况。

2. 事务的定义因业务而异：

   • 不同的业务场景对事务的定义不同。例如：

     • 在电商系统中，一个事务可能是“下单”操作，包括多个请求（如查询库存、提交订单、支付等）。
     • 在银行系统中，一个事务可能是“转账”操作，包括账户验证、扣款、入账等多个步骤。

   • 压测工具无法直接知道这些业务逻辑，因此无法直接统计 TPS。

---

TPS 是如何统计的？

要统计 TPS，需要结合业务逻辑，通过以下方式进行统计：

1. 在代码中统计事务完成数

• 在业务代码中，记录每个事务的开始和结束时间，并统计单位时间内完成的事务数。

示例：统计 TPS

import java.util.concurrent.atomic.AtomicInteger;

public class TPSTracker {
    private static final AtomicInteger transactionCount = new AtomicInteger(0);

    public static void main(String[] args) throws InterruptedException {
        // 模拟事务完成
        for (int i = 0; i < 100; i++) {
            new Thread(() -> {
                performTransaction();
            }).start();
        }

        // 每秒打印 TPS
        while (true) {
            Thread.sleep(1000);
            System.out.println("TPS: " + transactionCount.getAndSet(0));
        }
    }

    private static void performTransaction() {
        // 模拟事务处理
        try {
            Thread.sleep(100); // 模拟事务耗时
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        transactionCount.incrementAndGet(); // 记录事务完成
    }
}

输出：

TPS: 50
TPS: 48
TPS: 52

2. 使用日志分析

• 在业务代码中记录事务的完成时间，通过日志分析工具统计每秒完成的事务数。

示例：日志格式

2025-05-09 12:00:01 INFO Transaction completed: OrderID=12345
2025-05-09 12:00:01 INFO Transaction completed: OrderID=12346
2025-05-09 12:00:02 INFO Transaction completed: OrderID=12347

统计方法：

• 使用日志分析工具（如 ELK、Splunk）统计每秒的事务完成数。

3. 使用数据库统计

• 如果事务的完成状态会记录到数据库中，可以通过查询数据库统计 TPS。

示例：SQL 查询

SELECT COUNT(*) / 60 AS TPS
FROM transactions
WHERE completed_at >= NOW() - INTERVAL 1 MINUTE;

4. 使用压测工具结合业务逻辑

• 在压测脚本中模拟完整的事务流程，并统计事务的完成数。

示例：k6 脚本

import http from 'k6/http';
import { check } from 'k6';

export const options = {
    vus: 10, // 并发用户数
    duration: '30s', // 压测持续时间
};

let transactionCount = 0;

export default function () {
    // 模拟事务的多个步骤
    let step1 = http.get('https://example.com/step1');
    check(step1, { 'step1 success': (r) => r.status === 200 });

    let step2 = http.get('https://example.com/step2');
    check(step2, { 'step2 success': (r) => r.status === 200 });

    let step3 = http.get('https://example.com/step3');
    check(step3, { 'step3 success': (r) => r.status === 200 });

    // 如果所有步骤成功，记录事务完成
    if (step1.status === 200 && step2.status === 200 && step3.status === 200) {
        transactionCount++;
    }
}

// 在压测完成后打印事务总数
export function teardown() {
    console.log(`Total Transactions: ${transactionCount}`);
}

TPS 与 QPS/RPS 的关系

1. 事务与请求的关系：

   • 一个事务可能包含多个请求。例如：

     • 一个订单事务可能包含 3 个请求：

       1. 查询库存。
       2. 提交订单。
       3. 支付接口调用。

   • 如果 TPS 为 50，每个事务包含 3 个请求，则 QPS 为：

QPS = TPS × 每个事务的请求数 = 50 × 3 = 150

1. QPS/RPS 是 TPS 的基础：

   • QPS/RPS 是系统处理请求的能力，而 TPS 是系统完成业务事务的能力。
   • 如果系统的 QPS 很高，但 TPS 很低，可能说明事务的复杂度较高，或者系统存在性能瓶颈。

---

总结

• TPS 是业务级别的指标，表示系统每秒完成的事务数，不能直接通过压测工具获取。

• 统计 TPS 的方法：

  1. 在代码中记录事务完成数。
  2. 使用日志分析工具统计事务完成时间。
  3. 通过数据库查询统计事务完成数。
  4. 在压测脚本中模拟完整的事务流程并统计完成数。

• TPS 与 QPS/RPS 的关系：

  • TPS 是事务级别的吞吐量，QPS/RPS 是请求级别的吞吐量。
  • 一个事务可能包含多个请求，因此 QPS 通常大于 TPS。