本指南介绍了根据 RTB 协议开发应用时应考虑的最佳实践。
管理连接
保持连接
与重复使用现有连接相比，建立新连接会增加延迟时间，并且会在两端消耗更多资源。关闭的连接越少，就越少需要重新打开的连接。
首先，每个新连接都需要额外的网络往返才能建立。由于我们按需建立连接，因此与后续请求相比，连接上的第一个请求有效截止期限更短，更有可能超时。任何额外的超时都会增加错误率，从而导致 您的出价工具受到限制
其次，许多 Web 服务器都会为建立的每个连接生成一个专用工作器线程。这意味着，如需关闭并重新创建连接，服务器必须关闭并舍弃一个线程，分配一个新线程，使其可运行，并构建连接状态，然后才能最终处理请求。这会产生大量不必要的开销。
避免关闭连接
首先，请调整连接行为。大多数服务器默认设置专为包含大量客户端（每个客户端发出少量请求）的环境而量身定制。与之相反，对于 RTB，相对而言，一小部分机器会代表大量浏览器发送请求。在这些情况下，尽可能重复使用连接是明智之举。我们建议您设置以下内容：
- 空闲超时设置为 2.5 分钟。
- 将连接的请求数上限设为可能的最高值。
- 连接数上限（达到您的 RAM 可允许的最高值） 同时注意确认连接的数量 也不要过于接近这个值
例如，在 Apache 中，这需要将 KeepAliveTimeout 设置为 150、MaxKeepAliveRequests 设置为零，并将 MaxClients 设置为一个取决于服务器类型的值。
调整连接行为后，您还应确保出价方代码不会不必要地关闭连接。例如，如果您的前端代码在发生后端错误或超时时返回默认的“无出价”响应，请确保该代码在返回响应时不会关闭连接。这样，您就可以避免以下情况：如果出价方过载，连接开始关闭，超时数量增加，导致出价方被节流。
保持连接均衡
如果 Authorized Buyers 通过代理服务器连接到您的出价方服务器，那么连接可能会随着时间的推移而变得不平衡，因为 Authorized Buyers 只知道代理服务器的 IP 地址，无法确定每个宣传信息是发送到哪个出价方服务器。随着时间的推移，随着 Authorized Buyers 建立和关闭连接以及出价方的服务器重启，映射到每个出价方的连接数量可能会变得极不稳定。
当某些连接被大量使用时，其他打开的连接可能大部分处于空闲状态，因为它们目前不需要。随着 Authorized Buyers 的流量变化，空闲连接可能会变为活跃连接，活跃连接可能会变为空闲连接。如果连接分组不当，这些连接可能会导致出价方服务器上的负载不均。Google 会尝试通过在收到 10,000 个请求后关闭所有连接来防止这种情况，以便随着时间的推移自动重新平衡热门连接。如果您发现环境中的流量仍然不平衡，可以采取进一步措施：
- 如果您使用的是前端代理，请按请求选择后端，而不是按连接选择一次。
- 如果您通过硬件负载均衡器或防火墙代理连接，并且连接建立后映射会固定，请指定每个连接的请求数上限。请注意，Google 已指定每个连接的请求上限为 1 万个，因此，如果您仍然发现热门连接在您的环境中出现重合，则只需提供更严格的值。例如，在 Apache 中，将
MaxKeepAliveRequests设置为 5,000 - 配置出价方的服务器以监控其请求率并完成部分请求率 处理自己的连接数 （与类似应用相比）。
妥善处理过载
理想情况下，配额应该设置得足够高，这样您的出价工具就可以收到 但仅能处理这些请求在实践中，将配额保持在最佳水平是一项艰巨的任务，并且确实会发生过载，原因有很多：后端在高峰时段宕机、流量组合发生变化，导致每个请求都需要进行更多处理，或者配额值设置得过高。因此，请务必仔细考虑您的出价工具 因为传入流量过大
为了适应不同区域（尤其是亚洲与美国西部、美国东部与美国西部）之间的临时流量转移（最长一周），我们建议在 7 天高峰值与每个交易地点的 QPS 之间留出 15% 的缓冲空间。
就高负载下的行为而言，出价方可分为三大类 类别：
- “全面响应”出价方
虽然此出价方易于实现，但在过载时表现最差。它只会尝试响应收到的每个出价请求，无论如何，都会将无法立即处理的请求加入队列。接下来发生的情况通常如下所示：
- 随着请求速率的提高，请求延迟时间也会随之增加，直到所有请求都开始超时
- 随着宣传信息展示次数接近峰值，延迟时间会急剧增加
- 系统开始限制，允许的出价邀约数量急剧减少
- 延迟时间开始恢复，导致节流减少
- 周期再次开始。
此出价工具的延迟时间图呈现了一个非常陡峭的锯齿状 模式。或者，排队的请求会导致服务器开始分页。 或执行其他会导致长期运行缓慢的操作， 在高峰期结束之前，根本不会恢复，因此会导致出价结果低落 在整个高峰期内的费率无论是哪种情况，出价邀约数量都会减少，或者 响应将与配额只设置更低的值相比。
- “error on overload”出价方
此出价方接受的宣传信息数量上限为一定值，然后开始针对某些宣传信息返回错误。这可以通过内部超时、停用 连接队列（由 Apache 上的
ListenBackLog控制）、 实现概率下降模式 或其他某种机制如果 Google 发现错误率超过 15% 我们将开始限制与“对所有请求做出响应”的出价方不同，此类出价方会“减少损失”，从而能够在请求率下降时立即恢复。在过载期间，此出价方的延迟时间图表类似于浅锯齿形模式，在可接受的最大速率附近局部化。
- “在超载时不出价”出价方
此出价方接受出价邀约并达到特定比率，然后开始返回 “无出价”对任何过载的响应。与“过载错误”类似出价工具 这可通过多种方式实现不同的是 信号会传回 Google，因此我们绝不会限制出价邀约数量。前端机器会吸收过载，并且只允许其能够处理的流量继续传递到后端。
此出价工具的延迟时间图显示了一个平稳（人为地） 请求速率在峰值时段就会停止， 包含出价的响应所占的比例。
我们建议您将“超载时出错”与“超载时不出价”方法结合使用，具体方法如下：
- 超额预配前端，并将其设置为过载出错，帮助最大化它们能以某种形式响应的连接数。
- 当发生过载错误时，前端机器可以使用预先创建的“不出价”响应，而无需解析请求。
- 对后端进行健康检查，以便在没有足够容量的后端时返回“不出价”响应。
这样可以吸收部分过载，并让后端有机会响应其能够处理的确切请求数量。您可以这样理解 设置为“超载不出价”而前端机器则回退到“错误 超载”在请求数量远远高于预期时触发。
如果你有一个“回答一切问题”请考虑将其转换为 “超载出错”来调整连接行为，使其生效 拒绝超载虽然这会导致返回更多错误，但可以减少超时，并防止服务器进入无法响应任何请求的状态。
响应 ping
确保出价方可以响应 ping 请求（而非连接管理本身）对调试来说非常重要。Google 使用 ping 命令 请求对出价工具状态进行健全性检查和调试、连接关闭 行为、延迟时间等。Ping 请求的格式如下：
OpenRTB 协议缓冲区
id: "7xd2P2M7K32d7F7Y50p631"
OpenRTB JSON
{
"id": "4YB27BCXimH5g7wB39nd3t"
}
Google（已废弃）
id: "\3503cg\3023P\364\230\240\270\020\255\002\231\314\010\362\347\351\246\357("
is_test: true
is_ping: true
请注意，与您预期的相反，该 ping 请求不包含任何广告位。如上文详述的那样，您不应在响应 ping 请求后关闭连接。
考虑对等连接
减少网络延迟或变化的另一种方法是与 Google 对等互连。 对等互连有助于优化流量到达您的出价工具所采取的路径。通过 连接端点保持不变，但中间链接发生变化。如需了解详情，请参阅对等连接指南。将对等连接视为最佳实践的原因可总结如下：
在互联网上，公交链接主要通过“土豆红”进行选择 路由”该功能可找到离我们 网络以外的距离最近的链接， 数据包发送到其目的地，并通过该链接路由数据包。如果流量穿过与我们有许多对等连接的提供商拥有的骨干网段，则所选链接可能位于数据包起点附近。在此之后，我们无法控制数据包的路由 因此可能会被退回到其他自治系统 （网络）。
相比之下，如果存在直接对等协议，数据包始终会通过对等链接发送。无论数据包来自何处，它都会穿越 Google 拥有或租用的链路，直到到达共享对等点（应靠近出价方位置）。返回行程首先会跳转到 Google 网络，然后在其余路程中一直在 Google 网络上。让大部分路程都在 Google 管理的基础架构上运行，可确保数据包采用低延迟路线，并避免出现太多潜在的变化。
提交静态 DNS
我们建议买方始终向 Google 提交单个静态 DNS 结果，并依靠 Google 来处理流量传送。
以下是出价方的 DNS 服务器在尝试负载均衡或管理可用性时采用的两种常见做法：
- DNS 服务器会在响应查询时分配一个地址或地址子集，然后以某种方式循环使用此响应。
- DNS 服务器始终会使用同一组地址进行响应，但会循环响应中的地址顺序。
第一种方法在负载均衡方面表现不佳，因为堆栈的多个级别都有很多缓存，而且由于 Google 会向出价方收取 DNS 解析时间费用，因此尝试绕过缓存可能也不会获得首选结果。
第二种方法完全无法实现负载均衡 系统从 DNS 响应列表中随机选择一个 IP 地址，因此 也没关系。
如果出价方更改 DNS，Google 将遵循其 DNS 记录中设置的 TTL（存留时间），但刷新间隔时间仍不确定。