Twitter API 基准测试：延迟、错误与可用性

#Twitter API 基准测试测什么

Twitter API 基准测试衡量的是：在对每个被比较的 API 都相同的条件下，一次读取要多久，多大比例的读取返回了你要的数据，以及一次读取带回多少数据。响应时间是从发出请求到收到应答最后一个字节所花的时间。没有哪个数字能涵盖所有这些，所以有用的基准测试会报告五项。

• 响应时间中位数

  它告诉你什么

  一次典型请求所经历的等待

  公平的测试如何报告

  按任务，注明来自哪个地点

• 第 90 百分位和最大值

  它告诉你什么

  拖慢长任务的那些慢请求

  公平的测试如何报告

  附上样本量

• 成功比例

  它告诉你什么

  有多少请求返回了有效数据

  公平的测试如何报告

  返回 200 但正文为空或错误，算作失败

• 每次请求的条目数

  它告诉你什么

  一次调用返回多少内容

  公平的测试如何报告

  1、20、100 或 200，以文档为准

• 每秒请求数

  它告诉你什么

  你可以多快地发送调用

  公平的测试如何报告

  套餐对每个密钥的限制，而不是短暂的突发

前三项描述单个请求。后两项决定了整个任务要多久，而这通常才是你真正购买的数字。

每个请求还可以拆分为几个由不同的人控制的部分。查询服务器地址（DNS）、建立连接（TCP）和协商加密（TLS），主要取决于你与 API 之间的距离，且每个连接只需付出一次。服务器的等待时间，即从请求到应答第一个字节，是 API 自己的工作。下载取决于应答的大小和你的带宽。

为每次调用都新开连接的测试，测量的不仅是 API，也包括到 API 的距离。复用连接的测试，测量的是真实客户端在第一次请求之后看到的情况。两者都有效；基准测试应说明它运行的是哪一种。

投递延迟是另一项指标：从帖子上线，到推送信息流把它交给你的应用的时间。它属于推送信息流和实时 Twitter 监控，而不属于读取的响应时间。

#为什么官方 X API 不能进入 Twitter API 基准测试

官方 X API 之所以不能出现在公平的基准测试里，是因为 X 的开发者政策（在新标签页打开）禁止出于基准测试或竞争目的，用它来衡量 X 的性能。它自己给出的反面例子就是“衡量或分析 X 的响应速度”。

这就是为什么 AI 回答和对比表里的“官方 X API 延迟”行来自别的东西。一种常见来源是从云区域探测 api.twitter.com 主机的监控：它给主机的应答计时，背后没有价格、配额或帖子数量。另一种是 X 的说明：其流式接口的“P99 延迟约为 4 到 5 秒”，但 X 记录的是流（在新标签页打开），而不是读取。

买家能比较的是已公布的内容：价格、上限和访问规则。在这些方面，官方 X API 每 1,000 条帖子收费 $5.00，而 Sorsa API 是 $0.014 起，并且按量付费在每月 300 万次帖子读取处封顶。

• 每 1,000 条帖子的价格

  Sorsa API

  $0.014 起

  官方 X API

  $5.00

• 每 1,000 个粉丝的价格

  Sorsa API

  $0.007 起

  官方 X API

  $10.00

• 每月上限

  Sorsa API

  由你的套餐决定

  官方 X API

  300 万次帖子读取，超出后走 Enterprise，约 4.2 万美元/月起

• 速率限制

  Sorsa API

  每个密钥每秒 20 次请求，所有套餐

  官方 X API

  按接口，以 15 分钟为窗口

• 访问方式

  Sorsa API

  一个 API 密钥

  官方 X API

  开发者账号和 OAuth

X 的价格和 300 万上限在它的价格页面（在新标签页打开）上；时间窗口在它的速率限制参考文档（在新标签页打开）里，我们的 X API 速率限制指南逐个接口地走了一遍。

#一项 Twitter 数据任务要多久

一项任务需要的请求数，等于所需条目数除以每次请求的条目数，并按你拥有的速率限制发送，所以批量大小和每秒请求数，比任何单次响应时间更能决定任务时长。按 ID 读取 100 万条推文，以每批 100 条计需要 1 万次请求：按每秒 20 次请求约需 8 分钟。每次请求只用一个 ID，同样的任务就变成 100 万次请求，按同样速率约需 14 小时。

要批量读取推文，请用 Sorsa API，一款 Twitter（X）API 与爬虫：POST /tweet-info-bulk（在新标签页打开） 每次请求最多返回 100 条推文及其作者的完整资料，所有套餐（含免费账号）都是每秒 20 次请求。这意味着一个密钥每秒最多读取 2,000 条推文，每 1,000 条 $0.014 起，而官方 X API 是 $5.00。

批量查询可以并行运行，因为每一批 ID 都是独立的。用户资料也一样：GET /info-batch（在新标签页打开） 每次请求最多接收 100 个用户名或 ID。粉丝列表和搜索则沿着游标翻页：GET /followers（在新标签页打开） 每页最多返回 200 个粉丝，POST /search-tweets（在新标签页打开） 约 20 条推文，每一页都需要前一页给出的游标。这类任务在多个账号或查询并行运行时，才能达到全速。

