Performance advice

[steevhise]

I'm wondering in general if there are any resources out there for learning more about performance optimization with graphql-sequelize. I'm dealing with performance problems for an app that uses graphql-sequelize. Recently I added dataloader-sequelize but there continue to be some problems and it appears that a large part of it is occurring at the level of graphql or graphql-sequelize (rather than sql optimization, app-level code, etc, although there are some of those things to consider and we have). To illustrate one reason why I think that, attached is part of a timeline chart from an Elasticsearch-APM monitoring of the application. It shows basically one complete graphql query and basically it looks like all the sql query time included does not begin to add up to the total time of the graphql query.

So, I'm wondering what else is graphql or grapql-sequelize doing that's taking all that extra time, and more importantly, how can it be improved? Are there some kind of obvious global settings I may have not set correctly, or practices i may not be using, besides the aforementioned dataloader ? (the number of queries before I added that was indeed much much greater, so that's some improvement). And how can I force more joins so there are less sql queries?

thanks!

[mickhansen]

Usually in my own codebases i see a pretty linear relationship between query time and sql time, so i'm not quite sure what issue you're having here, you might have to start digging, if you can locate a specific codepath that's slow i could take a stab at optimizing it.

As for joins, you'd have to write that logic itself, imo graphql works best with dataloader where you have one query per level/Model.

[steevhise]

Thanks!
I just realized that codebase of mine is about 12 versions behind on the version of the graphql-js it's using! So my first task will have to be getting it to work with the newest...

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[ryanmcclure4]

@steevhise Did you ever track down what the issue was? I've been running into similar problems, with apm showing large spans of empty space with no indication of what's happening.

[steevhise]

@ryanmcclure4 not really - eventually what i did was start porting what seemed like the heaviest queries to pure sequelize and cut out graphql. ultimately i think we'll do that for our whole app. it just seems like there's too many layers and layers of promises and garbage collection and things need to be simplified. unless there's some real specific good reason (like putting multiple data sources under the hood of a public api or something), graphql seems like mostly an overhyped and counterproductive idea in general.

[steevhise]

oh but one thing to note: i did find out that at that time at least, elastic-apm-node itself caused some pretty noticeable performance issues because it uses async hooks, which is an experimental feature. now that it's a few versions later for both the module and node, i'm in the middle of trying apm again to see if we can use it now without terrible slowdowns (there's an option to turn off aysnc hooks within the module now). however, that's a tangent - APM wasnt the only reason for our performance problems..

[ryanmcclure4]

Gotcha, yeah at first elastic-apm-node added some insane performance issues to our app which took some tweaking to mitigate. I share your frustration with GraphQL - we've had good success with it overall but there are certainly cases with larger requests where it splits there query into a ridiculous amount of chunks, when a single query would be much more efficient.