6.3 性能基准测试

6.3 性能基准测试

性能基准测试（Benchmark）是评估和优化 Qdrant 性能的核心手段。无论是选型阶段的技术评估，还是上线后的性能调优，都需要一套科学的测试方法论来获得可靠的数据支撑。本章将从测试方法、指标定义、测试工具到优化策略，全面讲解 Qdrant 的性能基准测试实践。

为什么要做基准测试

在向量数据库领域，性能指标直接决定了用户体验和系统成本。一个毫秒级的延迟差距，在高 QPS 场景下可能意味着完全不同的用户体验。基准测试能回答以下关键问题：

• 在我的数据规模下，Qdrant 能提供多快的搜索响应？
• 在目标 QPS 下，系统资源够不够用？
• 不同配置参数对性能的影响有多大？
• 与其他向量数据库相比，Qdrant 的优势在哪里？

测试方法论

控制变量法

性能测试的核心原则是控制变量，每次只改变一个参数，观察其对性能的影响。Qdrant 的性能影响因素众多，包括：

• 数据规模（向量数量、维度、Payload 大小）
• 索引参数（HNSW 的 ef_construct、M 值、搜索 ef）
• 硬件配置（CPU 核数、内存大小、存储类型）
• 查询模式（单向量搜索、批量搜索、过滤搜索）
• 并发度（客户端连接数、并发请求数）

科学的做法是：先确定一个基准配置，记录基准性能数据，然后逐一调整参数，对比差异。

测试环境标准化

为了保证测试结果的可复现性，测试环境需要标准化：

1. 使用固定的硬件配置（避免云实例的性能波动）
2. 关闭不必要的后台进程
3. 多次运行取平均值（至少 3 次）
4. 排除首次运行的冷启动效应
5. 记录完整的系统环境信息（OS、CPU、内存、磁盘型号）

数据集选择

选择合适的测试数据集至关重要。常用的公开数据集包括：

• SIFT1M（128维，100万向量）：经典的图像特征数据集，适合基础性能测试
• GIST1M（960维，100万向量）：高维数据集，测试高维度场景
• 自建数据集：最贴近实际业务的数据，建议使用生产环境的真实数据子集

核心性能指标

延迟（Latency）

延迟是用户感知最直接的指标，表示从发送请求到收到响应的时间。

关键百分位数

• P50（中位数）：50% 请求的响应时间，反映典型体验
• P95：95% 请求的响应时间，反映大多数用户体验
• P99：99% 请求的响应时间，反映尾部延迟
• P999：99.9% 请求的响应时间，反映极端情况

在向量搜索场景中，P99 延迟是最关键的指标。因为用户通常只记得最差的体验。

测量方式

使用 Python 进行延迟测试时，推荐使用 perf_counter 获取高精度时间戳：

import time
import statistics

latencies = []
for _ in range(10000):
    start = time.perf_counter()
    client.search(
        collection_name="test",
        query_vector=query_vector,
        limit=10
    )
    elapsed = time.perf_counter() - start
    latencies.append(elapsed * 1000)  # 转为毫秒

latencies.sort()
print(f"P50: {statistics.median(latencies):.2f}ms")
print(f"P95: {latencies[int(len(latencies) * 0.95)]:.2f}ms")
print(f"P99: {latencies[int(len(latencies) * 0.99)]:.2f}ms")
​

吞吐量（Throughput）

吞吐量表示系统在单位时间内能够处理的请求数量，通常用 QPS（Queries Per Second）衡量。

单线程 QPS

start = time.perf_counter()
for _ in range(1000):
    client.search(collection_name="test", query_vector=qv, limit=10)
elapsed = time.perf_counter() - start
print(f"单线程 QPS: {1000 / elapsed:.1f}")
​

并发 QPS

使用多线程模拟并发请求：

import concurrent.futures

def measure_throughput(concurrency, duration_seconds=30):
    start_time = time.time()
    completed = [0]

    def worker():
        while time.time() - start_time < duration_seconds:
            client.search(collection_name="test", query_vector=qv, limit=10)
            completed[0] += 1

    with concurrent.futures.ThreadPoolExecutor(max_workers=concurrency) as executor:
        futures = [executor.submit(worker) for _ in range(concurrency)]
        concurrent.futures.wait(futures)

    elapsed = time.time() - start_time
    return completed[0] / elapsed

for c in [1, 4, 8, 16, 32, 64]:
    qps = measure_throughput(c)
    print(f"并发数: {c}, QPS: {qps:.1f}")
​

精度（Recall）

