采集前先测一把：搜索 API 的性能基准测试实践

「这个接口能扛多少并发？延迟多少？最优参数是什么？」——这些问题应该在采集系统上线前用基准测试回答，而不是上线后靠事故发现。这篇记录我给搜索数据接口（SerpBase，serpbase.dev）做性能基准测试的实践：测什么、怎么测、结果怎么用。

为什么需要基准测试

搜索数据采集的性能瓶颈在「接口的 QPS 上限和延迟特性」，而这两点接口文档不会给你精确值。上线前跑一次基准，能回答：

1. 单请求延迟：P50/P90/P95，判断够不够实时
2. 并发上限：多大的并发开始触发限流/延迟飙升
3. 最优并发：吞吐最高且稳定的并发数
4. 最优参数：要不要分页、要不要换端点

有了这些数据，采集任务的并发设置、调度节奏、容量规划都有依据，而不是拍脑袋。

测什么：三个核心指标

• 延迟分布：P50/P90/P95（尾延迟比均值重要）
• 吞吐：每秒完成的请求数（不是并发数）
• 成功率：不同并发下的成功率（限流的信号）

怎么写基准脚本

用免费额度跑（注册送 100 次），控制好量别把免费额度烧完：

import requests
import time
import statistics
from concurrent.futures import ThreadPoolExecutor

API_KEY = "你的key"
URL = "https://api.serpbase.dev/google/search"
HEADERS = {"Content-Type": "application/json", "X-API-Key": API_KEY}

def single_request():
    start = time.time()
    resp = requests.post(
        URL, headers=HEADERS,
        json={"q": "serp api benchmark", "hl": "en", "gl": "us"},
        timeout=30,
    )
    data = resp.json()
    return {
        "ok": data.get("status") == 0,
        "latency_ms": (time.time() - start) * 1000,
    }

def bench(concurrency, total=40):
    results = []
    with ThreadPoolExecutor(max_workers=concurrency) as ex:
        futures = [ex.submit(single_request) for _ in range(total)]
        for fut in futures:
            results.append(fut.result())

    lats = sorted(r["latency_ms"] for r in results if r["ok"])
    return {
        "concurrency": concurrency,
        "success_rate": sum(1 for r in results if r["ok"]) / len(results),
        "p50": statistics.median(lats) if lats else 0,
        "p90": lats[int(len(lats) * 0.9)] if lats else 0,
        "p95": lats[int(len(lats) * 0.95)] if lats else 0,
        "throughput": len(results) / (sum(r["latency_ms"] for r in results) / 1000 / concurrency) if results else 0,
    }

# 梯度测试：并发 1 / 5 / 10 / 20
for c in [1, 5, 10, 20]:
    print(bench(c))

注意：这是消耗真实请求的基准（每次 1 credits）。用免费额度做「小样本梯度」够用（每档 20-40 次），别跑大数据量。

结果怎么解读

典型的基准结果长这样（示意）：

并发	成功率	P50	P90	结论
1	100%	1.4s	2.0s	单请求基线
5	100%	1.5s	2.2s	稳定，吞吐线性涨
10	100%	1.6s	2.5s	吞吐到顶附近
20	96%	2.8s	5.0s	触发限流，延迟飙升

解读规律：

• P90 明显高于 P50 → 尾延迟存在，实时场景要留余量
• 并发翻倍但吞吐不涨 → 已到接口 QPS 上限
• 成功率下降 + 延迟飙升 → 越过限流线，这个并发是上限

最优并发 = 成功率 100%、吞吐最高且稳定的那档（上例是 10）。

结果怎么落地

基准数据不是「跑完就完」，落地到三处：

1. 并发配置：采集脚本的并发数 = 基准测出的最优值（别拍脑袋）
2. 容量规划：知道「每秒能采多少」，倒推「10 万关键词要跑多久」
3. 监控基线：基准的 P90/P95 就是健康监控的基线——线上延迟明显高于基线 = 有问题（响应慢篇的基线来源）

# 伪代码：基准结果落库，作为监控基线
BASELINE = {"p50": 1500, "p90": 2200, "optimal_concurrency": 10}

踩坑记录

坑 1：用真实业务关键词做基准。 基准请求量大，别用生产要采的词（会污染你自己的数据），用独立的测试词。

坑 2：并发测太大，把免费额度烧了。 20 并发 × 40 次 = 800 credits，一下烧掉 8 个词的免费额度。小样本梯度（每档 20 次）够用。

坑 3：只看平均值。 均值好看但尾延迟吓人。必须看 P90/P95。

坑 4：没做并发梯度。 只测单请求，不知道并发上限。梯度是基准的核心。

工程清单沉淀

1. 测三个指标：延迟分布、吞吐、成功率
2. 跑并发梯度（1/5/10/20），找最优并发
3. 解读：P90-P50 差距看尾延迟，吞吐不涨看上限
4. 结果落地：并发配置 + 容量规划 + 监控基线
5. 用免费额度做小样本，别烧光

基准测试让「接口能力」从玄学变数据。采集系统的并发、容量、监控基线，都该从这一把基准开始。

接口的参数和计费（1 credits/次）在 SerpBase 官方文档 里可查，基准前先确认。你的采集任务做过基准测试吗？评论区聊聊测得的最优并发。