Fork me on GitHub
#graphql
<
2022-01-18
>
orestis11:01:51

Not strictly graphql related but possibly someone in this channel could give me some pointers. I'd like to troubleshoot some performance issues with some of our graphql endpoints. There's obviously the timing extension support right there in Lacinia for one-offs, but I would like to take this as an opportunity to add proper observability (e.g. AWS x-ray, Honeycomb etc). What I'm looking for is to collect various timing data about graphql queries: How long did the root resolver took, how long did the sql backend took for the root resolver, any other N+1 queries that we may be unwittingly firing etc etc.

hden12:01:54

I did exactly that with X-Ray. It helped us identified several N+1 problems. The Java SDK is quite painful to work with, so I ended up with wrapping it as a clojure library. https://github.com/hden/aws-xray-sdk-clj

orestis13:01:25

Thanks! Did you end up instrumenting every resolver manually or is there some trick in Lacinia to wrap all resolvers?

orestis13:01:34

Any guidance on how to map segments to graphql? I guess the top level query is the first segment and any child resolvers would be subsegments?

hden13:01:55

Yes. Depends on how you resolve your result, a context switch might be needed. https://lacinia.readthedocs.io/en/latest/resolve/context.html

orestis13:01:23

Also what could be a useful annotation? Eg resolver args?

hden13:01:43

You might need to pass the root segment to the field resolvers so that the field resolvers can attach subsegments to the root segment. There are several ways to do so, one is to pass the parent (e.g. root) segment as a part of the application context.

orestis14:01:44

Right, I was hoping that Lacinia could allow me to do that globally. But I guess I could do that via a defresolver macro or similar.

👍 1
yenda16:01:42

We've been using pedestal.log tracing with datadog, opening traces in interceptors, and spans around resolvers using a wrapper so that we have the details. It was quite painful tbh because active-span can return a closed span and we ended up with mangled traces. In the end with quite some lifting on our end to completely rely on our own active spans it works ok

orestis17:01:34

It seems like there's some movement towards standardizing tracing etc with open telemetry but it feels quite early days still. I'll probably go with x-ray for now.

osi19:01:24

we have our GraphQL endpoint instrumented with Honeycomb. highly recommended.

hlship19:01:40

I have been thinking about some mechanism where you could provide some kind of "event listener/callback" to Lacinia and it would send you details about what it is doing. That might make it possible to identify what's going on during execution.

👍 2