Performance of ExecutionStrategy#completeField and ExecutionStrategy#fetchField
See original GitHub issueHi,
While testing our application for 1k data, in the JProfiler readings we see graphql parsing and processing is taking significantly more time than the DB layer.
Specifically two methods:
- graphql.execution.ExecutionStrategy#completeField
- graphql.execution.ExecutionStrategy#fetchField
*marked in blue is the Datafetcher implementation that looks up data from DB, taking 13.4% of the total execution time
Note: the output of DataFetchers is Map<String, Object>
- Query used for this call:
{
"query": "query searchEntities($scope: SearchScope!,$first: Int!,$sortBy: SortByField) {searchEntities(scope: $scope,first:$first,sortBy: $sortBy) {matchedEntities { activeEntity { name description } draftEntities{ description probableEntity{ description name createTime } }} pageInfo { endCursor hasNextPage } } } ",
"variables": {
"scope": {
"appIdentifier": "app1",
"nativeType": "nativeType1"
},
"first":1000,
"sortBy":{
"field":"UpdateTime",
"order":"Desc"
}
}
}
We are using graphql-java version : 14.0. Also attaching graphql schema. EntityApi.graphql.txt
- looking up 65k records, total Graphql execution took about 228s
where actual DB lookup took ~22s only
Question is : What factors contribute to graphql processing overhead? Are there any best practices that can help to reducing the overall time as we are extensively using graphql in all our APIs?
Issue Analytics
- State:
- Created 3 years ago
- Reactions:10
- Comments:20 (12 by maintainers)
Top Results From Across the Web
Performance issues in graphql-java, specificall...anycodings
Specifically these two methods of Graphql anycodings_graphql are taking most of the processing time: graphql.execution.ExecutionStrategy#completeField; graphql.
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
I am going t close this issue. We have attackd the performance of the execution strategy quite a lot of late.
Any of the (very welcome) perf details above will not be out of date to the code.
We should raise new performance issues against the latest code at future points
In which case I dont know how kickstart + kotlin works and this project (graphql-java) does not support kick start. Kick start is built on top of graphql-java but how it uses it exactly is not something I can help with.
Others may know more.
Good luck with finding your answers