derekbrown
Hey everyone! New to the forum, not new to Elixir. 
In any case, recently had a discussion with @benwilson512 on overhead during GQL requests, and then saw a related question in the Absinthe channel on Slack, so decided to open it up here for input/guidance.
Problem
We’ve been tracing our API’s performance in Datadog and have seen some oddities that we can’t quite diagnose. Pictures are worth 1000 words, so here are some flame graphs for one request that demonstrates the issue:
The overall flame graph
1st Flame: Token Auth (in our Context)
2nd Flame: GQL Resolution
What’s happening in the gaps after auth/context and after the actual resolution?
This is just one request, but many of our requests have this shape, where the majority of the request has something unknown happening for at least 50ms or so. In some cases, we have 100ms or so unaccounted for, usually on the tail-end of the request post-resolution.
Environment
- App is released via
mix releaseto AWS (EC2 machine) and deployed behind an ELB (https). - Elixir 1.9.1, Erlang 22, Absinthe v1.5.0, Absinthe Plug v1.5.0-rc2, Absinthe Phoenix 1.5.0-rc.0
- The app is behind a Phoenix Router, Phoenix Endpoint, but is an API server.
Is anyone else seeing things like this? Happy to answer any other questions to help figure this out!
Where Next?
Trending in Questions
Other Trending Topics
Latest on Elixir Forum
Sponsor Spotlight
Producing high quality Elixir screencasts since 2017.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixirconf-us
- #ai
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #elixirconf-eu
- #metaprogramming
- #hex
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Master modern tools, write cleaner code, and tackle real-world challenges.
**Building the future of software with AI, trust, and human connection.**
The deployment platform built for Elixir: PaaS ease, VPS control.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 19 to 10- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
tansan
Is there a tutorial some where? I mainly want to see the performance on my queries with Abinsthe. If I set it up, would it show up in LiveDashboard?
benwilson512
Hi @tansan yes
:telemetryis basically the ecosystem standard at this point.tansan
Sorry to bring up an old thread, but is this still the recommended telemetry for absinthe in 2023?
benwilson512
Awesome. Do note that once OTP 24 is released we’ve seen significant improvements from the JIT as well, so we expect the overhead to drop a further ~60% from that alone.
derekbrown
Yes! Forgot to mention that: we’re using
PersistentTermas well (have been since it was in PR last year), and it’s definitely provided gains as well. Huge thanks to @benwilson512 and team for that.FWIW, when I say that our response times are manageable, I may have been understating. Our overall times have been reduced to a third of what they were.
It’s still a mystery to me exactly what’s happening, but it’s now a low priority mystery for us.
benwilson512
The offer to investigate any runnable example stands! Do make sure to check out the persistent_term backend Absinthe.Schema.PersistentTerm — absinthe v1.11.0 which we’re promoting out of the Experimental namespace in the next release. It has proven to be both faster and easier to work with.
I’m seeing the original post was on Absinthe 1.5.0, and we definitely fixed an N^2 regression in our variable handling somewhere in a release between that and latest. Hopefully you’ve updated since!
derekbrown
I didn’t unfortunately. But I do think that a lot of it is resolution. We made a couple of changes to batch resolvers that seemed to have helped. There were a couple of uncaught n+1 errors as well on our side. Still a lot of unexplained gaps though, but the response times are at least manageable now.
mmartinson
@derekbrown did you end up with any further learnings from this? I’m working with a similar issue. Any useful resources to link?
benwilson512
With respect to this, the best bet would be to create something we can both iterate on that exhibits the behaviour you’re running into. I should also ask about the server you’re running this in.
derekbrown
Thanks, Ben! Makes sense. You’ve been super helpful and I’m appreciative.
And JSON encoding being a majority of the tail makes sense as well; I think that length of time is proportionate to our response object. I’m still trying to diagnose if it’s our nested query documents (sometimes 4-5 levels) that’re causing the perf gap during validation or if it’s something else.