方法论

ruststream-nats 如何测量自己：三个循环、在真实服务器上的运行、受 Broker 限制的判定计算，以及代码计数。流程就是框架自己的流程（RustStream 方法论），本页说明它在 NATS 上是什么样子。

三个循环

一个进程把每个场景跑三遍，作为三个循环，它们只有一处不同：承载消息的是什么。

• 裸客户端。 直接驱动 async-nats：一个 Core 订阅或一个 JetStream 拉取消费者，手工读取、解码，在 JetStream 上还要手工确认。
• Broker crate。 本 crate，上面什么也没有：Broker 建立连接，描述符打开一个订阅，一个循环从它的流中取出投递、解码并 ack。
• RustStream。 用户写的服务：一个 #[subscriber] 处理器及其外围的应用。

其余一切在三个循环中都相同：连接选项、订阅、消费者配置、ack 的位置、解码成同一个结构体、载荷字节、带四个 worker 线程的 tokio 运行时，以及二进制程序。

消息体是 512 字节的 JSON。它解码成一个包含两个整数字段的结构体，因此解码不做内存分配，数字反映的是本 crate，而不是 JSON 解析器。

运行

• 每次运行使用新的 subject，在 JetStream 上还使用新的流和消费者。一次运行永远看不到之前的运行留下的东西。
• JetStream 流保存在内存中，采用工作队列保留策略。 服务器底下的磁盘不进入这项关于分发的测量。
• 消费者先订阅。 随后由第二个连接上的发布者给它供数，并且最多领先 32768 条消息，因为慢订阅者接不住的消息会被 Core NATS 丢弃。
• 在三个循环中，计时窗口都从第一次投递开始，到最后一次投递解码完成时结束。 连接、订阅和创建流都在窗口之外。
• 消息条数来自一次探测，它测量裸循环的速率，因此在任何机器上，测量的运行都至少持续五秒。
• 各循环交替进行：裸、crate、RustStream，共三轮。每个循环报告它最佳、中位和最差的一轮。

当消费者在运行的大部分时间里都在等服务器时，该行标为 受 Broker 限制。这是算出来的。一次探测为 30000 个由服务器自己应答的请求（$JS.API.INFO）计时，并取中位数。传输说明一次投递要花几次往返。二者之积达到每条消息测得时间的一半时，该行就被标记。Core 投递不花往返，因为它由服务器推送。JetStream 投递花两百分之一次往返，即为一批 200 条消息发出的拉取请求。往返时间与机器信息一起公布，因此这个计算可以核对。

代码计数

开销图的每个场景都是用户写的服务，基于 NatsBroker，连接同一台服务器，构建时不带 testing 特性，运行在单线程运行时上。一个 JetStream 拉取消费者读取一个流，另一个线程上的生产者在测量区间打开之前把这个流填满。

指令数来自 callgrind，内存分配来自 DHAT。一个场景依次在一次投递、1000 次、2000 次上运行。后两次之差是一条消息的稳态开销，单次投递就是冷启动。

服务器是真实的，所以计数在各次运行之间会有少许变动：套接字怎样把字节交给客户端，取决于时序。七次运行中，每条消息的指令数变动不到千分之五，内存分配在 2000 次的运行中只差一个块。某个场景的内存分配超过它出现过的最高总数再加千分之一时，运行失败。与保存的基线对照时，某个场景的指令数多出百分之二也算失败。

自己运行

just bench

这条命令按 docker-compose.test.yml 启动测试环境，运行两个对照场景，停止测试环境，并重写 docs/benchmarks/results.json。它需要几分钟，并且需要独占机器。它会清空 RUSTFLAGS，因此二进制程序不会绑定到构建它的 CPU 上。两条命令都按发布版本的方式构建基准测试，跨 crate 启用完整的链接时优化（fat LTO），因此这些数字描述的正是服务实际使用的代码。

just bench-code

代码计数不到一分钟，并且需要 valgrind。它安装发布版本的 Cargo.lock 所固定的基准测试运行器。在 main 上运行 just bench-code --save-baseline=main 记录基线，在分支上运行 just bench-code --baseline=main 与它对照。开头的数字改变统计的投递次数（just bench-code 5000）；公布的图表按 1000 次统计。