实时出价应用最佳实践

本指南介绍开发应用时应考虑的最佳做法 。

管理连接

使连接保持活动状态

建立新连接会增加延迟时间，并且所需时间会更长 而不是重复使用现有资源减少关闭次数 您可以减少必须打开的连接数 。

首先，每个新连接都需要额外的网络往返 确定。由于我们是按需建立连接，因此 有效期限较短，更有可能超时 后续请求。任何额外的超时都会增加错误率，从而导致 您的出价工具受到限制

其次，许多网络服务器会为每个连接生成专用的 。这意味着要关闭并重新创建连接，服务器 必须关闭并舍弃线程，分配新的线程，使其处于就绪状态， 构建连接状态，然后再最终处理请求。相当多 不必要的开销

避免关闭连接

首先调整连接行为。大多数服务器默认值都是针对 具有大量客户端的环境，每个环境 请求。对于实时出价，相比之下，少量机器会在 代表大量浏览器。在这些 那么应尽可能多次重复使用连接周三 建议您设置：

• 空闲超时设置为 2.5 分钟。
• 连接到最高 可能的值。
• 连接数上限（达到您的 RAM 可允许的最高值） 同时注意确认连接的数量 也不要过于接近这个值

以 Apache 为例，这需要设置 KeepAliveTimeout 至 150，MaxKeepAliveRequests 至 零，并将 MaxClients 设置为取决于服务器类型的值。

调整连接行为后，您还应确保 出价工具代码不会不必要地关闭连接。例如，如果你的 返回默认的“无出价”的前端代码发生后端事件时响应 遇到错误或超时，请确保代码返回其响应而不关闭 连接。这样可以避免您的出价工具 过载，连接开始关闭，超时次数增加， 会导致您的出价工具受到限制

保持连接均衡

如果 Authorized Buyers 连接到出价方的服务器 则连接可能会随着时间的推移而变得不平衡 因为只知道代理服务器的 IP 地址 无法确定在哪个出价工具服务器收到每条出价邀约。 随着时间的推移 连接数和出价工具的服务器重启时， 都可能会变得很大变化。

当某些连接被频繁使用时，其他打开的连接可能 大部分都处于空闲状态，因为此时不需要。如 Authorized Buyers 流量发生变化，空闲连接可能会变为活跃状态 就会进入空闲状态这可能会导致您的出价工具服务器上的负载不均衡 Google 会通过以下方式来防止 在 10,000 个请求后关闭所有连接，以自动重新平衡热量 连接数。如果您仍然发现 您可以采取进一步的措施：

1. 请为每个请求选择后端，而不是为每个连接选择一次 请使用前端代理
2. 指定每个连接的最大请求数 代理连接（通过硬件负载平衡器或防火墙）， 一旦建立连接，映射就会固定下来。请注意， 已指定每个连接 10,000 个请求的上限 则仅当您发现商品价格仍然较高时，才需要提供更严格的值 您的环境中的这些连接将变成集群例如，在 Apache 中 将 MaxKeepAliveRequests 设置为 5,000
3. 配置出价方的服务器以监控其请求率并完成部分请求率 处理自己的连接数 （与类似应用相比）。

妥善处理过载

理想情况下，配额应该设置得足够高，这样您的出价工具就可以收到 但仅能处理这些请求实际上，将配额控制在 最佳级别是一项艰巨的任务，并且会针对各种不同类别 原因包括：后端在高峰时段关闭、流量组合发生变化 或者只设置了一个配额值 过高。因此，请务必仔细考虑您的出价工具 就会出现过多的流量

为了适应临时性的交通调整（最长一周） （尤其是亚洲和美国西部与美国东西/美国之间）， 我们建议在 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

"id": "4YB27BCXimH5g7wB39nd3t"

id: "7xd2P2M7K32d7F7Y50p631"

请注意，与您的预期相反，ping 请求并不包含 广告位。而且，如上面所述，您不能在响应 ping 请求后关闭连接。

考虑对等互联

减少网络延迟或变化的另一种方法是与 Google 对等互连。 对等互连有助于优化流量到达您的出价工具所采取的路径。通过 连接端点保持不变，但中间链接发生变化。请参阅 如需了解详情，请参阅对等互连指南。通过 将对等互连视为一种最佳实践的理由可以总结如下：

• 在互联网上，公交链接主要通过“土豆红”进行选择 路由”该功能可找到离我们 网络以外的距离最近的链接， 数据包发送到其目的地，并通过该链接路由数据包。时间 流量会经过与我们合作的提供商拥有的骨干网部分， 对等连接，则所选链路可能靠近 开始发送数据包。在此之后，我们无法控制数据包的路由 因此可能会被退回到其他自治系统 （网络）。

• 相反，当存在直接对等互连协议时，数据包 始终通过对等互连链路发送无论数据包来自何处 遍历 Google 拥有或租赁的链接，直到找到共享 该对接点应靠近出价方位置。返程行程 从访问 Google 网络的短跃点开始， 和网络。让大部分行程都由 Google 管理 基础架构可确保数据包采用低延迟路由， 可能性很大。

提交静态 DNS

我们建议买方始终向 Google 提交一个静态 DNS 结果， 用于处理流量传输。

下面是出价工具的两种常见做法尝试加载时的 DNS 服务器 或管理可用性：

1. DNS 服务器发出一个地址或地址子集作为响应 然后以某种方式循环显示这个响应。
2. DNS 服务器始终返回同一组地址进行响应，但会循环 响应中的地址顺序。

第一种方法在负载均衡方面较差，因为 堆栈的多层，并且尝试绕过缓存 还可以得到首选的结果，因为 Google 将 DNS 解析时间收取到 出价工具。

第二种方法完全无法实现负载均衡 系统从 DNS 响应列表中随机选择一个 IP 地址，因此 也没关系。

如果出价方更改了 DNS 设置，Google 将遵循之前设置的 TTL（存留时间） 但刷新间隔仍不确定。