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