在GAE中实现一致的响应时间？

Question

对我的应用程序运行负载测试时，我看到非常一致的响应时间。一旦GAE的负载水平恒定，平均响应时间就越来越小。 但我想在其他应用程序上获得相同的一致性，这些应用程序每秒接收的请求数量要少得多。在那些我永远不需要支持超过约3个请求/秒。

Reading the docs让我觉得增加最小空闲实例的数量会导致更一致的响应时间。但即使这样，每次GAE的调度程序认为需要更多实例时，客户端仍然会看到更高的响应时间。我正在寻找一个用户看不到那些初始缓慢请求的设置。

当我将最小空闲实例数增加到1时，我希望GAE仅使用一个常驻实例。随着负载的增加，它应该启动并预热新的（动态）实例。 Only once they are warmed up，GAE应向他们发送请求。 但从响应时间来看，似乎客户端请求在动态实例中随着它们的出现而到达。因此，这些请求需要很长时间（最多30秒）。

• 如果我的预热代码不完整会发生这种情况吗？
• 对动态实例的第一次调用是否会如此缓慢，因为它们涉及尚未预热的代码路径？

在负载测试期间或当有足够多的人使用该应用时，我没有遇到此问题。但是当我没有人使用应用程序时，我的测试环境几乎无法被客户端使用，例如在早上。

谢谢！

Answer 1

一些通用的想法：

• 30秒实例的启动时间似乎非常多。我们做了很多初始化（包括数据库命中），我们有大约5秒的开销。
• 热身 - 请求无法保证。如果所有实例都忙，并且调度程序认为如果启动新实例而不是在繁忙的实例上对其进行排队，则会更快地回答请求，它将执行此操作 没有浪费时间进行预热 - 请求
• 我不认为这是一个冷代码路径的问题（虽然我不详细了解java的热点），它可能是需要先填充的（mem-）缓存
• 我不知道你对“不完整的热身代码”是什么意思;只需检查您的日志中是否有/ _ah / warmup请求 - 如果有，请启用热身请求并正常工作。
• 增加超出1实例标记的空闲实例数量可能对此没有帮助。

可悲的是，没有任何通用技巧可以避免这种情况，但你可以尝试

• 推迟初始化代码（仅执行实例启动开销的绝对必需最小值）
• 启动后端保持（mem-）缓存热

如果您不介意成本（并且不需要为小批量应用程序自动扩展），您甚至可以通过永远在线的后端提供所有请求