Tracking issue - GraphQL performance (Slow or poor relation performance)

[derrickmehaffy]

Describe the bug

This is a tracking issue for all the various issues related to GraphQL performance as compared to REST or just in general poor relational performance

Context

Currently GraphQL is performance very un-optimized on model entries that have quite a lot of relations or a very complex relational structure. This is not what we intended as GraphQL itself and the query system implemented should provide a much faster response as compared to something like REST, as the goal of GraphQL is to be faster however with a higher degree of control.

Current behavior

(Taken from the OP of: #5182 but see linked issues for more current behavior)

I've noticed some slow performance whenever the amount of relations started growing of an entry. I thought the fix mentioned in #4080 already fixed this, but after some testing, I've come up with the following results (same query/same output fields):

REST: 110-120ms
GraphQL: 900-910ms

That's a big difference. After reading the original issue, I started to dig through the graphql plugin and started fiddling with the populate settings on line 155 in services/Loader.js (as already mentioned in the original post). Setting the populate to a hard coded [] results in a huge boost:

GraphQL: 120-140ms

The funny thing here is, the fields that originally are populated in the params, are still queryable after setting the populate to [].
However, this does not seem to have effect when deep filtering. I not sure why, but i'll try to figure that out sometime this week.

Expected behavior

GraphQL performance should be significantly faster than REST in many different use cases. Or at the very least, performance wise, in line with our REST implementation.

Related Issues, Feature requests, Discussions, and Forum threads

Please note, the below are not the limit and additional entries may be linked to this issue, you can find them referenced in the comments.

• GraphQL is acting really slow compared to REST #5182
• GraphQL is acting really slow compared to REST #4080
• GraphQL queries are extremely slow, they always populate automatically all relations #8535
• Unnecessary join queries on many-to-many relations cause performanse issue in large datbase. #5363
• High GraphQL response time query images relations #3552

More will be added as needed

Possible workarounds depending on the use case

None currently known other than to avoid usage of GraphQL in favor of REST

[derrickmehaffy]

This issue has been mentioned on Strapi Community. There might be relevant details there:

https://forum.strapi.io/t/trying-to-understand-how-graphql-plugin-works/1078/2

[xarvel]

Any news ?

[derrickmehaffy]

@xarvel it's going to take some time for us to address this probably and most likley won't happen until Q1 2021

[jwerle]

@xarvel to improve performance, we've introduced graphql-jit as an executor for Apollo, rewrote how the dataloaders initialize and work in a request contexts, removed "dominant": true from all model attributes, overload how components are loaded in resolvers, and introduced a cache with Apollo. We still see higher latency with GraphQL compared to REST, but the average request latency has dropped with these changes. We believe the root of our issues comes from the has many and belongs to many relationship between models, but we are still actively auditing.

This was a lot of guessing with trial/error over time 🤷‍♂️