数字

ruststream-nats 的基准测试数字测的是什么，以及不能从中得出哪些结论。

与裸客户端的对照

同一行中的三个循环可以互相比较，因为它们在同一个进程中、交替地、对着同一台服务器运行。一行不能与另一个 Broker crate 公布的行比较：各种传输在每条消息上做的工作不同。

服务器运行在同一台机器上，走回环接口。没有网络延迟，同样的每条消息开销在时间中所占的比例，比面对跨网络的服务器时更大。应把该百分比读作已部署服务所付代价的上界。

标为 无法区分 的行，其各循环之间的差异小于各轮之间的波动。低于这一噪声的数字会显得精确，而这种精度从未被测出，因此不予公布。在 JetStream 上，每次投递都要把一个确认发回服务器，这么小的差异淹没在其中。

受 Broker 限制 的行表示消费者在运行的大部分时间里都在等服务器。本 crate 和运行时的工作于是发生在这段等待之内，测出的差异接近零。这是开销的下界，而不是对它的测量。

代码的开销

指令计数包含本 crate 的代码、它上面的运行时，以及 async-nats 在服务线程上的工作，其中包括它的连接任务。由于服务器是真实的，计数在各次运行之间会有少许变动。同样的计数在缓存未命中处要花更多时间，因此计数不等于时间。

每个数字都是稳态，即 1000 次投递的运行与 2000 次投递的运行之差。连接、查找流、创建消费者以及它们背后的首批内存分配属于冷启动，只付一次。

JetStream 投递的内存分配大多属于客户端：每交出一百条消息发出的一个拉取请求，以及它的连接任务与订阅之间通道的内存块。

它们不意味着什么

一行就是一个消费者读取一个 subject，消息体很小，服务器只有一台。它测量的是一次投递在本 crate 内部的开销，而不是 NATS 能承载多少。

JetStream 流保存在内存中。基于文件存储的流回答的是另一个问题，关于服务器，而不是关于本 crate。队列组、一组 worker 工作分区以及同一个流上的多个消费者，也各自回答不同的问题，这个对照不测量其中任何一个。代码图在同一测试环境上统计批处理器和应答。

这些数字是一台机器在某一天的快照，构建信息记录在旁边。它们在一台只做这次运行的机器上手动重新测量：它们显示的差异小于共享机器的噪声。