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) 的智能体上运行持续负载测试，以每分钟 1,500 个查询（每秒 25 个查询）的速率持续 60 秒，并使用
min_instances=10和默认concurrency(9)，可能会产生以下结果：- 平均延迟时间始终较低，约为 1.6 秒。
稳定、持续的负载可使服务保持暖状态，从而实现最佳性能。
利用率不足的异步工作器
默认情况下，container_concurrency 配置为同步代码，其中每个 Agent Platform 实例一次仅处理一个请求。基于智能体开发套件 (ADK) 的异步智能体可以同时处理多个 I/O 密集型请求（例如 LLM 或工具调用）。
例如，向基于 ADK 的代理发送 300 个并发请求（使用 min_instances=10 和默认 container_concurrency=9）可能会产生以下结果：
- 虽然延迟时间中位数约为 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) 错误。