Replies: 1 comment
|
My PR originally did not pass CI because of type complexity: adding tracing bumped up the return value's complexity incidentally. I just fixed CI (by allowing the complexity) to hopefully get some feedback on the PR :). |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Hi folks, I'm curious if it is a specific choice for sqlx to not be using extensive use of tracing spans? Or if that is just its current status?
For context, I'm digging in to some performance issues in my application as we scale to hundreds of thousands of requests per minute. We're pretty bought in to the tracing ecosystem and otel, and we often see big gaps in our data that we think might be connection pool acquisition, but we're not sure.
We're thinking about going ham and instrumenting sqlx (at least the pool and the postgres backend) within an inch of its life to try and dig in to what is happening here. But if there's some sort of background info we're missing I'd be glad to know it. It'd also change how we go about doing that.
Note I originally posed this question on Discord, and since then I did a TAS speedrun of instrumenting a lot of sqlx to see what that looks like: #4343. I haven't used it, though, so I don't know if this solves my problem or is worth upstreaming.
All reactions