performance - 使用 nestjs 和 graphql 调查响应序列化的性能

Question

我正在研究 nodejs 后端中序列化的性能问题。我想要一些关于在服务中的应用程序逻辑返回其响应之后如何调查发生的事情的建议。

目前有一个使用 typeorm 执行的错误查询，它返回大约 12000 行。这个查询的速度不是问题，但是从服务返回结果时，api真正返回响应大约需要100秒。该应用程序使用带有 graphql 的 nestjs 作为 api。

我猜想在 apollo 服务器或在 nestjs 中完成了一些繁重的序列化。我该如何进一步调查？数据库查询的大尺寸是这里唯一的问题，还是其他问题？

这里真正的问题是这会阻塞 nodejs 的事件循环大约 100 秒，这会冻结整个后端。

标签： performancenestjsapollo-server

Answer 1

通过控制台日志调试，我发现 typeorm 不是问题。大多数时间没有花在 typeorm 上，甚至没有花在服务或解析器上。大部分时间都花在了解析器返回后的某个地方，这让我想到了阿波罗服务器本身。

当尝试从相同的服务返回但使用常规的休息控制器时，只需要大约一秒钟。我最终做的是在解析器中的响应数据上使用 JSON.stringify，然后将 graphql 响应输入为字符串。对于这种特殊情况，这很好，因为无论如何数据都与系统的其余部分完全隔离。

问题可能出在验证返回数据类型的阿波罗服务器部分，但这主要是猜测。