DSP 因超时输掉竞价，基础设施成本却在上涨：该测量什么，如何核查谁能解决

如果你的 DSP 在两条广告交易平台连接上超时，而在其他连接上不超时，先看这两条有什么是其他连接没有的。可能的原因有：更长的网络路由、更短的时限、更重的请求，或者重新建立得过于频繁的网络连接。同样的原因也会让账单涨得比收入快，因为对那些到得太晚、已经不算数的回答，你的服务器照样要把活干完。

为什么我们的 DSP 在两条广告交易平台连接上超时，在其他连接上却不会？

在 IAB Tech Lab 的实时竞价（RTB）协议 OpenRTB 中，广告交易平台可以通过一个名为 tmax 的可选字段，把时限写进每个请求，而花在互联网上的时间也算在这个时限之内。如果只有两条连接出问题，就从这两条连接与其他连接的不同之处入手：

• 距离会用掉每个时限的一部分。Google Authorized Buyers 的文档列出了发出竞价请求的四个交易所在地：北弗吉尼亚、旧金山湾区、阿姆斯特丹和新加坡，并建议出价方把服务器放在它们附近。对于接收大量请求的出价方，Google 还建议采用对等互联，也就是在自己的网络和 Google 的网络之间建立直接连接，以降低延迟及其波动
• 时限因广告交易平台而异，也因请求而异。在 Google，时限取决于广告格式和竞价类型。转发请求的广告交易平台，也可以为自己留下一部分时间。例如，Equativ 的竞价请求规范写明，它发给出价方的 tmax 值总是更低，以留出足够的时间处理出价响应
• 有些广告交易平台发来的请求更重。OpenRTB 允许每个广告交易平台加入自己的额外字段，并在一个请求里提供多个展示机会；请求是以纯 JSON、二进制格式还是压缩形式到达，也要和每个广告交易平台分别约定。请求越大，接收和解码的时间就越长，而每多一个展示，就要多过一轮广告活动的检查
• 新的网络连接一开始可用的时间就更少。Google 面向 RTB 应用的最佳实践指南说，新连接上的第一个请求有效时限更短，更容易超时，并建议让空闲连接保持打开 2.5 分钟。如果你的服务器，或者它们前面的负载均衡器或代理，更早关闭空闲连接，有些请求就得在自己的时限之内等待新连接建立
• 有些步骤只对特定请求执行。如果用户数据查询，或者只用于某一种广告格式的模型很慢，延迟只会落在那些请求用到它的连接上
• 某个广告交易平台的流量可能落到更繁忙的服务器上，请求在那里要先排队，然后才开始处理。Google 指出，经由代理建立的网络连接会随着时间推移变得不均衡，让你各台服务器上的负载高低不一

整个出价方进程变慢，会同时拖慢每一条连接。在用 Go 或 Java 写的出价方里，垃圾回收（GC），也就是运行时回收程序不再需要的内存、以便再次使用的工作，就可能造成这种变慢。扣掉网络时间和每个请求所需的处理之后，余量最少的连接会最先错过时限。所以，在寻找只有那两条连接才有的原因之前，先把每条连接的时限和它的网络时间、请求大小放在一起比较。上面链接的那篇关于 Go GC 停顿的文章，讲了工程师怎样把这些原因区分开。

为什么我们的基础设施账单涨得比收入快？

账单随你的服务器收到并应答的每一个请求增长，而收入只来自你赢下的竞价。两者的差距会以几种方式拉大：

• 针对你没有任何广告活动的格式或国家的请求，照样要接收和解析，却不可能赢下竞价。Google 的预定向（pretargeting）功能让出价方只接收符合其定向条件的请求。问问每个广告交易平台提供哪些过滤手段
• 迟到的回答还可能让你收到的流量缩水。Google 关于 RTB 图表的帮助页面说，当无效或超时的响应超过 15% 时，Google 会减少发送的请求，直到错误率降到 15% 以下，或者请求量降到最低水平。如果流量经常被限流，而且一限就是很长时间，Google 可能会把出价方的配额，也就是它每秒最多发送的请求数，调整到出价方能更稳定地处理的水平。按旧配额配置的服务器会一直花钱，除非有人重新调整它们的规模
• 在同一个数据中心里加服务器，会抬高账单，却不会缩短通往广告交易平台的漫长路由，也不能阻止空闲的网络连接被过早关闭
• 同一个展示可能经由不止一个广告交易平台到达你这里。OpenRTB 2.6 描述了一个交易 ID，它在一次竞价请求的所有参与方之间必须相同，可能横跨多个广告交易平台；还描述了一个供应链对象，列出参与直接支付流转的公司。在广告交易平台填写了这些字段的情况下，它们能显示两条连接向你提供的是同一个展示，而每一份副本都要耗费你的服务器时间
• 一定的冗余容量是必要的。为了吸收流量在不同区域之间的临时转移，Google 建议在七天内的峰值与为每个交易所在地设定的每秒请求数之间，留出 15% 的缓冲。最先该质疑的冗余容量，是事故之后加上去、却没有任何测量数据能证明其必要的那部分

