我们根据平均响应时间超过 3 秒的情况自动扩展 Elastic Beanstalk Java 应用程序。发生这种情况时，我们会向环境中添加 2 个实例。一旦平均响应时间回到 1.5 秒以内，我们就会减少 1 个实例，并采用 300 秒的冷却策略。
我们的新终端预计大约需要60 秒做出回应，这有点破坏了我们的自动缩放模型，因为平均值现在会严重偏差。
我们最初的目标是检测端点何时遇到延迟（我们调用第三方 API 并代理其结果 - 因此任何延迟都是因为第三方超时或花费的时间比计划的要长）。到目前为止，自动扩展效果很好。
当我们引入长期运行的请求时，我们有哪些可用的选项？
我们是否应该考虑根据请求子集的延迟以编程方式增加和减少实例数量，例如端点 a 和端点 b 的平均延迟为 3 秒，但端点 C 的平均延迟为 70 秒？
我们可以假设，如果 10％ 的用户使用 60 秒端点，而其他 90％ 的用户使用 1-2 秒端点，那么我们可以尝试将平均值设置得更高作为折衷方案，但是，我担心这意味着我们无法足够早地扩展某些端点。
谢谢，
抢。
答案1
您是否考虑过建立一个新的自动缩放组？
您的统计方法/思维很好，但会影响原组中一定比例的请求。最好将新组分开。