数字

每个公布的数字测的是什么，哪些数字之间可以相互比较。

与裸客户端的对照

每一行都由维护该 Broker crate 的人测出，在自己的机器上，对着 localhost 上的 Broker。 因此行与行之间不可比：一行的绝对吞吐量说明不了另一行的任何事情。可比的只有同一行里的各个循环， 结果要做的正是这一比较。

localhost 上的 Broker，对框架来说是最苛刻的环境。这里没有网络延迟。每条消息的绝对开销不变， 因此占的比例比隔着真实网络时更大。应把该百分比读作已部署服务所付代价的上界，而不是典型值。

“受 Broker 限制”标记表示，裸客户端在整个运行的大部分时间里都在等套接字。框架的工作于是发生在 原本就在等待的时间里，测出的差异趋近于零。对这类负载来说这是真实结果：饱和的消费者就是这样。 但这样的数字是分发开销的下界，不是对它的测量，切勿读成“免费”。

框架代码的开销

指令数是精确的。在 ruststream 里，同一个二进制程序跑两次得到同一个数字，快一倍的机器也得到 同一个数字，因此 ruststream 的各行之间可比，与另一台机器上测出的同一行也可比。指令数说明不了 的是时间：同样的指令数，在缓存未命中处要花更多时间。

在 ruststream 里，这个数字就是本 crate 自身的工作，此外别无他物： 用户写的服务，跑在进程内队列上，把载荷解码成一个类型、读一个字段、确认投递。里面没有 Broker， 所以只有框架的代码变了，数字才会变。这正是两个百分点可以算作缺陷而不是噪声的原因。

每条消息的数字都是稳态。启动服务的开销只付一次：连接、建立订阅，以及它们背后的首批内存分配。 把它摊到一次运行的消息上，等于把一次性的价钱当成每条消息的价钱公布出去。因此每个场景测两次， 第二次的投递数是第一次的两倍，一条消息的开销就是两次运行之差；冷启动单独测，只投递一条消息。 在 ruststream 里，这两次分别是一千条和两千条。

内存分配按每条消息统计。在 ruststream 里，投递路径上是零：服务跑起来之后，消息从队列走到 处理器函数体，框架一次也没有向分配器要过内存。ruststream 发布路径上的数字，就是 Broker 为持有交给它的消息所要的那几次分配，此外再无其他。

Broker crate 在真实的传输上测量自己，多数是对着自己 compose 文件里的 Broker。因此它的数字里 还包含客户端的工作，每次运行之间也会有少许变动。数字包含哪些开销、变动多大、两次运行各投递 多少条、受哪个上限约束，都写在该 crate 的基准测试页面上。