CODEWITHSUNDEEP
performancenestjsapollo-server
rablentain
rablentain

Reputation: 6745

Investigate performance of response serialization with nestjs and graphql

I am looking into a performance issue with serialization in a nodejs backend. I would like some suggestions about how to investigate what is happening after that the app logic in the service has returned its response.

Currently there is a bad query executed with typeorm that returns about 12000 rows. The speed of this query is not a problem, but when the result is returned from the service, it takes about 100 seconds for the api to actually return the response. The application is using nestjs with graphql as api.

I guess that there is some heavy serialization done either in apollo server or in nestjs. How do I investigate this further? And is the large size of the database query the only issue here, or could it be something else?

The real problem here is that this is blocking the event loop of nodejs for about 100 seconds, which freezes the whole backend.

Upvotes: 1

Views: 1826

Answers (2)

rablentain
rablentain

Reputation: 6745

By console log debugging I discovered that typeorm was not the problem. The most time was not spent in typeorm, not even in the service or the resolver either. The most time was spent somewhere after the return of the resolver which lead me to think about apollo server itself.

When trying to return from the same service but using a regular rest controller instead, it only took about a second. What I ended up doing was to use JSON.stringify on the response data within the resolver and then just typed the graphql response as a string. For this particular case it was fine since the data was quite isolated from the rest of the system anyway.

The issue was probably within the part of apollo server which validates the typing of the returned data, but that is mostly a guess.

Upvotes: 2

Jesse Carter
Jesse Carter

Reputation: 21207

Are you sure that the actual query being executed is returning only 12000 rows, or is 12000 rows just the number that are eventually returned from the API?

It is very likely that you are returning many more rows to the NestJS backend which then need to be normalized into the actual result set you receive from the API. This is an easy problem to run into if you're doing a lot of joins and is related to the concept of Object-relational impedance mismatch.

In the past I had a similar problem where my result set from the API only returned a few thousand rows but over 400 thousand rows were sent back to TypeORM which then had to flatten them appropriately and caused the exact performance issue that you're running into.

I highly recommend that you check the generated SQL for the problematic query and then run it manually on the DB to see how many rows you actually get back.

Upvotes: 0

Related Questions