时间戳

首页 > 解决方案 > 长期承诺是否会导致 NodeJS 应用程序无法通过就绪检查？

node.js - 长期承诺是否会导致 NodeJS 应用程序无法通过就绪检查？

问题描述

我目前有一个异步功能，需要大约 7 分钟才能完成。它在 localhost 节点服务器上运行良好，但在大约 6 分钟后无法在 Google App Engine 上进行就绪检查并导致应用重新启动（就绪检查时出现 503 状态）。

函数的结构是这样的：

await Promise.all(customers.map(customer => recursivelyDownloadProfiles(someRequestParams)));

const recursivelyDownloadProfiles = (request, profiles = []) =>
    downloadProfilesAndReturnNextPage(request).then(
        ([nextRequest, moreProfiles]) => {
            const allProfiles = [...profiles, ...moreProfiles];
            if (!nextRequest) {
                return allProfiles;
            }
            return recursivelyDownloadProfiles(nextRequest, allProfiles);
        }
    );

下载的每个页面都有 5 秒的“睡眠”超时，以保持在 API 配额内。

我试图理解这个问题 - 这是“非阻塞”代码吗？所以即使我的递归是无限的（它不是），为什么准备检查失败了？

更新

查看就绪检查日志，他们在每次迭代中发送 200 个，直到大约 6 分钟后，然后他们开始在某个迭代中失败。与阻止就绪检查的 http 请求有关吗？

标签： node.jsgoogle-app-engineasynchronousgoogle-cloud-platform

解决方案

我重新访问了这个打开的错误并找到了答案：这是我的实例上的内存不足错误。结果证明，配置文件的递归下载已达到 1.25GB 的 RAM，并且每次实例都关闭。

在使用日志记录排除 TIMEDOUT 请求后，我转到应用引擎控制台并找到了这个有说服力的图表： 内存配置文件

当然，这不是我个人机器上的问题。

通过在我的本地机器上记录我的数组大小（以字节为单位）来确认这一点。

解决方案 这只是在从 3rd 方 API 下载分页结果时过度使用了扩展运算符。而不是使用超过 80 页的const cumulativeProfiles = [...cumulativeProfiles, ...newlyDownloadedProfiles]I used cumulativeProfiles.push(newlyDownloadedProfiles)，会产生巨大的内存差异

推荐阅读