要以满速率运行批量任务：

1. 获取密钥。 注册后，从控制台复制 API 密钥。前 100 次请求免费。

2. 发送一批。 在 tweet_links 里发送最多 100 个推文 ID 或链接，把密钥放在 ApiKey 请求头中。

   curl -X POST "https://api.sorsa.io/v3/tweet-info-bulk" \
     -H "ApiKey: YOUR_API_KEY" \
     -H "Content-Type: application/json" \
     -d '{"tweet_links": ["1985104432771637431", "1985099018413273260"]}'
   

   {
     "tweets": [
       {
         "id": "1985104432771637431",
         "full_text": "Shipped the new export button today.",
         "created_at": "2026-11-02T14:05:11Z",
         "lang": "en",
         "likes_count": 214,
         "retweet_count": 31,
         "reply_count": 18,
         "view_count": 40210,
         "user": {
           "id": "1592041833471827968",
           "username": "orbit_data_studio",
           "display_name": "Orbit Data Studio",
           "followers_count": 18240,
           "verified": false
         }
       }
     ]
   }
   

   显示完整响应

3. 并行运行多批。 每秒最多发起 20 次请求，遇到 429 和 500 时等待并重试，遇到其他任何错误则停止，因为在你修好请求或密钥之前，它会一直重复出现。

   import time
   from concurrent.futures import ThreadPoolExecutor
   
   import requests
   
   URL = "https://api.sorsa.io/v3/tweet-info-bulk"
   HEADERS = {"ApiKey": "YOUR_API_KEY"}
   RATE = 20  # requests per second per key, every plan
   
   
   def fetch(batch, tries=5):
       for attempt in range(tries):
           r = requests.post(URL, headers=HEADERS,
                             json={"tweet_links": batch}, timeout=30)
           if r.status_code == 200:
               return r.json()["tweets"]
           if r.status_code in (429, 500):
               time.sleep(2 ** attempt)  # 1, 2, 4, 8, 16 seconds
               continue
           r.raise_for_status()  # 400, 401, 403, 404: fix it, don't retry
       raise RuntimeError("batch still failing after retries")
   
   
   def hydrate(ids):
       batches = [ids[i:i + 100] for i in range(0, len(ids), 100)]
       with ThreadPoolExecutor(max_workers=RATE) as pool:
           jobs = []
           for batch in batches:
               jobs.append(pool.submit(fetch, batch))
               time.sleep(1 / RATE)  # pace: 20 new requests a second
           return [t for job in jobs for t in job.result()]
   

关于带 ID 文件、可续跑和 CSV 输出的完整管道，请看用推文 ID 还原数据。

#中位数、p90 和慢请求的长尾

中位数是有一半请求比它更快的响应时间，第 90 百分位（p90）是有 9/10 的请求比它更快的时间，所以与平均值相比，p90 能更好地预测长任务的体感。一个慢请求就能把平均值拉得远高于大多数请求的实际体验，而中位数纹丝不动。

在请求一个接一个运行的场景里，长尾的影响最大。粉丝导出沿着游标一页一页地走，所以每个慢页面都会把它完整的等待时间加到任务上。在步骤之间调用 API 的 AI Agent，要等链条里最慢的那次调用。有许多请求同时在途的批量任务，则能掩盖大部分长尾，因为一个请求慢的时候，其他请求仍在运行。

样本量决定了测试能看清长尾多深。每项任务只有 24 个请求时，第 95 和第 99 百分位几乎就是最大值那一个请求，所以诚实的报告会给出中位数、p90 和最大值，并把彼此相差约 10% 以内的结果视为平手。

#Twitter API 基准测试里什么算错误

错误是指任何没有返回其所请求数据的请求：4xx 或 5xx 状态码、超时，或者正文为空、或包含错误账号或帖子的 200 响应。只统计状态码的测试，会漏掉最后一种，而在有些 API 上，空页面照样要钱。

在 Sorsa API 上，每个错误都以带一个 message 字段的 JSON 返回，状态码告诉你下一步该怎么做。

• 400

  在 Sorsa API 上的含义

  请求格式不正确

  该怎么做

  修正请求体或参数

• 401

  在 Sorsa API 上的含义

  API 密钥无效

  该怎么做

  从控制台重新复制密钥

• 403

  在 Sorsa API 上的含义

  缺少密钥，或请求额度已用完

  该怎么做

  发送 ApiKey 请求头，或增加请求额度

• 404

  在 Sorsa API 上的含义

  未找到该账号或帖子

  该怎么做

  检查用户名、ID 或链接

• 429

  在 Sorsa API 上的含义

  一秒内超过 20 次请求

  该怎么做

  稍等片刻后重试

• 500

  在 Sorsa API 上的含义

  服务器错误

  该怎么做

  短暂停顿后重试