精度表示搜索结果的质量，即返回的结果中有多少比例属于真正的 Top-K 最近邻。

对于每个查询向量，先通过暴力搜索（Brute Force）获得精确的 Top-K 结果作为基准，再与 HNSW 搜索结果对比，计算召回率。在实际应用中，召回率和延迟之间存在权衡：增大搜索 ef 值可以提高召回率，但会增加延迟。

资源使用率

性能测试还需要关注资源消耗：

• CPU 使用率（用户态、系统态）
• 内存占用（常驻内存、堆内存）
• 磁盘 I/O（读写速率、IOPS）
• 网络带宽

HNSW 参数调优

HNSW 是 Qdrant 默认的向量索引算法，其参数对性能影响巨大。

M 值（连接数）

M 值控制每个节点在 HNSW 图中的最大连接数。

• M 越大，图越密集，召回率越高，但内存占用和构建时间也越大
• 默认 M=16 是一个平衡选择
• 对于高精度需求，可设为 32 或 64
• 对于内存受限场景，可设为 8

内存影响：每个向量额外占用的内存约为 M x 4 字节（float32）的指针。

ef_construct（构建参数）

ef_construct 控制索引构建时的搜索范围。

• 值越大，构建的索引质量越高，召回率越好
• 但构建时间显著增加
• 默认值为 100
• 对于离线索引构建，建议设为 200-500

ef（搜索参数）

ef 控制搜索时的遍历范围，可以在每次查询时动态设置。

• ef 越大，搜索越精确（召回率越高），延迟越高
• ef 必须大于等于 limit（返回结果数）
• 推荐 ef = limit x 2 到 limit x 10

延迟与召回率的权衡：

ef = limit       → 最低延迟，可能牺牲召回率
ef = limit * 5   → 平衡点，大多数场景的推荐值
ef = limit * 10  → 高召回率，延迟略有增加
ef = limit * 50  → 接近暴力搜索的精度
​

Qdrant 官方基准测试参考

Qdrant 团队定期发布官方基准测试结果，基于标准化的测试环境和数据集。以下是一些参考数据（实际性能取决于硬件配置和数据特征）：

单节点 100万 768维向量

• 搜索延迟 P95：约 2-5ms（ef=128）
• 单线程 QPS：约 5000-8000
• 内存占用：约 3-4GB（含 HNSW 索引）

单节点 1000万 768维向量

• 搜索延迟 P95：约 5-15ms（ef=128）
• 单线程 QPS：约 2000-4000
• 内存占用：约 30-40GB

批量搜索性能

批量搜索（batch search）可以显著提升吞吐量，因为减少了网络往返开销和内部处理开销。批量大小建议在 32-128 之间。

常见性能问题排查

搜索延迟突然升高

可能原因和排查步骤：

1. 检查是否有大批量写入正在进行（写入会影响索引更新，影响搜索性能）
2. 检查内存是否不足（内存不足会导致频繁的磁盘交换）
3. 检查是否有其他进程占用 CPU 或 I/O
4. 检查 ef 参数是否被异常调大

写入吞吐量不足

可能原因和排查步骤：

1. 检查是否使用了批量写入（单条写入效率远低于批量）
2. 检查磁盘 I/O 是否是瓶颈（使用 SSD vs HDD 差异巨大）
3. 检查 Qdrant 的 WAL（预写日志）配置
4. 考虑关闭写入时的同步等待（async write）

内存持续增长

Qdrant 的 HNSW 索引需要将大量数据加载到内存。如果内存持续增长，检查：

1. 向量数量是否超出预期
2. 是否有大量重复写入导致内存碎片
3. Payload 索引是否占用了过多内存
4. 考虑启用量化（Scalar Quantization 或 Product Quantization）减少内存占用

对比测试框架

如果需要对比 Qdrant 与其他向量数据库的性能，建议使用标准化的测试框架：

1. ANN Benchmarks：学术界广泛使用的向量搜索基准测试框架
2. VectorDB Benchmarks：专门针对向量数据库的对比测试工具
3. 自建框架：根据业务场景定制的测试脚本

对比测试的关键是确保公平性：使用相同的数据集、相同的硬件、相同的查询模式。避免用不同的参数配置来"优化"某一个产品的结果。

总结

性能基准测试是 Qdrant 优化和选型的核心手段。通过科学的测试方法论、标准化的测试环境、全面的指标监控，可以获得可靠且可复现的性能数据。重点关注 P99 延迟、并发 QPS 和召回率之间的权衡，合理调整 HNSW 参数，在精度和性能之间找到最佳平衡点。