question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Performance of ExecutionStrategy#completeField and ExecutionStrategy#fetchField

See original GitHub issue

Hi,

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.

image

Specifically two methods:

  • graphql.execution.ExecutionStrategy#completeField
  • graphql.execution.ExecutionStrategy#fetchField

image *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 image

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:closed
  • Created 3 years ago
  • Reactions:10
  • Comments:20 (12 by maintainers)

github_iconTop GitHub Comments

2reactions
bbakermancommented, Jul 10, 2021

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

0reactions
bbakermancommented, Feb 7, 2022

we’re using graphql java kickstart

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

Read more comments on GitHub >

github_iconTop 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 >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found