Skip to content
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.

Sign up for GitHub

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

Jump to bottom

On-demand server-timing #3410

Open
steve-chavez opened this issue Apr 14, 2024 · 2 comments · May be fixed by #3507
Open

On-demand server-timing #3410

steve-chavez opened this issue Apr 14, 2024 · 2 comments · May be fixed by #3507
Assignees
@taimoorzaeem
Labels
enhancement a feature, ready for implementation

Comments

@steve-chavez
Copy link
Member

steve-chavez commented Apr 14, 2024 •
edited
Loading

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.
@steve-chavez steve-chavez added idea Needs of discussion to become an enhancement, not ready for implementation difficulty: beginner Pure Haskell task enhancement a feature, ready for implementation and removed idea Needs of discussion to become an enhancement, not ready for implementation labels Apr 14, 2024
@develop7
Copy link
Collaborator

Setting server-timing-enabled to true has a ~6.5% RPS decrease.

Damn, I wonder how much slower will OTel be when enabled then.

@steve-chavez
Copy link
Member Author

Yeah, this makes sense since server-timing is a trace and by definition:

Running traces takes too much time and consumes too many resources to trace every request an application receives.
https://www.techtarget.com/searchitoperations/tip/The-3-pillars-of-observability-Logs-metrics-and-traces

Damn, I wonder how much slower will OTel be when enabled then.

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)

@taimoorzaeem taimoorzaeem self-assigned this Apr 24, 2024
@taimoorzaeem taimoorzaeem linked a pull request May 11, 2024 that will close this issue
Open
@steve-chavez steve-chavez removed the difficulty: beginner Pure Haskell task label Sep 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@taimoorzaeem taimoorzaeem

Labels
enhancement a feature, ready for implementation
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

feat: add metrics=timings to prefer header taimoorzaeem/postgrest
3 participants
@develop7 @steve-chavez @taimoorzaeem