我知道GAE调度程序是审查和关注的主题。我也知道这对于我的应用程序的性能至关重要。我在上周花费了优化和分析我的应用程序。
我还了解，调度程序旨在在应用程序大小的整个范围内工作，并且根据并发用户而言，该算法可能不会针对我相对较小的规模应用程序进行优化。
我相信以下对待处理延迟的描述是错误的，这导致了不可避免的延迟：
等待延迟滑块控制了在 在由默认的实例提供之前，等待队列 您的应用程序的版本。如果最低待处理延迟很高 应用引擎将允许请求等待而不是启动新实例 处理它们。这可以减少实例小时数 应用程序用途，但可能会导致更多的用户可见延迟。
如何在我以串行中执行10个请求（启用mutli-threading）的待处理延迟15秒和2个空闲实例的情况下，它会旋转新实例？
我为什么要关心？我只能将所有的Intialation放在热身代码中？错误的。我正在使用JDO使用GAE/J。看来，每个实例第一次击中实体类型时，它首次引起了几秒钟的"验证"开销。在大多数情况下，除非您将JDO登录到信息级别，否则您甚至都不知道这是在发生这种情况。
我的问题是：
是否有人经历了与调度程序行为有关的以下情况及其与DS初始化的互动，如果是的话，您是否可以提出解决方案，以避免产生此类延迟？
具体来说，情况是：
- 使用JDO-每次新实例"触摸"实体类型首次引起初始化开销（如果您有疑问，请将JDO记录级别设置为信息）。这个开销的订单为2-3秒
- 由于这个开销而增加了延迟，再加上调度程序显然忽略了待处理的延迟参数，这意味着它更有可能旋转新实例，而不是计算现有实例可以处理请求。
- 由于新请求是由新实例处理的，因此上述初始化开销。因此，恶性循环永存。
请注意，我已经考虑了以下补救措施：
- 迁移到冬眠或类似 - 一项巨大的工作和不清楚是否会解决问题。
- 修改我的应用程序体系结构以使用后端来提供所有DB功能，因为我至少可以控制我运行的数量等等。
- 也许我缺少一些JDO配置，只能避免上述开销？
是的，当您首次访问它时，JDO会导致延迟。这是由于要求实施的JDO规格能够提供只能通过内省DB收集的信息；即使您不想要这些信息，它仍然必须收集。我的建议，就像在应用程序引擎上使用Java的任何人一样，是不使用JDO-使用更适合App Engine的东西，例如Objectify。
不太可能导致新实例在您的情况下启动新实例。最可能的是最小的闲置实例；如果这大于0，则一旦实例被请求占据，调度程序将额外旋转。