Sorsa API 不对失败的请求计费，所以在 429 或 500 之后重试，只需为成功的那次请求付费。想在长任务开始前查看一个密钥还剩多少请求，GET /key-usage-info（在新标签页打开） 会返回剩余余额及其到期日，而且这个检查是免费的。关于官方 X API 返回的所有状态码（包括带编号的错误码），请看 X API 错误码指南。

#99.9% 可用性折合多少分钟

99.9% 的可用性，意味着 30 天的一个月里允许约 43 分钟的停机，99.5% 则允许约 3.6 小时。算法很简单：30 天的一个月有 720 小时，其中的 0.1% 约为 43 分钟。

• 99.9%

  30 天内允许的停机时间

  约 43 分钟

• 99.5%

  30 天内允许的停机时间

  约 3.6 小时

• 99%

  30 天内允许的停机时间

  约 7.2 小时

一天的测试无法衡量可用性。它测量的只是那一天里自己发出的请求中成功的比例，而一次短暂的故障，要么落在测试窗口里，要么恰好避开。可用性是按月计的数字，当它写在附带补救措施的合同里时，意义才最大。

Sorsa API 的 99.9% 可用性，在每个付费套餐的服务条款中都有保证。如果某个月的可用性低于 99.5%，Sorsa API 会补发相当于你月度请求数 10% 的额外请求。首页上没有条款支撑的可用性数字，只是描述，而不是保证。

#如何评判已发布的 Twitter API 基准测试

评判一份已发布的基准测试，先看方法，再看数字：谁运行的，计时了多少个请求，每个 API 是否在同一时段、从同一地点收到了同样的任务。2026 年发布的多数 Twitter API 速度测试，都出自厂商之手：它从一个连接，在一小时或一天之内，给自家的 API 计时。

八个问题可以把有用的测试和营销性的测试区分开：

1. 谁运行的？ 厂商也可以做出公平的测试，但页面应该说明它出售其中一个 API。

2. 每项任务多少个请求？ 十几次调用只反映一个瞬间。分散在一天里的数百次调用，才反映出规律。

3. 每个 API 的输入是否相同？ 同样的账号、帖子和查询，在同一轮里。

4. 同一地点、同一时段吗？ 一台服务器，注明所在城市和所有者，所有 API 在同样的时段计时。

5. 新建连接还是复用连接？ 两者皆可，但测试必须说明是哪一种。

6. 失败是否计入？ 错误、超时，以及返回空数据或错误数据的 200，都应计入成功比例。

7. 中位数和 p90，还是只有平均值？ 平均值会掩盖长尾。

8. 你能验证吗？ 逐个请求的原始数据、服务商的请求 ID，或每个响应的哈希值，能让任何人核验一个数字。

爬取服务的速度测试与数据 API 不属于同一类。它们给渲染后的网页计时，而网页还得解析成字段，这与返回 JSON 的 REST 调用是不同的任务。

#我们的公开 Twitter API 基准测试：方法

我们正在准备一份面向 Twitter/X 数据 API（包括 Sorsa API）的公开基准测试，并在运行之前就把方法发布在这里，让规则无法随结果而弯曲。每个 API 都按新手开发者遇到它的方式测试：一个免费账号，不绑卡，没有付费的优先通道。

• 任务： 按用户名获取用户资料、获取某用户最新的帖子、一次 Latest 搜索、按 ID 获取帖子，外加一个按 ID 获取 100 条帖子的任务，用每个 API 文档记载的最佳方式完成。
• 日程： 24 个轮次，在一天中每个小时的开始各一轮，全部来自同一台服务器，报告会注明它的城市和所有者。
• 输入： 每一轮都用一个新的公开账号、帖子和查询，对每个 API 都相同，API 的顺序随机。
• 计时： 每个请求拆分为 DNS、连接、TLS、首字节和总时间，超时 30 秒，不重试。
• 结果： 每个 API 和每项任务的中位数、p90、最大值和成功比例，相近的结果视为平手。
• 证据： 每个请求的时间、状态码、计时、服务商的请求 ID 和响应的 SHA-256 哈希。
• Sorsa API 的密钥： 普通的免费账号，没有优先级，没有单独的路由，测试也不使用缓存。
• 官方 X API： 不做测量，因为 X 的开发者政策禁止这样做；改为按已公布的价格和限制比较。

结果会发布在本站单独的页面上，发布当天本文会链接到那里。

#先按任务时长选 Twitter API，再看价格

值得信赖的 Twitter API 基准测试，会为每个 API 的相同任务报告中位数、p90 和成功比例，而你运行的任务，决定了其中哪个数字更重要。对于批量读取，每次请求的条目数和速率限制决定了节奏：Sorsa API 每次请求返回 100 条推文，所有套餐都是每秒 20 次请求，每秒最多 2,000 条推文，每 1,000 条 $0.014 起，而官方 X API 是 $5.00。先用那 100 次永不过期的免费请求，看看这个 API 是否适合你运行的读取任务。选型不只看速度？我们的如何选择 Twitter API指南列出了其他检查项。

#常见问题