Big Pineapple是1.1.1.1、Gateway DNS、DNS防火墙、AS112及其他多个Cloudflare DNS服务背后的平台，随时存储超过2500亿条DNS缓存项。在这种规模下，每个条目浪费一个字节的成本相当于我们整个系统超过250GB的内存。连续的五次变更缓存条目在内存中的存储方式，使每个条目的占用减少了超过50%。在我们的整个系统中，这些变更释放了大约100TB的内存，相当于130台第13代服务器的RAM总量。缓存的速度也提升了。插入处理能力提高了43%，查找延迟降低了19%，因为更少的分配和更好的内存局部性使我们没有为了空间而牺牲速度。缓存的内容在冷启动时，Big Pineapple开始时有一个空缓存。随着DNS查询的到来，缓存逐渐填满，直到达到其最大条目数，此时我们会驱逐旧的或不太受欢迎的项目以腾出空间。确切的缓存大小因数据中心而异。当使用EDNS客户端子网（ECS）时，权威服务器会根据客户端的网络返回不同的答案，因此我们会缓存同一查询的多个版本。这增加了条目数量和每个条目所消耗的内存，使本帖中的优化对ECS密集型位置尤其具有影响力。缓存中的每个项目都是一个键值对。键用于识别查询的内容：pub struct CacheKey { qname: Name, qtype: Rtype, authenticated: bool, tag: Vec < u8 >, } 值存储DNS响应本身：答案、权威和附加记录部分，以及诸如创建时间、命中计数和生存时间（TTL）等元数据。pub struct CacheEntry { timestamp: UnixTimeStamp, pub inception: Instant, pub ttl: Ttl, pub hits: u32, pub answers: Vec < Record >, pub authority: Vec < Record >, pub additional: Vec < Record >, pub errors: Vec < ExtendedError >, ... } 这两个结构体都有改进的空间。若干字段使用了在条目存储后我们不需要的额外开销类型。基准内存使用为了衡量每个变更的影响，我们通过填充缓存入随机生成的条目进行基准测试，这些条目大致匹配我们在生产环境中看到的流量分布：56% A记录、25% AAAA，以及19% TXT。每个条目包含1到4条记录。TXT记录作为基准测试中所有非A / AAAA记录类型的替代。它们的大小在64到224字节之间随机化，接近我们在变长记录类型中看到的平均响应大小。我们使用自定义分配器跟踪内存使用情况，该分配器包装Rust的系统分配器，并记录每个缓存条目的分配数量和大小。除了内存，我们还在整个缓存流中测量插入处理能力和查找延迟，以确保内存节省不会以性能为代价。这些输入近似于生产，而不是完全重现。处理内存还取决于流量混合、缓存占用、分配器状态以及缓存外部使用的内存。因此，我们在推广期间测量了生产实例的常驻内存。容量的成本Vec<T>存储三个字段：指向堆分配数据的指针、当前长度和总容量。当你推送一个项目时，Vec检查长度是否超过容量，并在需要时重新分配。如果有空间，它只需附加项目并增加长度。然而，一旦我们将DNS响应存储在缓存中，我们就不会再次修改它。容量字段没有用处，但仍然为每个Vec成本8个字节。过度分配的堆空间也是浪费的，因为一个容量为八个项目但只存储了五个的Vec在堆上留下三个空槽。使用Box<[T]>解决了这两个问题。它在创建后无法增长，因此不需要容量字段或为将来元素保留空间。同样适用于String，它也携带一个容量字段。Box<str>摒弃了它。每个缓存条目存储8个Vec和String字段。用Box<[T]>和Box<str>替换它们为每个字段节省了8个字节，为每个条目节省了64个字节。它还消除了Vec为未来增长所保留的多余堆内存。综合节省超过15TB，且超过2500亿条缓存项。更少的列表，更少的指针我们可以存储一个包含每个部分起始偏移量的单个列表，而不是将答案、权威和附加部分存储在单独的列表中。由于DNS记录每部分的计数可以适应u16，我们可以为每个偏移量使用u16（2字节），相比之下，每个单独的Box<[T]>需要8字节指针和8字节长度。这样就去掉了两个列表，每个都有一个8字节的指针和8字节的长度，替换为两个2字节的偏移量，为每个条目节省了28字节。这些节省并不总是直接与从单个字段中去掉的字节数量相关。Rust插入填充以满足对齐要求，并将结构体的大小上调到其对齐的倍数。移除小字段因此可以消除。