graphql-engine/server/benchmarks/benchmark_sets/deep_schema
Brandon Simmons 167e8f4cae server/benchmarks: configurable pause after each adhoc benchmark, bef…
…ore checking allocations

It seems like there might be some non-determinism exposed after #10206 we see a huge regression reported in live_bytes in huge_schema which apparently disappears, later reappearing in
https://github.com/hasura/graphql-engine-mono/pull/10226#issuecomment-1697897108

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/10240
GitOrigin-RevId: 8e9533cb9fd7db6c002f00d1d9cb0331d574d6a2
2023-08-30 20:27:53 +00:00
..
adhoc_operations server/benchmarks: configurable pause after each adhoc benchmark, bef… 2023-08-30 20:27:53 +00:00
config.query.yaml [ci] add benchmark for deep schema 2022-08-24 15:55:29 +00:00
dump.sql.gz [ci] add benchmark for deep schema 2022-08-24 15:55:29 +00:00
README.md [ci] add benchmark for deep schema 2022-08-24 15:55:29 +00:00
replace_metadata.json [ci] add benchmark for deep schema 2022-08-24 15:55:29 +00:00

This data set is meant to test nested remote relationships: it contains a huge amount of remote relationships, chosen to make it so that as "depth-first" traversal will cross from one source to the other 50 times. Building the schema across remote relationships isn't easy, and the reason this set came to be was that an approach we considered for how to use different contexts for different sources actually resulted in a performance degradation with deep schemas such as this artificially created one.

At time of writing, we have no plan to use this set to benchmark queries: our main concern is the schema building time, as measured by a call to replace_metadata.

A degradation of performance that is made visible by this set but no other likely indicates a problem with the implementation of remote relationships in the schema.