Custom resolvers are degrading performance dramatically.

[harrisrobin]

I have hosted this repo and I found a pretty big performance issue I mentioned to @marktani over Slack. He then told me to make an issue.

https://entr-server.now.sh/
This is pretty much the same code, with a few custom resolvers added.

Prisma is hosted on the US shared cluster.
Graphql server is hosted on now.sh.

If you send the following query to the playground, you will notice things are fast as I am expecting:

Test 1

Query

query {
  spaces {
    id
  }
}

Performance:

Now let's add a custom resolver from this repo, numRatings, basically this :

Test 2

Query

query {
  spaces {
    id
    numRatings
  }
}

Performance:

All of a sudden this query takes over 7 seconds 😱

Test 3

Now let's add another one. I made this one myself:

Query

query {
  spaces {
    id
    numRatings
    avgRating
  }
}

Performance

It pretty much exactly doubled.

What's going on here? Can someone please explain how custom revolvers impact performance? Would love to learn more

Everything can be tested on
https://entr-server.now.sh/

Thank you very much :)

[marktani]

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 🙂

[schickling]

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.

[harrisrobin]

@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
  }
}
}

[sorenbs]

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.

[marktani]

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.

[timsuchanek]

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 :)