-
-
Notifications
You must be signed in to change notification settings - Fork 996
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
On-demand server-timing #3410
Comments
Damn, I wonder how much slower will OTel be when enabled then. |
Yeah, this makes sense since
Not yet familiar with OTel (and the Push model) but doesn't it do some buffering before sending the events to a collector? I've also read that they do sampling, so not all requests are traced. This would reduce resource consumption. It would be interesting to have an internal sampling mechanism, so we could have some server-timing traces exposed as metrics. (just an idea for now, not sure if worth it) |
Problem
Setting server-timing-enabled to true has a ~6.5% RPS decrease. Using GETSimple on https://github.com/PostgREST/postgrest-benchmark:
no timings = 2176.4712194 rps
with timings = 2033.3584706 rps
I don't think there's a way around it since calculating the timings requires using clock time which needs a system call (clock_gettime).
Solution
Allow getting server timing headers through a new preference header.
Prefer: metrics=timings
metrics=timings
would be the only value for now, but we could extend it later on.This can later be enabled/disabled with #2987.
While at it, deprecate server-timing-enabled since it has a perf impact.
The text was updated successfully, but these errors were encountered: