【发布时间】:2012-10-29 19:42:10
【问题描述】:
我知道 GAE 调度程序是备受关注和关注的对象。我也知道这对我的应用程序的性能至关重要。上周我一直在优化和分析我的应用程序。
我还了解,调度程序设计用于在各种应用程序大小范围内工作,就并发用户而言,该算法可能不会针对我相对较小规模的应用程序进行优化。
我认为以下对待处理延迟的描述是错误的,这会导致不可避免的延迟:
Pending Latency 滑块控制请求在 在由默认实例提供服务之前的挂起队列 您的应用程序的版本。如果最小挂起延迟很高 App Engine 将允许请求等待而不是启动新实例 来处理它们。这可以减少您的实例小时数 应用程序使用,但可能导致更多用户可见的延迟。
当我以 15 秒的等待延迟和 2 个空闲实例连续执行 10 个请求时,所有请求都需要 1-3 秒(启用多线程),它怎么可能会旋转起来?新实例?
我为什么要关心?我可以把我所有的初始化都放在我的热身代码中吗?错误的。我正在将 GAE/J 与 JDO 一起使用。似乎每个实例第一次遇到实体类型时,它第一次会产生几秒钟的“验证”开销。大多数情况下,除非您将 JDO 日志记录设置为 INFO 级别,否则您甚至不会知道正在发生这种情况。
我的问题如下:
是否有其他人经历过以下与调度程序行为及其与 DS 初始化的交互有关的情况,如果是,您能否提出解决方案,以便我避免出现此类延迟?
具体情况是:
- 使用 JDO - 每次新实例第一次“接触”实体类型时,都会产生初始化开销(如果您有疑问,请将 JDO 日志记录级别设置为 INFO)。此开销约为 2-3 秒
- 此开销导致延迟增加,加上调度程序明显忽略 Pending Latency 参数这一事实意味着它更有可能启动新实例,而不是计算现有实例可以处理请求。
- 因为新请求正在由新实例处理,所以上述初始化开销是重复的。恶性循环就这样延续下去了。
请注意,我已经考虑过以下补救措施:
- 迁移到休眠或类似模式 - 一项艰巨的任务,尚不清楚它是否能解决问题。
- 修改我的应用程序架构以使用后端来提供所有数据库功能,因为至少我可以控制我正在运行的数量等。
- 也许我遗漏了一些 JDO 配置,可以简单地避免上述开销?
【问题讨论】:
-
能否请您指出,您的问题到底是什么?
-
嗨 Pavel,是的,很公平,我没有问清楚的问题,我会编辑。
-
嗨,doright,我认为如果您专注于寻求解决方案,而不是简单地试图让其他人确认问题存在,那么您的问题可能会更有用。确认它的存在并不能真正帮助解决问题,但我认为通过edit 回答您的问题,这可能对面临相同问题的其他 Java App Engine 开发人员有用。希望这可以帮助!祝你好运! :)
-
感谢jmort253,再次更新。
标签: google-app-engine google-cloud-datastore