问题标签 [google-cloud-tasks]

DEADLINE_EXCEEDED从 Node.js 客户端向 Google Cloud Tasks 添加任务时，我偶尔会遇到一个错误。我只尝试在 for 循环中添加 17 个任务。不知道为什么偶尔会发生这种情况，有时效果很好！

这是详细的错误日志：

我以为我达到了一些配额。但在检查时，它们都没有超过。

这是我创建队列的方式（更新插入）：

这是我添加任务的方式：

我正在使用 Cloud Task 队列在 App Engine Python 3 中创建一个新服务。该项目已经有一个使用 python 2 并在queue.yaml文件中声明队列的服务。

根据文档，我无法混合使用queue.yamlCloud Tasks API 创建队列，因此我将为新服务创建另一个 yaml 文件。

我的问题是新的queue.yaml是否会覆盖现有的队列，或者我可以为每个服务声明不同的队列。

我正在尝试使用 HTTP Target 实现 Google Cloud Task 队列。我已经为 App Engine 使用了队列，但在迁移到 Cloud Run 时，我希望使用相同的队列系统。我已经实现了调度程序代码，但与 App Engine 不同，我不能信任标头，所以我知道我需要使用身份验证令牌验证请求，但我很难理解它？我也在做很多假设。我正在尝试在 PHP 中构建它，因此如果可能的话，最好在 PHP 中查看一个示例，但即使只是流程的一些 Psuedo 代码也会很有用。

我的第一个假设是最好使用 OIDC 令牌？基于：

如果您在目标服务中编写自己的代码来验证令牌，则应使用 OIDC 令牌。有关这意味着什么的更多信息，请参阅 OpenID Connect，尤其是验证 ID 令牌。

我已经阅读了这个链接的标题，但如果我说实话，它并没有让我很清楚。

其次，令牌将在 Authorization 标头中为Bearer <token>？

第三，我想我应该使用类似包的东西firebase/php-jwt来解码令牌。但是我该如何准确解码呢？我的服务 JSON 文件只有一个私钥，我需要从云控制台获取公钥吗？一旦我这样做了，我需要查看令牌的特定部分来验证请求吗？还是我可以将其解码为有效的 JSON 就足够了？

每次我阅读一些关于如何做到这一点的文档时，我想我越来越接近答案了，但我现在花费的时间比我想要的要长得多，而且当谷歌文档似乎很少只是指出我需要做什么。

我正在尝试使用 Cloud Run（完全托管）和 Cloud Tasks，并且在延迟方面看到了奇怪的结果。

我在 Cloud Tasks 中有一个调用 Cloud Run 中的 API 的队列。使用以下值创建任务：

我尝试了许多队列配置，结果相同。

Cloud Run 是一个处理请求（没什么花哨的）并返回响应的 python 服务器。

问题是来自队列的请求的延迟非常高（约 15 分钟），但是如果我卷曲端点curl https://<app>.run.app/<endpoint>，它只需要几秒钟。

15分钟。是我为Cloud Run 的请求延迟得到的值，它不包括队列中的延迟。

我也在已知问题中发现了这一点，但它指的是我没有使用的自定义域，所以我不确定这是同一个问题。

有没有人遇到过（并希望解决）类似的事情？我可能做错了什么？

我已经建立了一个谷歌云任务队列并发送了数千个任务。我已经修改了设置，但没有什么让它变得更快。

该任务是对我的应用引擎服务器的简单 POST 请求，它会在 10 秒内返回。

我尝试在 App Engine 中添加更多目标服务器，但显然这不是问题，因为如果我直接调用我的目标服务器，它会在 10 秒内处理超过 40-50 个请求......但队列似乎每分钟只处理5-10个。

检查应用引擎服务器未充分利用，20% 的 CPU，非常低的内存，非常低的流量，因此它显然没有从队列中获得应有的任务。

那么如何才能让任务分派得更快呢？

我的队列 yaml 具有最新设置。我已经尝试了它的许多变体...

我们构建了一个严重依赖谷歌云任务的应用程序，但随着我们用户群的增加，我们正在将 100 个云任务排入队列。虽然 99% 以上的任务被正确执行，但很少有任务会消失。

这是一个非常奇怪的问题。没有原木会增加伤害。我在我的应用程序中添加了自定义日志以打印任务名称。

我的应用程序 A --> 创建云任务 --> 调用另一个应用程序 B

A 成功创建 CT，但 B 仅收到 99%+ 的任务，而不是 100%。

例如这个问题：locations/asia-south1/queues/tpl-pending/tasks/88947425534926389671

我们正在使用 Cloud Tasks 调用“本地”API 网关（使用 Http 请求）。这个 API 网关 (IBM API Connect) 位于本地系统 (Oracle) 的前面。这个后端系统有时会很慢。>5s。

我们拼命尝试增加吞吐量，但“调整”云任务队列设置（如 -max-dispatches-per-second 等）。 gcloud tasks queues update queue-1 --max-dispatches-per-second=8 --max-concurrent-dispatches=16

但是，当我们“启动”云任务设置时，我们看到的只是那个黄色三角形告诉我们，由于“系统资源”，我们被“强制”降低了速率。

我的理解是，黄色三角形的出现是由于我们调用的 API 网关的“错误”。基本上，GCP/Cloud Tasks 根据来自我们正在调用的 API 端点的返回码/错误/超时/延迟等“自行”重新行动，结果是速率/直通率非常低。这种理解正确吗？有人可以验证吗？

GUI 确实说“或者因为当前没有可用于执行请求的实例”。他们在谈论什么实例？所以对我来说，这意味着有可能是“GCP 特定”资源出现在这里并对“强制执行率”产生影响？或者？

无论如何，任何帮助/见解将不胜感激。

谢谢

我创建了一个谷歌云任务，队列不断重试，该函数也没有被调用。

这是来自云控制台的日志。

云任务说：

App Engine 强制执行的处理速率低于此队列的最大速率，这可能是因为您的应用程序正在返回 HTTP 503 代码，或者是因为当前没有可用于执行请求的实例。

但是，我使用 HTTP POST 请求将任务转发到云函数，类似于本教程中概述的请求。我的日志中没有看到它转发到的云功能的任何 503。

我queue.yaml的是：

我们目前在一些虚拟机上使用 Rabbit MQ 和 Celery：

• 我们有一批要并行处理的任务（例如同时处理一些文件或对图像运行一些机器学习推理）
• 批处理完成后，我们回调我们的应用程序，获取结果并启动其他批处理任务，这些任务可能取决于先前执行任务的结果

所以我们有要求：

• 我们的应用需要知道批次何时完成
• 我们的应用需要跨批次收集的任务结果
• 当我们在每个成功的任务中对应用程序进行回调时，它可能会杀死应用程序

现在我们尝试使用谷歌云来实现这一点，我们希望从虚拟机转移到谷歌云任务或发布/订阅与谷歌云功能相结合的东西。是否有针对我们在 Google Cloud 中的问题的最佳实践设置？