We want to Measure GraphQL query/mutation performance and see if there are bits of code that we can improve. We would also like to see what is the overhead being added by query rewriting and processing apart from the time it takes to process the query by Dgraph. Load testing and getting P50, P95, …

Hi Pawan Great post! I think the list is detailed for different queries and mutations we would want to test on. I have a few things we probably could add: Test running a query and mutation at the same time and monitor performance Running multiple threads of random queries/mutations from different…

I want these two points: [image] pawan: Once we get some initial latency/throughput numbers from our load testing, then we should find a way to store them and compare them across releases. [image] Sankalan13: We could use distributed testing with cloud resources and have a database that …

[image] Sankalan13: Test running a query and mutation at the same time and monitor performance Running multiple threads of random queries/mutations from different users parallelly We could include a test which runs query and mutations at the same time and use that for load testing. I am not …

[image] pawan: I believe our work would give us more value if we spent our time doing more testing and benchmarking over the next 3 weeks. Fair enough. Let’s have a look at a work plan for that.

Listing down the individual tasks which would be converted to JIRA tickets getType/queryType single and multi-level queries Also to be tested with interfaces. These would be written as Go benchmarks which would make an HTTP call to an Alpha running on the same instance. We should be measuring t…

[image] pawan: We would again check the CPU/memory profile and the %ge of time taken for pre and post processing vs the actual mutation Also, for mutation and query we should see json serialization and deserialization time for larger payloads. Some libraries support parallel encoding which is…

[image] pawan: The aim here is to see if we can parallelize our execution of custom fields or make it more efficient by computing some bits at schema update time instead of query execution time. Since we process requests parallelly, we should run the tests with Go’s race detector.

[image] pawan: I am not so sure about random queries/mutations because we can’t benchmark that across releases as the latency would depend on the queries/mutations and their ratios. I agree, we’d not be able to benchmark that across releases. I think randomness would facilitate mimicking prod…

Maybe we can include schema related things also here, like what you suggested today. And that might help us answer these questions as well - What are the limits for a schema for GraphQL .

You are missing the mutation/delete use case as well. I know bulk deletes are problematic in the current graphql implementation. It would be good to benchmark those so we can document improvement over time. Other Queries I would recommend adding: query using using geolocation filtering for dist…

Benchmarking GraphQL performance

Dev

arijit (Arijit Das) June 26, 2020, 3:04am 7

Also, for mutation and query we should see json serialization and deserialization time for larger payloads. Some libraries support parallel encoding which is 1.5x to 2x faster than encoding/json package.

Topic		Replies	Views
GraphQL query/mutation benchmarking result GraphQL benchmark	10	2123	July 28, 2020
Graphql Benchmark with Locust GraphQL benchmark	4	2535	October 27, 2020
Making Dgraph a truly GraphQL-native database - Dgraph Blog Blog	1	680	September 9, 2021
Linköping GraphQL Benchmark (LinGBM) GraphQL	6	623	December 5, 2021
Dgraph benchmark Dgraph dgraph	8	932	August 5, 2020

Benchmarking GraphQL performance

Related topics