数字

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

与裸客户端的对照

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

一次读取承载最多一千条记录，因此它分摊到一条记录上的份额很小。在 DynamoDB 那一行，每条记录还要付出一次属于自己的条件写入，即它的 ack 背后的检查点。在 受模拟器限制 的行中，往返至少占了一次投递所用时间的一半。本 crate 和运行时的工作于是发生在一段裸客户端同样要付出的等待之内，各循环之间的差异是这部分工作的下界，而不是对它的测量。

决定两行节奏的，是模拟器在一个分片上接收和返回记录的速度，与哪个循环读取它们无关，而往返计算不统计这一点。因此一行中的三个循环都落在彼此的波动范围之内。这两行说明，本 crate 和运行时都没有高出这个下限。它们没有说明在更快的测试环境上三者会如何比较。

代码的开销

指令计数包含运行时、本 crate，以及 AWS SDK 在服务线程上的工作：构建并签名每个请求、HTTP 交换，以及解析每个应答。一次投递分摊一次 GetRecords 的一份，应答还要加上一次属于自己的 PutRecord，所以应答那一行几乎全是 SDK 的工作。每个数字的大部分都是 SDK 的工作，而不是本 crate 的工作，这些数字不能与客户端在自己线程上工作的 Broker 的数字相比。同样的计数在缓存未命中处要花更多时间，因此计数不等于时间。

每个数字都是稳态，即 1000 次投递的运行与 2000 次投递的运行之差。连接、打开订阅、列出分片、获取它的租约和迭代器，以及它们背后的首批内存分配属于冷启动，只付一次。

它们不意味着什么

测试环境是 LocalStack，一个 Kinesis 和 DynamoDB 的模拟器，而不是托管服务。它在回环接口上用普通 HTTP 应答，没有 TLS 握手、凭证刷新和区域的延迟。对照仍然成立，因为三个循环都与同一个模拟器通信。吞吐量不能推及真实服务：区域中的流有按分片计算的限制，应答的时间尺度也不同。

一行就是一个分片、一个消费者和 512 字节的消息体。它测量的是一条记录在本 crate 内部的开销，而不是 Kinesis 能承载多少。

在三个循环中，计时窗口都在读出最后一条记录的字段时、在写入它的检查点之前关闭，因此每次运行都有一个检查点处于所有数字之外。追上填充者的消费者在空读取之后要付出 20 毫秒的等待，这段等待计入被它推迟的那条记录。

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