2

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

阅读文档让我认为增加最小空闲实例的数量应该会导致更一致的响应时间。但即便如此，客户端仍然会看到更长的响应时间，每次 GAE 的调度程序认为需要更多实例时。我正在寻找用户看不到那些初始缓慢请求的设置。

当我将最小空闲实例数增加到 1 时，我希望 GAE 仅使用一个常驻实例。随着负载的增加，它应该启动并预热新的（动态）实例。只有在它们预热后，GAE 才会向它们发送请求。但是从响应时间来看，似乎客户端请求在被提出时以动态实例的形式到达。因此，这些请求需要很长时间（最多 30 秒）。

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

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

谢谢！

4

1 回答 1

1

一些通用的想法：

  • 实例的 30 秒启动时间似乎非常多。我们做了很多初始化（包括数据库命中），我们有大约 5 秒的开销。
  • 不保证预热请求。如果所有实例都忙，并且调度程序认为如果它启动一个新实例而不是在一个忙的实例上排队，请求将得到更快的响应，它会这样做而不会浪费时间进行预热请求
  • 我不认为这是冷代码路径的问题（尽管我不详细了解java的热点），它可能是需要先填充的（mem-）缓存
  • 我不知道您所说的“不完整的预热代码”是什么意思；只需检查您的日志以获取对 /_ah/warmup 的请求 - 如果有的话，预热请求已启用并正在工作。
  • 将空闲实例的数量增加到超过 1 个实例标记可能在这里无济于事。

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

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

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

于 2013-02-27T16:23:20.903 回答