You don’t need to do it this way. see https://rakyll.org/profiler-labels/ <https://rakyll.org/profiler-labels/>
You label the work. The work will be recorded with the labels for analysis. The labels can be nested. This will allow you to use the execution trace to profile wall time, see https://talks.golang.org/2015/dynamic-tools.slide#30 <https://talks.golang.org/2015/dynamic-tools.slide#30> The standard pprof/profile will do cpu time profiling. This is all you really need to do the profiling. > On May 11, 2020, at 10:58 PM, Steve Canfield <stevencanfi...@gmail.com> wrote: > > Thanks, but what about the "I can't enable profiling for every request" bit? > Assume it's actually important for me to know the cpu consumption on a per > request basis. > > On Mon, May 11, 2020 at 4:55 PM Robert Engels <reng...@ix.netcom.com > <mailto:reng...@ix.netcom.com>> wrote: > Look at pprof labels. > >> On May 11, 2020, at 6:29 PM, Steven Canfield <stevencanfi...@gmail.com >> <mailto:stevencanfi...@gmail.com>> wrote: >> >> >> Hi, >> >> I have an RPC server which has heterogenous requests, e.g. some calls hit >> cache and are cheaper to serve while others need to compute a result. >> >> Is there any way to keep track of the cpu used just by one particular >> goroutine[1]? It seems like there's not a straightforward way today without >> adding logic around every single blocking piece (to start/stop a timer), and >> in the future will become completely impossible with "Non-cooperative >> goroutine preemption". >> >> I would be happy with only knowing this number when a goroutine finishes. >> >> I'm familiar with using pprof for measuring the entire process, but it's not >> clear to me how to go from there to what was used by a particular RPC, and I >> also can't enable profiling for every request. >> >> Thanks, >> -Steve >> >> 1: I really want a goroutine and its children, but I create new goroutines >> in few enough places that I could do some context mgmt to manage this. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "golang-nuts" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to golang-nuts+unsubscr...@googlegroups.com >> <mailto:golang-nuts+unsubscr...@googlegroups.com>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/golang-nuts/e2d7e3d7-c678-4515-9cdb-060d29b14500%40googlegroups.com >> >> <https://groups.google.com/d/msgid/golang-nuts/e2d7e3d7-c678-4515-9cdb-060d29b14500%40googlegroups.com?utm_medium=email&utm_source=footer>. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/A1D870A7-ADFD-4F00-B678-E7C6C0FE80FD%40ix.netcom.com.
