i just converted a graphql-java service to kotlin, then rewrote it to use graphql-kotlin. i ran load...

# graphql-kotlin

[Lenny]

i just converted a graphql-java service to kotlin, then rewrote it to use graphql-kotlin. i ran load tests before and after. the final version has a significant performance regression … average latency rose from 200-ish ms to over 1000ms. this is using 3.0.0-rc5. i’ll dig in more but if anyone has guidance on where to look i could use the help!

[Shane Myrick]

What operations are you running to test performance? Query, Mutation, Subscription?

Are you using coroutines or any async wrapper?

[Lenny]

queries only, and i’m not really using coroutines yet but i am using dataloader

[Dariusz Kuc]

well there is a big difference in behavior whether you use regular blocking query vs coroutine based one

[Dariusz Kuc]

checking if we have it documented

[Dariusz Kuc]

https://expediagroup.github.io/graphql-kotlin/docs/execution/async-models

[Dariusz Kuc]

TLDR if you don’t use any of the async models, by default you will be blocking the threads

[Dariusz Kuc]

are you using graphql-kotlin-spring-server ?

[Lenny]

i’m not, we have our own java framework 😞

[Lenny]

i think this codepath is using completable futures, but maybe i’m blocking things elsewhere … i’m experimenting with a couple of things

[Lenny]

this is the resolver i’m using:

class Query {
  fun plan(id: ID, env: DataFetchingEnvironment): CompletableFuture<Plan?> {
    return env.getDataLoader<String, Plan>("plan").load(id.value)
  }
}

[Lenny]

and i’m calling it multiple times in the same operation, like

{
  a: plan(id: 1) {id}
  b: plan(id: 2) {id}
  c: plan(id: 3) {id}
}

[Dariusz Kuc]

what execution strategy are you using?

[Dariusz Kuc]

i.e. completable future will eventually run on some thread

[Dariusz Kuc]

you might need to create custom strategy with thread pools (or custom data fetcher that does it)

[Lenny]

.executeAsync()

[Lenny]

if that’s what you mean

[Dariusz Kuc]

https://github.com/ExpediaGroup/graphql-kotlin/blob/master/graphql-kotlin-spring-server/src/main/kotlin/com/expediagroup/graphql/spring/GraphQLAutoConfiguration.kt#L86

[Lenny]

hm interesting … i haven’t needed that api when i was using graphql-java directly

[Lenny]

i can give it a shot

[Dariusz Kuc]

i believe those are the defaults

[Dariusz Kuc]

it should behave similarly though -> i.e. if you return completable future https://github.com/ExpediaGroup/graphql-kotlin/blob/master/graphql-kotlin-schema-generator/src/main/kotlin/com/expediagroup/graphql/execution/FunctionDataFetcher.kt#L140 should just return

[Dariusz Kuc]

and then its up to graphql-java execution strategy to actually execute the futures

[Lenny]

yeah that was my impression too

[Dariusz Kuc]

If you could share some code that repro the issue that would be great

[Dariusz Kuc]

But such a big difference seems suspicious

[Lenny]

yeah i agree … i’ll spend some time trying to create a minimal reproduction

[Lenny]

thanks for the responses so far!

[Lenny]

sighh false alarm — i don’t know java and made a mistake structuring my app. i was recreating the schema on every request. which makes wayyyy more sense than a problem with graphql-kotlin!

[Dariusz Kuc]

👍