GraphQL query/mutation benchmarking result

[pawan (Pawan Rawal)]

Summarized Results

Mutations

• add/update mutations - Most of the time and memory is spent while executing the mutation inside Alpha. This means that GraphQL mutations add very little overhead over GraphQL± mutations
  @arijit is supposed to post the ratio of (pre + post processing time) to the total time spent executing the mutation.

• add/update mutations with Auth - The execution time for mutations with and without auth rules is very similar which means auth rules don’t add much overhead. In some cases the execution time with auth rules is lesser because we end up fetching lesser data.

Queries

• query - GraphQL queries can end up taking 14-36% of the total execution time doing post-processing and applying GraphQL constraints. The percentage is higher for queries that return a large amount of data. A lot of memory and time is consumed while JSON unmarshalling the result of the GraphQL± query from Alpha and transforming it (completeObject) and then json marshaling it back(WriteTo above). There is scope for improvement here and we have added this to investigate in our backlog.
• queries with custom fields - There are two cases here, single and batch mode.

@abhimanyusinghgaur

|=================================================|
|      Schema type        |  % GraphQL layer time |
|=========================|=======================|
| Simple Schema           |          14-36%       |
| Custom with SINGLE mode |          40-96%       |
| Custom with BATCH mode  |          36-70%       |
|=================================================|

We have discovered a couple of issues that we have added to our backlog.

• too many file descriptor error - This comes when we make too many concurrent requests. We should look into how can we avoid that error.
• bug with id not being substituted properly while making requests to fetch a custom field in single-mode - this has been fixed already by @abhimanyusinghgaur