Custom resolvers are degrading performance dramatically. about graphql-prisma-typescript HOT 6 CLOSED

Hey @harrisrobin, after the new batching support in prisma-binding, we've seen tremendous improvements in performance. I'm sure @timsuchanek can provide more details on this one than me 🙂

Please give it a try, thanks for bringing this up in the first place! I'm closing this discussion for now, feel free to open another ticket if you encounter any other question.

from graphql-prisma-typescript.

Yes, in my example application that included exactly the use case you described, I could reduce the query time from 19s to 1.6s, while having multiple roundtrips from eu to us. Would be interesting to hear, if you also see performance gains :)

from graphql-prisma-typescript.

Your first query takes ~2 seconds for me. That should take much shorter.

The demo endpoint is helpful for comfirming that queries take long, but it's difficult to say what happens "behind the scenes". I just did a bunch of tests with aggregation queries with my own service, and all of them had much better performance.

Did you try to connect directly to your Prisma endpoint and run the raw query that is done by the Prisma binding?

My current assessment is that the latency between your deployed GraphQL Yoga server to the Prisma endpoint is the main factor for the long duration. On what now tier is your instance deployed? Where is it deployed to?

Please share more information so we can look into that further 🙂

from graphql-prisma-typescript.

Currently prisma-binding doesn't make use yet of the dataloader pattern – which is a critical pending improvement (prisma-labs/prisma-binding#7). This will most likely also negatively impact the current situation.

@harrisrobin can you confirm this just happens when using the hosted development cluster of Prisma and not when you're running Prisma locally? I suspect this to be a result of request throttling which will no longer be an issue once dataloader support in prisma-binding was introduced.

from graphql-prisma-typescript.

@schickling you are correct. I can confirm that this does not happen in local.

No custom resolver on local

query {
  spaces {
    id
    name
  }
}

with custom resolver on local

query {
  spaces {
    id
    name
    avgRating
  }
}
}

from graphql-prisma-typescript.

One extra piece of information: I just tried to send an invalid query to your API. It should involve no db communication and thus should be really fast. A query from Berlin averages 800 ms for me, which is 2-3x what I would expect. Can you try to look at your now dashboard to verify that it is not getting frozen and unfrozen all the time?

This doesn't explain the increased latency when adding more resolvers though. What I suspect is happening is that your requests to Prisma are being throttled. The free dev clusters queue up requests to ensure that no service performs more than 1 request per second. I think we need to allow for short bursts to allow use cases like this. I will follow up here when we have implemented this change.

from graphql-prisma-typescript.