Mercurial > hg > nginx-site
changeset 708:25584379a968
Slightly revised the DTrace article's text and grammar.
author | Ruslan Ermilov <ru@nginx.com> |
---|---|
date | Fri, 05 Oct 2012 04:15:57 +0000 |
parents | b133b1f44765 |
children | a4648185190a |
files | xml/en/docs/nginx_dtrace_pid_provider.xml |
diffstat | 1 files changed, 26 insertions(+), 26 deletions(-) [+] |
line wrap: on
line diff
--- a/xml/en/docs/nginx_dtrace_pid_provider.xml Thu Oct 04 15:02:55 2012 +0000 +++ b/xml/en/docs/nginx_dtrace_pid_provider.xml Fri Oct 05 04:15:57 2012 +0000 @@ -20,15 +20,15 @@ </para> <para> -Although nginx build with <link doc="debugging_log.xml">--with-debug</link> +Although nginx built with the <link doc="debugging_log.xml">--with-debug</link> option already provides a lot of information about request processing, it is sometimes desirable to trace particular parts of code path more -thoroughly and at the same time omit the rest of debug output. +thoroughly and at the same time omit the rest of debugging output. DTrace pid provider (available on Solaris, OS X) is a useful tool to -explore userland programs internals, since it doesn’t require any code +explore userland program’s internals, since it doesn’t require any code changes and it can help with the task. -E.g. a simple DTrace script to trace and print nginx functions calls -may look like: +A simple DTrace script to trace and print nginx function calls +may look like this: <programlisting> #pragma D option flowindent @@ -53,14 +53,13 @@ <para> One of the common scenarios for using DTrace with nginx is the following: -attach to the nginx worker to log request lines and request start times. +attach to the nginx worker process to log request lines and request start times. The corresponding function to attach is -<literal>ngx_http_process_request</literal>, and the argument in question -is a pointer to <literal>ngx_http_request_t</literal> structure. +<c-func>ngx_http_process_request</c-func>, and the argument in question +is a pointer to the <literal>ngx_http_request_t</literal> structure. DTrace script for such request logging can be as simple as: <programlisting> - pid$target::*ngx_http_process_request:entry { this->request = (ngx_http_request_t *)copyin(arg0, sizeof(ngx_http_request_t)); @@ -69,19 +68,20 @@ printf("request line = %s\n", this->request_line); printf("request start sec = %d\n", this->request->start_sec); } +</programlisting> -</programlisting> </para> <para> It should be noted that in the example above DTrace requires some knowledge -about <literal>ngx_http_process_request</literal> structure. +about the <literal>ngx_http_process_request</literal> structure. Unfortunately while it is possible to use a specific <literal>#include</literal> directive in the DTrace script and then pass it to a C preprocessor -(with -C flag), that doesn’t really work. -Due to a lot of cross dependencies almost all nginx header files +(with the <literal>-C</literal> flag), that doesn’t really work. +Due to a lot of cross dependencies, almost all nginx header files have to be included. -In turn, based on configure script settings, nginx headers will include PCRE, +In turn, based on <command>configure</command> script settings, +nginx headers will include PCRE, OpenSSL and a variety of system header files. While in theory all those header files related to a specific nginx build might be included in DTrace script preprocessing and compilation, in reality @@ -91,7 +91,7 @@ <para> The problem above can be solved by including only the relevant and -necessary structures and types definitions in the DTrace script. +necessary structure and type definitions in the DTrace script. DTrace has to know sizes of structures, types, and fields offsets. Thus dependencies can be further reduced by manually optimizing structure definitions for use with DTrace. @@ -105,17 +105,17 @@ <para> First of all <literal>objs/ngx_auto_config.h</literal> file generated by configure should be included, because it defines a number of constants -affecting various <literal>#ifdef’s</literal>. -After that there’s some basic types and definitions +affecting various <literal>#ifdef</literal>’s. +After that, some basic types and definitions like <literal>ngx_str_t</literal>, <literal>ngx_table_elt_t</literal>, -<literal>ngx_uint_t</literal> etc. should be put at the beginning of +<literal>ngx_uint_t</literal> etc. should be put at the beginning of the DTrace script. These definitions are compact, commonly used and unlikely to be frequently changed. </para> <para> -Then there’s the <literal>ngx_http_process_request_t</literal> structure which +Then there’s the <literal>ngx_http_process_request_t</literal> structure that contains a lot of pointers to other structures. Because these pointers are really irrelevant to this script, and because they have the same size, it is possible to just replace them with void pointers. @@ -127,19 +127,19 @@ typedef ngx_http_request_body_t void; </programlisting> -Last but not least it is necessary to add definitions of two member structures: -<literal>ngx_http_headers_in_t</literal> and -<literal>ngx_http_headers_out_t</literal>, callback functions -declarations and constants definitions. +Last but not least it is necessary to add definitions of two member structures +(<literal>ngx_http_headers_in_t</literal>, +<literal>ngx_http_headers_out_t</literal>), +declarations of callback functions and definitions of constants. </para> <para> -Final DTrace script can be downloaded +The final DTrace script can be downloaded from <link url="http://nginx.org/download/trace_process_request.d">here</link>. </para> <para> -The example below shows the output of the DTrace script: +The following example shows the output of running this script: <programlisting> # dtrace -C -I ./objs -s trace_process_request.d -p 4848 @@ -155,7 +155,7 @@ </para> <para>Using similar techniques the reader should be able to trace other -nginx functions calls. +nginx function calls. </para> </section>