servenv: Move away from using default HTTP muxer#12987
servenv: Move away from using default HTTP muxer#12987dbussink merged 3 commits intovitessio:mainfrom
Conversation
Review ChecklistHello reviewers! 👋 Please follow this checklist when reviewing this Pull Request. General
If a new flag is being introduced:
If a workflow is added or modified:
Bug fixes
Non-trivial changes
New/Existing features
Backward compatibility
|
c7bdb92 to
5480dde
Compare
Up until now we've been using the implicit default HTTP mux. The problem of using this mux is that it works implicitly also for profiling endpoints. So the moment that `net/http/pprof` is imported, those endpoints get added. We want to be able to make enabling the profiling endpoints optional, but there's no way to do that with the default mux except by recompiling and removing the import. By moving everything away from the default mux to an explicit mux for the servenv, we can make this configurable in the near future. It still gets added to the default mux, but we don't use that anymore so it doesn't get exposed. The changes here now explicitly add the profiling endpoints so that we can make that optional in a follow up. Signed-off-by: Dirkjan Bussink <d.bussink@gmail.com>
5480dde to
94fbd24
Compare
ajm188
left a comment
There was a problem hiding this comment.
this is awesome! i have one suggestion around structuring, but otherwise i'm extremely excited about this
| // register the HTTP handlers for profiling | ||
| _ "net/http/pprof" |
Because of the http pprof import that exists today and our usage of the default mux, we always end up with the http profiling endpoints today. It’s not possible to turn those off and on because of that. Anyone using Vitess could be using those endpoints to enable / disable specific profilers at runtime through those pprof http endpoints. We use these for example in PlanetScale internally when we need to debug issues with Vitess to do things like dump stack traces for goroutines. That’s separate from the profiling flags which end up always enabling the profiling depending on how those flags are given. So they are separate things today. The net change of the refactor here is that for the end user everything still works the same. |
Signed-off-by: Dirkjan Bussink <d.bussink@gmail.com>
Signed-off-by: Dirkjan Bussink <d.bussink@gmail.com>
Since vitessio#12987 profiling is not loaded implicitly through an import but only explicitly. This means we need to make sure that `servenv.Init` is called. It's not called for all binaries which is an oversight. It also explains why this wasn't found with vitessio#12987 since that was tested with binaries like `vttablet` and `vtgate` and it was assumed that this loading was done everywhere properly, which it sadly was not. Signed-off-by: Dirkjan Bussink <d.bussink@gmail.com>
Up until now we've been using the implicit default HTTP mux. The problem of using this mux is that it works implicitly also for profiling endpoints. So the moment that
net/http/pprofis imported, those endpoints get added.We want to be able to make enabling the profiling endpoints optional, but there's no way to do that with the default mux except by recompiling and removing the import.
By moving everything away from the default mux to an explicit mux for the servenv, we can make this configurable in the near future. It still gets added to the default mux, but we don't use that anymore so it doesn't get exposed.
The changes here now explicitly add the profiling endpoints so that we can make that optional in a follow up.
Checklist