本指南介绍了根据 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%，我们将开始节流。与“对所有请求做出响应”的出价方不同，此类出价方会“减少损失”，从而能够在请求率下降时立即恢复。在过载期间，此出价方的延迟时间图表类似于浅锯齿形模式，在可接受的最大速率附近局部化。
- “在超载时不出价”出价方
此出价方接受的宣传信息数量上限为一定比例，然后会针对任何超载情况返回“无出价”响应。与“error on overload”出价方类似，此功能可通过多种方式实现。不同之处在于，系统不会向 Google 返回任何信号，因此我们不会限制宣传信息的展示次数。前端机器会吸收过载，并且只允许其能够处理的流量继续传递到后端。
此出价方的延迟时间图表显示了一个平台，该平台在高峰时段（人为地）停止与请求速率保持一致，并且包含出价的响应比例相应下降。
我们建议您将“超载时出错”与“超载时不出价”方法结合使用，具体方法如下：
- 过度预配前端并将其设置为在过载时出错，以最大限度地提高它们能够以某种方式响应的连接数量。
- 当发生过载错误时，前端机器可以使用预先创建的“不出价”响应，而无需解析请求。
- 实现后端的健康检查，以便如果没有任何后端有足够的容量可用，则返回“不出价”响应。
这样可以吸收部分过载，并让后端有机会仅响应其能够处理的请求数量。您可以将其视为“过载时不出价”，当请求数量明显高于预期时，前端机器会回退到“过载时出错”。
如果您使用的是“对所有请求做出响应”出价方，不妨考虑通过调整连接行为将其转换为“出现过载时出错”出价方，以便其实际上拒绝过载。虽然这会导致返回更多错误，但可以减少超时，并防止服务器进入无法响应任何请求的状态。
考虑对等互连
减少网络延迟或不稳定性的另一种方法是与 Google 对等互连。对等连接有助于优化流量到达出价方的路径。连接端点保持不变，但中间链接会发生变化。如需了解详情，请参阅对等连接指南。将对等连接视为最佳实践的原因可总结如下：
在互联网上，传输链路主要通过“热土豆”式路由进行选择，该路由会查找 Google 网络之外最靠近且能够将数据包传送到目的地的链路，并通过该链路路由数据包。如果流量穿过与我们有许多对等连接的提供商拥有的骨干网段，则所选链接可能位于数据包起点附近。在此之后，我们无法控制数据包到达出价方的路线，因此它可能会在途中跳转到其他自治系统（网络）。
相比之下，如果存在直接对等协议，数据包始终会通过对等链接发送。无论数据包的来源为何，它都会穿越 Google 拥有或租用的链路，直到到达共享对等点（应靠近出价方位置）。在返回行程中，系统会先跳转到 Google 网络，然后在剩余路程中一直在 Google 网络上。让大部分路程都在 Google 管理的基础架构上运行，可确保数据包采用低延迟路线，并避免出现太多潜在的变化。
提交静态 DNS
我们建议买方始终向 Google 提交单个静态 DNS 结果，并依靠 Google 来处理流量传送。
以下是出价方的 DNS 服务器在尝试负载均衡或管理可用性时采用的两种常见做法：
- DNS 服务器会在响应查询时分配一个地址或地址子集，然后以某种方式循环使用此响应。
- DNS 服务器始终会使用同一组地址进行响应，但会循环响应中的地址顺序。
第一种方法在负载均衡方面表现不佳，因为堆栈的多个级别都有很多缓存，并且由于 Google 会向出价方收取 DNS 解析时间费用，因此尝试绕过缓存可能也不会获得首选结果。
第二种方法根本无法实现负载均衡，因为 Google 会从 DNS 响应列表中随机选择 IP 地址，因此响应中的顺序无关紧要。
如果出价方更改 DNS，Google 将遵循其 DNS 记录中设置的 TTL（存留时间），但刷新间隔时间仍不确定。