Agent Runtime 提供部署参数，让您可以优化和扩缩智能体的性能。通过配置这些参数，您可以有效地处理不可预测或突增的流量模式。
本页介绍了如何优化和扩缩 Agent Runtime 性能的最佳实践，涵盖以下场景：
这些场景展示了如何使用部署参数来解决常见的性能 瓶颈，尤其是在实际应用中不可预测的突增流量模式 。
冷启动问题
当请求到达时，如果没有空闲实例或容器来处理该请求，Agent Runtime 就会被迫启动一个新实例或容器，此时会发生 冷启动 。这会给请求增加显著的延迟时间。
例如，向具有默认 min_instances=1 的智能体发送 300 个并发请求可能会显示以下结果：
冷启动 （首次运行）：平均延迟时间约为 4.7 秒。
温启动 （立即第二次运行）：平均延迟时间约为 0.4 秒。
超过 4 秒的开销几乎完全是由于新实例启动以处理负载造成的。
请尝试以下方法来缓解冷启动问题：
设置足够高的
min_instances值，以处理基准流量。 例如，将min_instances=10设置为示例智能体可以将 冷启动的平均延迟时间缩短到大约 1.4 秒。对于流量突增或高流量的应用，请将min_instances设置为可以处理典型负载的值，而无需从 1 进行扩缩。最大值为 10。使用队列向 Agent Runtime 发送稳定、持续、可预测的负载。例如，在基于智能体开发套件 (ADK) 的智能体上运行持续负载测试 60 秒，每分钟 1,500 个查询（每秒 25 个查询），且
min_instances=10和默认concurrency(9) 可以产生以下结果：- 平均延迟时间始终较低，约为 1.6 秒。
稳定、持续的负载可使服务保持“温热”状态，并实现最佳性能。
异步工作器利用率不足
默认情况下，container_concurrency 配置用于同步代码，其中每个 Agent Platform 实例一次仅处理一个请求。
异步智能体（例如基于
智能体开发套件 (ADK)的智能体）可以同时处理多个
I/O 绑定请求（例如 LLM 或工具调用）。
例如，向具有 min_instances=10 和默认 container_concurrency=9 的基于 ADK 的智能体发送 300 个并发请求可能会产生以下结果：
- 虽然中位延迟时间约为 4 秒，但最大延迟时间会飙升至 60 秒。这表明在服务缓慢扩容时，请求会大量排队。
为了缓解异步工作器利用率不足的问题，请增加 container_concurrency，以允许每个 Agent Platform 实例处理多个请求。每个智能体进程可以处理的并发请求数是 container_concurrency / 9。值 9 表示每个容器中并行运行的智能体进程数。
例如，向具有 min_instances=10 和 container_concurrency=36 的同一基于 ADK 的智能体发送 300 个并发请求可能会产生以下结果：
- 最大延迟时间从 60 秒降至大约 7 秒。这表明现有实例可以更有效地吸收流量峰值。
对于异步智能体（例如基于 ADK 的智能体），请将 container_concurrency 设置为 9 的倍数（例如 36）作为起点。这可以提高对流量峰值的响应速度，并减少扩容带来的延迟。
请注意，将 container_concurrency 值设置得过高可能会导致内存不足 (OOM) 错误。