我正在研究 nodejs 后端中序列化的性能问题。我想要一些关于在服务中的应用逻辑返回其响应后如何调查发生的事情的建议。
目前有一个使用 typeorm 执行的错误查询，它返回大约 12000 行。这个查询的速度不是问题，但是当服务返回结果时，api真正返回响应大约需要100秒。该应用程序正在使用带有 graphql 作为 api 的 nestjs。
我猜在 apollo 服务器或在 nestjs 中完成了一些繁重的序列化。我该如何进一步调查？数据库查询的大尺寸是这里唯一的问题，还是其他问题？
这里真正的问题是，这会阻塞 nodejs 的事件循环大约 100 秒，从而冻结整个后端。
【问题讨论】：
标签： performance nestjs apollo-server
通过控制台日志调试，我发现 typeorm 不是问题。大多数时间没有花在 typeorm 上，甚至没有花在服务或解析器上。大部分时间都花在了解析器返回后的某个地方，这让我想到了阿波罗服务器本身。
当尝试从同一个服务返回但使用常规的休息控制器时，只需要大约一秒钟。我最终做的是在解析器中的响应数据上使用 JSON.stringify，然后将 graphql 响应输入为字符串。对于这种特殊情况，这很好，因为无论如何数据都与系统的其余部分完全隔离。
问题可能出在验证返回数据类型的阿波罗服务器部分，但这主要是猜测。
【讨论】：
您确定正在执行的实际查询只返回 12000 行，还是 12000 行只是 API 最终返回的数字？
您很可能会向 NestJS 后端返回更多行，然后需要将这些行标准化为您从 API 收到的实际结果集。如果您要进行大量连接，这是一个容易遇到的问题，并且与 Object-relational impedance mismatch 的概念有关。
过去我遇到过类似的问题，我的 API 结果集仅返回几千行，但超过 40 万行被发送回 TypeORM，TypeORM 然后必须适当地展平它们并导致您的确切性能问题又遇到了。
我强烈建议您检查生成的 SQL 以查找有问题的查询，然后在数据库上手动运行它以查看实际返回的行数。
【讨论】：