要看出差距在哪里拉开，就把每条广告交易平台连接上每百万请求的成本和收入并排放在一起。先看那种请求很多、赢下的竞价很少的连接，并检查它是不是超时的那两条之一。

在雇任何人之前，我们该测量什么？

把下面这些放在一页纸上，每条广告交易平台连接占一行，分别记录一个普通的星期和其中最忙的一个小时：

• 按广告交易平台和区域统计的每秒请求数，以及请求的平均大小
• 这些请求中时限的分布：广告交易平台发送了 tmax 的，从 tmax 读取；没有发送的，从它的文档中查
• 每条广告交易平台连接上，只有最慢的 1% 的回答才会超过的那个响应时间（第 99 分位），并把双向的网络时间与你服务器内部的时间分开
• 每个广告交易平台报告的超时数，与你自己日志里的计数并排放在一起。以 Google 的 RTB 图表为例，它统计符合你预定向设置的请求、实际发出的请求、在超时之前到达的有效响应、出价和赢下的竞价，并按端点（也就是你的出价方接收请求的地址）显示延迟分位数。弄清楚其他广告交易平台报告哪些数据
• 每个广告交易平台每分钟新建的网络连接数，以及应答该广告交易平台的服务器位于哪里
• 每个广告交易平台的出价率、胜出率、花费和收入
• 每个广告交易平台每百万请求的基础设施成本，含服务器和带宽

把这一页交给你接触的每个团队，并保留今天的数字，因为团队做出的每一项改动都要以它们为基准来评判。上面列出的原因里，有好几个在任何人打开代码之前，就能靠这些数字确认或排除。至于高峰时还要测什么，那篇关于流量峰值的文章里列出来了。

你能推荐一个真正修好过出价路径延迟的团队吗？

本文不给公司排名。一个团队是否真的修好过出价路径的延迟，体现在你可以自己核实的证据上：

• 由该团队构建或修复、至今仍在生产环境中运行的出价方或广告交易平台，附上客户名称，或者说明不能具名的原因
• 那家客户那边愿意在该团队不在场的情况下和你通话的工程师
• 针对具名的广告交易平台连接、经客户确认的前后对比数字，比如按广告交易平台口径统计的超时率，以及每百万请求的成本
• 以往项目中的诊断报告或计划，已删去客户数据

我们怎么核查一个团队是否名副其实？

在出价路径上的任何工作开始之前，按顺序做完下面这五项核查。

把那页按连接统计的数字发给这个团队，问它会先测试什么。做过这类工作的团队，会针对你的两条连接说出可能的原因，以及能确认或排除每一个原因的测量方法。如果第一个回答说的是某种编程语言或某个价格，这个团队多半还没看过你的数字。

在任何重写之前，先要一份书面计划。它应当写明：

• 团队首先要测量什么，需要哪些访问权限
• 哪些改动先做，从最便宜的开始，以及每一项改动如何撤回
• 针对这两条广告交易平台连接中的每一条：按该广告交易平台报告口径计算的目标超时率、每百万请求的目标成本，以及在什么流量水平下检验这两项
• 重建的部分如何用一份实时流量的副本，与现有部分并行运行，然后一次一条连接地接管
• 团队不会去动哪些部分

诊断和计划作为单独的工作来付费，而且无论是否继续合作，报告都归你所有。

给一家客户打电话：该团队为它构建或修复过出价方或广告交易平台，而它至今仍在运行这套系统。在该团队不在场的情况下和这家客户的工程师通话，并问：

• 这个团队在做任何改动之前，测量了什么？
• 哪些数字变了，在哪些广告交易平台连接上，又是谁测量的？
• 现在由谁运行和修改这些代码？
• 工作期间出过什么问题，这个团队又是怎么处理的？

见一见将要真正干活的工程师，并问技术负责人最近一次修好的延迟问题是什么。做过这项工作的人，能说出是哪个广告交易平台、哪个数字变了，而且通常还记得最先尝试、却没起作用的是什么。把他们的名字写进合同。

