Also, you may be interested in github.com/robaho/goanalyzer <http://github.com/robaho/goanalyzer> - I feel it makes latency analysis much easier.
> On May 11, 2020, at 11:46 PM, robert engels <reng...@ix.netcom.com> wrote: > > 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 >> <mailto: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 > <mailto: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 > > <https://groups.google.com/d/msgid/golang-nuts/A1D870A7-ADFD-4F00-B678-E7C6C0FE80FD%40ix.netcom.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/D2E41AEE-E53C-4817-8E77-1D41D5219700%40ix.netcom.com.
