0

我们有两个 cron 作业，它们遇到了两个不同的动态后端，并且都遇到了同样的问题。我可以通过导航到 cron 作业直接在浏览器中执行的 URL 来复制问题。

我们的应用程序的冷启动时间相当长。当我导航到使用后端的 URL 时，我看到以下错误

Error: Server Error
The service you requested is not available yet.

Please try again in 30 seconds.

在日志中，我看到后端的 /_ah/start 请求（我们没有特定的处理程序）并带有以下消息：

 This request caused a new process to be started for your application, and thus caused your application code to be loaded for the first time. This request may thus take longer and use more CPU than a typical request for your application.

然后我所做的是刷新后端 URL，它工作正常。

所以我的理论是，如果后端已经加载，cron 作业可以正常工作。如果不是，它不会等待足够长的时间来查看后端是否会加载。

假设这是正确的，有没有办法让 cron 作业等到 /_ah/start 完成？

另外两个选项是使用我们不想做的常驻实例，或者改善我们的冷启动时间，这在待办事项列表中但直到现在对我们来说还不是问题（我们使用常驻实例作为前端）。

后端是B1。假设我们可以升级它，但作为一家资金紧张的初创公司，我宁愿不升级。

4

2 回答 2

3

Cron 没有 taskqueue 所具有的重试功能，因此我建议使用前端 cron 以便将任务放入具有动态后端实例的任务队列中。这样，cron 请求本身将由空置的前端实例处理，这比您现在所做的更可靠，并且在失败时将重试您的后端任务执行。

为了使第一个 cron 调用更健壮，您可以为一个特定的后端任务多次发出 cron 请求，并在放置任务时，将任务命名为与特定任务相关联的名称（例如 20120430-task1 或其他名称），捕获任务的错误重复（并且在 catch 子句中除了记录之外什么都不做）。

有关命名任务的更多详细信息，请参阅： https ://developers.google.com/appengine/docs/java/taskqueue/overview#Task_Names

于 2012-04-29T12:58:37.887 回答
0

我用来确保后端在线并准备就绪的一个方便技巧是在你的工作 cron 之前 30 秒安排一个不做任何事情的 cron。no-op 请求失败或成功都没有关系，它会在重要的 cron 之前预热你的后端。

关于错误代码 503 的另一个说明 - 如果您处理不存在的后端实例编号，有时会发生这种情况。检查任务标头以确保后端主机是 0.yourbackend.yourapp.appspot.com，或者 # 是 < 分配的后端总数。

于 2012-04-29T18:06:41.580 回答