数字

ruststream-gcp-pubsub 的基准测试数字测的是什么，以及它们不能支持哪些结论。

与裸客户端的对照

同一行的三个循环可以相互比较，因为它们在同一个进程里交错运行，对着同一个模拟器。一行不能拿去和另一个 Broker crate 公布的一行比较：不同的传输在每条消息上做的事并不一样。

标为「无法区分」的开销，是该循环与裸客户端之间的差值小于各自多次运行之间离散范围的那一种。凡是传输本身 比分发贵得多的地方，这就是诚实的结果。低于运行噪声的数字读起来像是从未测到过的精度，所以不公布。

「受 Broker 限制」的一行是被模拟器定的速：所有循环都在同一份等待里跑完了整轮。它们之间的差值于是是分发 开销的下界，而不是对它的测量。第一行离这条线只差几个百分点，每次运行都可能落在线的这一侧或那一侧，所以 它有没有这个标记，都说明不了消费者是否曾经是瓶颈。

代码的开销

这些数字是绝对值，客户端和框架的工作都算在内；框架单独的开销由核心库在它的 基准测试页上公布。同样的指令数 在缓存未命中的地方要花更多时间，所以计数不等于时间。

每个数字都是稳态，即 1000 次投递的运行和 2000 次投递的运行之间的斜率。启动服务和处理第一次投递是冷启动， 只付一次。

它们不意味着什么

模拟器不是那个服务。它在回环地址上用明文应答同一套 API，把 TLS 握手、凭据刷新和到某个地域的往返 都留在了外面。所有循环都对着同一个模拟器说话，所以它们之间的比较仍然成立；速率本身则是一个本地数字， 这里没有任何东西能预言一个订阅从某个地域投递多少。

流控是模拟器不复现的第二样东西。它能发多快就发多快，不管订阅上写着什么上限，所以没有一个循环会遇到 云上的订阅对落后的消费者施加的那次暂停。

一行就是一个消费者、一个订阅、一个很小的消息体，以及一台跑在回环地址上的模拟器。它测的是一次投递在这个 crate 里的开销，不是 Pub/Sub 能扛多少。

这些数字是一台机器在某一天的快照，构建信息和它们记在一起。它们由人手工重测，测量期间机器只跑这一项： 它们显示的差值，比与其他任务共用的机器上的噪声还小。