Queries that include input fields are executed slowly

[dhartung]

Library Version
graphql-kotlin-spring-server:6.2.5

Describe the bug
I have encountered performance problems with a large number of requests. After deeper analysis, I found out that a query with input fields is much slower than a query without. Having many objects with input fields increases the problem even more.

Steps to reproduce

class ExampleQuery: Query {
    fun example(): List<ExampleType> = (1..20).map { ExampleType() }
}

data class ExampleType(
    val number: Int = Random.nextInt()
) {
    fun addition(a: Int, b: Int) = a + b
}

Now we can execute two different queries

Query A	Query B
query QueryA { example { one: number two: number three: number } }	query QueryB { example { one: addition(a: 500, b: 600) two: addition(a: 400, b: 700) three: addition(a: 300, b: 900) } }

When timing the requests to the endpoint, we can measure the following execution times:

Query	Min	Max	Mean	Std
A	1.4ms	37.8ms	5.0ms	4.4ms
B	13.7ms	271.9ms	36.4ms	36.2ms

When including input fields, the execution time is 7-10 times worse. In fact, this means that we have to run up to 10 times more instances to handle the same amount of load.

I've created a small repo to reproduce my results: https://github.com/dhartung/graphql-kotlin-demo

Expected behavior
Adding or removing input types to the query should make almost no difference to the execution time.

[samuelAndalon]

When including input fields, the execution time is 7-10 times worse. In fact, this means that we have to run up to 10 times more instances to handle the same amount of load.

Hello, did you run some sort of stress testing or benchmarking that back ups this statement ?

it makes sense to me that queries with inputs will take longer to execute because the arguments need to be deserialized.

will take a deeper look into this, on v6 we switched from jackson into kotlin reflections to deserialize arguments so theorically this process should be faster now.

[fletchgqc]

@samuelAndalon the stress test is in the sample which @dhartung provided.

[samuelAndalon]

@fletchgqc i was referring to

10 times more instances to handle the same amount of load.

that's not necessarily true, at least for the full reactive non-blocking servers, webflux i,e.

anyways -- will take a look at this.

Cheers!

[roookeee]

I did some digging and these functions are the hottest while executing b:

These all ultimately lead to KTypeExtensionsKt.isSubclassOf() via KTypeExtensionsKt.isOptionalInputType():

It seems like Kotlins isSubclassOf is pretty slow with a depth-first search approach.

The only way to alleviate these issues is to do the reflective introspection once per Kotlin function. We could get away with implementing a cache inside of isOptionalInputType() but it would be healthier to introduce a more sophisticated caching mechanism which does all reflection related operations (not only the optional input type check) the first time a "new" Kotlin function is encountered. This would require a more extensive rewrite of some internals.

EDIT: The other half of convertArgumentValue()s execution time is spent in isGraphQLContext() which also uses isSubclassOf, it seems to be a general bottleneck for us:

[roookeee]

Let me know if you would like to get a PR for this and in what way I should address the outlined issue (simple cache inside isSubclassOf vs a more thorough reorg) :)