Composition performance

[ehardy]

We are using the @apollo/composition package as part of an open source graphql schema registry we are using internally. The package's composeServices() function is used to compose and validate schemas before a new schema version can get added to the registry. We have noticed that composeServices() takes significantly longer the more schemas there are to compose. Running a benchmark on my Mac M1, composing our 42 schemas takes anywhere between 700-800ms, not bad. On our Kubernetes clusters, where we don't use as fast CPUs, composing the same 42 schemas takes 10x longer, in the range of 8s, sometimes more. Initially when we had a handful of schemas, things were ok, but the more schemas we created, the longer it took for composing schemas, which is to be expected I suppose. We will be creating more schemas in the future, so the situation will only get worse.

So it could argued/said that this is our problem and we just have to run better hardware, but I was wondering if that's something that others have experienced and if there are any plans to maybe improve the performance of composeServices()?

[sachindshinde]

Thanks for writing in! Depending on the subgraph schemas, composition can take a while to run, as it needs to validate that all possible queries on the router API schema can be answered via a combination of queries on the subgraph schemas. Regarding hardware, using more powerful CPU cores may help, but it may also help to check RAM/memory usage and ensure you're not getting close to limits there (we've found composition times can increase significantly when near memory limits).

[ehardy]

Thanks for the reply @sachindshinde. It didn't occur to me that memory could affect composition performance. I have plenty on my Mac compared to what we have allocated on our Kubernetes pods. I'll do a few tests with different memory settings.

You mentioned Router, which is written in Rust. Are there any plans to have a Rust based version of composeServices()?