profile icon indicating copy to clipboard operation
profile copied to clipboard

Support writing to arbitrary io.Writer

Open jcline opened this issue 8 years ago • 2 comments

Hi,

I have a use case where I want to trigger profiles on a remote server and then load the resulting file via an HTTP endpoint. It seemed to me supporting writing the raw bytes to an arbitrary io.Writer would be the most generic way of supporting that use case (and potentially others).

I have a fork with code that works for me on master at https://github.com/VerizonDigital/profile, but it's kind of messy feeling and doesn't have any new tests for the io.Writer portion. Is this something you're interested in? I'm more than happy to change the way I've implemented it if you have any changes you'd like made.

Thanks for the work you've done so far. Starting with this made my life easier. :D

jcline avatar Aug 16 '16 23:08 jcline

Why not use net/http/pprof ?

On 17 Aug 2016, at 07:58, James Cline [email protected] wrote:

Hi,

I have a use case where I want to trigger profiles on a remote server and then load the resulting file via an HTTP endpoint. It seemed to me supporting writing the raw bytes to an arbitrary io.Writer would be the most generic way of supporting that use case (and potentially others).

I have a fork with code that works for me on master at https://github.com/VerizonDigital/profile, but it's kind of messy feeling and doesn't have any new tests for the io.Writer portion. Is this something you're interested in? I'm more than happy to change the way I've implemented it if you have any changes you'd like made.

Thanks for the work you've done so far. Starting with this made my life easier. :D

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

davecheney avatar Aug 17 '16 00:08 davecheney

I have several constraints which prevented using that, based on my understanding of the mechanism:

  • The program supports creating arbitrary HTTP endpoints on arbitrary address port combinations, and I need this one to run on a distinct address port combination that does not interfere with the others. AFAICT the net/http/pprof assumes a global http instance it can add it's routes to and use, which my service doesn't have available. I suppose I could modify it so that the global instance was the special one, but I can't say I'm a huge fan of singletons in general.
  • There are networking constraints out of my control that will result in long, idle connections being killed. It's unclear to me if pprof streams while it profiles or only sends the data after the profiler has been stopped. Splitting starting the profiler and retrieving the data into separate HTTP requests seemed like a simple solution to the concern.
  • The /debug/* endpoints don't match the API style of the rest of the service (not the end of the world, but sucks that they aren't customizable, AFAICT).
  • I've no idea how to implement any authorization mechanism with the net pprof package.

jcline avatar Aug 17 '16 00:08 jcline