So I ended up with the same results using Node 0.8.x. Also tried out nhttpsnoop and ended up with this:
[root@00-0c-29-ab-31-af /development/nhttpsnoop]# ./nhttpsnoop -l -c -o time,pid,probe,which,latency,method,raddr,rport,url TIME PID PROBE LATENCY METHOD RADDR RPORT URL [ 4.671205] 49804 client -> - GET undefined 0 / [ 4.837243] 49804 client <- 166.037ms GET undefined 0 / [ 9.671754] 49804 client -> - GET undefined 0 / [ 9.863990] 49804 client <- 192.236ms GET undefined 0 / [ 14.673242] 49804 client -> - GET undefined 0 / [ 14.849406] 49804 client <- 176.163ms GET undefined 0 / [ 19.673156] 49804 client -> - GET undefined 0 / [ 19.852341] 49804 client <- 179.185ms GET undefined 0 / The default values for address and port are showing up here too, which I find interesting. This feels like an environmental issue, I'm running it locally through VMWare currently. I'm going to try it out in a real environment as well. Thanks for the sanity check! On Mon, Feb 5, 2018 at 3:05 PM, Brad Gardner <bgardne...@gmail.com> wrote: > I'll give both nhttpsnoop and older versions of node a try shortly, > haven't had a chance to get back at it since last night. I'll reply if > anything interesting turns up. > > Thanks! > > On Mon, Feb 5, 2018 at 2:42 PM, David Pacheco <d...@joyent.com> wrote: > >> On Sun, Feb 4, 2018 at 8:02 AM, Brad Gardner <bgardne...@gmail.com> >> wrote: >> >>> Hello! >>> >>> I'm working on learning to use DTrace to profile NodeJS applications and >>> have hit a wall that I'm hoping to get some additional insight on. >>> >>> I have a NodeJS application that is sending an HTTP request to >>> https://example.com every 5 seconds. This is working and getting a >>> proper response. >>> >>> *I'm using the following DTrace script:* >>> >>> #pragma D option quiet >>> >>> node*:::http-client-request >>> { >>> printf("Connection to %s:%d on fd %d - Request %s: %s\n", >>> args[1]->remoteAddress, args[1]->remotePort, >>> args[1]->fd, >>> args[0]->method, args[0]->url); >>> } >>> >>> *Output:* >>> >>> [root@00-0c-29-ab-31-af /development]# dtrace -s ./test.d >>> Connection to undefined:0 on fd 0 - Request GET: / >>> Connection to undefined:0 on fd 0 - Request GET: / >>> Connection to undefined:0 on fd 0 - Request GET: / >>> >>> It appears to me that all of the args[1] properties are not assigned and >>> giving back default values (undefined or 0 depending on type). >>> >>> *The documentation for this probe lists the arguments:* >>> >>> 12437 node35247 node _ZN4node26DTRACE_HTTP_CLIENT_R >>> EQUESTERKN2v820FunctionCallbackInfoINS0_5ValueEEE http-client-request >>> >>> Probe Description Attributes >>> Identifier Names: Private >>> Data Semantics: Private >>> Dependency Class: Unknown >>> >>> Argument Attributes >>> Identifier Names: Evolving >>> Data Semantics: Evolving >>> Dependency Class: ISA >>> >>> Argument Types >>> args[0]: node_http_request_t * >>> args[1]: node_connection_t * >>> args[2]: string >>> args[3]: int >>> args[4]: string >>> args[5]: string >>> args[6]: int >>> >>> >>> The node_http_request_t struct properties appear to work, while the >>> node_connection_t properties do not. >>> >>> I'm not sure where to go next in debugging this, or determining what >>> I've misconfigured. >>> >>> This is running on a SmartOS VM, running NodeJS 8.4. >>> >>> Any insight, or a kick in the right direction would be greatly >>> appreciated. >>> >> >> >> It's been a while since I dug into the internals, and I usually use >> "nhttpsnoop" when I use these probes. But what you're doing seems >> reasonable. Does it work reliably with an older version (such as Node >> 0.10)? >> >> -- Dave >> > > ------------------------------------------- dtrace-discuss Archives: https://www.listbox.com/member/archive/184261/=now RSS Feed: https://www.listbox.com/member/archive/rss/184261/25769126-e243886f Modify Your Subscription: https://www.listbox.com/member/?member_id=25769126&id_secret=25769126-8d47a7b2 Powered by Listbox: http://www.listbox.com
