Expose profiling endpoints #3370
Conversation
olegbespalov
force-pushed
the
feat/pprof
branch
from
bac27ee
to
6fd68cc
Compare
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## master #3370 +/- ##
=======================================
Coverage 73.36% 73.36%
=======================================
Files 261 261
Lines 19742 19760 +18
=======================================
+ Hits 14483 14497 +14
- Misses 4365 4367 +2
- Partials 894 896 +2
Flags with carried forward coverage won't be shown. Click here to find out more.
☔ View full report in Codecov by Sentry. |
olegbespalov
force-pushed
the
feat/pprof
branch
from
6fd68cc
to
ec85262
Compare
There was a problem hiding this comment.
Not certain if we shouldn't make this configruable but otherwise LGTM!
My predominant problem wiht lack of configuration isn't even it being "expensive" to have it around - it isn't.
But the fact that we add it on top of the /api/v1 endpoint which we might drop at some future point and then anything using this needs to change. But I feel like it will probably be better at taht future point to leave this endpoint where it is and build v2 around it 🤷
|
I am also unsure if we need to expose the profiling endpoints by default even if it doesn't harm (at least, I can't name the cases). It also aligns with other grafana's projects where enabling profiles are usually controlled by setting. So, if the team decides, I'll happily produce one more commit. @oleiade @codebien, anybody else who sees that? Please vote on this comment:
|
|
I would align with the Grafana ecosystem and have config for it 👍🏻 |
Maybe we can find more rationale about why in their original issues. |
olegbespalov
dismissed stale reviews from oleiade, codebien, and mstoykov
via
66dc9c5
olegbespalov
force-pushed
the
feat/pprof
branch
from
ec85262
to
66dc9c5
Compare
olegbespalov
added
the
documentation-needed
|
Hey there! I've implemented a flag Unfortunately, it's not so easy to add the configuration via environment variables; for example, REST API has no way to configure it through environment variables. But for the starter, that should be enough. |
There was a problem hiding this comment.
LGTM 🚀
As I tried the feature locally, I had to go and read the code to find out what port to use in the URL.
I wonder if we could somehow display the profile URL as part of k6 output somehow. The dashboard project displays it as part of the output line at the moment. Feel free to merge without, and don't consider my comment blocking 👍🏻
cmd/run.go
Outdated
| go func() { | ||
| defer apiWG.Done() | ||
| logger.Debugf("Starting the REST API server on %s", c.gs.Flags.Address) | ||
| logger.Debugf("Profiling endpoints exposed: %v", c.gs.Flags.ProfilingEnabled) |
There was a problem hiding this comment.
I would prefer this to be behind an if instead of printing a false/true
|
@mstoykov no problem, I'll adjust and add log 👍 |
olegbespalov
force-pushed
the
feat/pprof
branch
from
2089d5b
to
a43edef
Compare
What?
This change exposes profiling endpoints for the k6.
Why?
This won't have significant performance implications (if the endpoints are not used), so we could expose them by default.
But having this endpoint allows efficient development of k6 (and extension)
Checklist
make ci-like-lint) and all checks pass.make tests) and all tests pass.Related PR(s)/Issue(s)
Closes #1692