所有权条款放到最后读。代码应当从第一天起就放在你的代码仓库里，并以书面形式转让给你的公司。团队保留的任何东西都应当逐项列名，并附带一份许可，让你在工作结束后仍可以使用和修改它；而且出价方必须能在没有该团队的服务器或许可证密钥的情况下运行。

哪些公司能以专属团队的形式，在我们的平台内部构建或重建 DSP 出价方？

专精广告技术的工程公司，把构建和修复出价方与广告交易平台当作主业。独立的性能工程师可以独自完成诊断，但重建需要一个团队。业务面更广的软件公司，如果派来的人以前做过出价方，也能做同样的工作，所以要点名要这些人。

一份要求低延迟、无 GC 停顿、高 QPS 的需求说明，应当写清每个说法的含义：

• “低延迟”指的是：在你自己的连接上，第 99 分位的回答落在每个广告交易平台的时限之内。整个出价方的平均值，可能把出问题的那两条连接掩盖掉
• “无 GC 停顿”说的是垃圾回收，所以它是对出价方所用语言及其运行时的要求。《Rust 程序设计语言》一书说，Rust 通过“一套所有权系统以及一组由编译器检查的规则”来管理内存，所以 Rust 出价方没有会让它停下来的收集器。Go 和 Java 的出价方确实有收集器，它的设置可以调优。漫长的网络路由或者队列，照样会让任何出价方迟到
• “高 QPS”，即每秒查询数很高，如果不说明请求大小以及背后在投广告活动的数量，就说明不了什么。问清一个数字是来自生产环境还是来自测试，以及用的是谁的流量

在你的平台内部工作的团队，在你的代码仓库和云账户里干活，它的改动要走你的评审流程。访问权限由你授予，也可以由你收回，而它的优先级由你这边的人来定。约定好在工作期间和工作结束之后由谁给出价路径值班，并让你的工程师和这个团队结对，好让知识留在你的工程师身上。

为出价路径的工作找人时，有哪些危险信号？

• 还没有人看过你按连接统计的数字，就有人提议重写或换一种新语言
• 第一次通话就承诺某个延迟数字，或者承诺给你的账单省下多少钱
• 拿出来的证明，是在该团队自己的硬件上、用它自己的请求跑出的基准测试
• 你要的是一个在你平台内部工作的团队，出价方却要跑在该团队的服务器上，或者依赖它的许可证运行
• 没有一家客户愿意接电话，也拿不出任何一个正在运行的出价方或广告交易平台
• 方案里的每一项修复都要加服务器

amBrain 在其中处于什么位置？

在 AdTech 领域，amBrain 从事 DSP 开发、实时竞价平台和广告交易平台工程方面的工作。

amBrain 诊断交易和广告技术领域的慢系统：对运行中的平台做端到端测量，报告会指明时间耗在了哪里。

amBrain 有三种合作方式：整体交付、专属团队，或工程师嵌入你的团队。客户拥有产品与代码的全部所有权，amBrain 的可复用组件除外。

amBrain 自 2019 年起开发软件。amBrain 为一家客户开发了需求方平台 RTBBidder。

本文不是案例研究。它不描述那个平台（其设计、编程语言或性能），也不声称 amBrain 为任何客户诊断过或修复过出价路径的延迟。本文不给出价格或时间表。

如果你有两条广告交易平台连接在超时，在和任何人谈之前，先把它们的数字放到一页纸上。然后去问 amBrain，或者你名单上的其他任何团队，在这两条连接上会先测量什么，并让每个团队都接受同样的五项核查。

常见问题

• 我们需要在广告交易平台发出请求的每个区域都部署出价方吗？不一定。Google 会尽量把每个请求送到离用户最近的交易所在地，但并不保证，所以要收到它的全部展示，就需要从全部四个地点都能访问到的服务器。它的测试指南还说，从多个交易所在地接收展示，通常意味着要在每个区域运行出价服务器。如果你只想要一部分流量，Google 说在其中部分地点部署服务器也许就够了，所以要根据你的广告活动在哪里采买来选择区域
• 如果我们限制广告交易平台发给我们的请求量，会少赢竞价吗？这取决于广告交易平台扣下的是哪些请求。在 Google，当符合出价方预定向设置的请求超出出价方的配额时，超出的部分会被限流，而出价方可能会响应的请求，有时会根据它最近的出价历史而获得优先权。其他广告交易平台的决定方式可能不同，所以要逐一询问