<div dir="ltr"><div><span style="color:rgb(255,153,0)">Hi Maxim,<br></span></div><div><span style="color:rgb(255,153,0)">Thanks for your code review and good comments.<br></span></div><div><span style="color:rgb(255,153,0)">The basic idea for http-call-trace is to provide a mechanism for nginx to have a sync-like call stack trace to enhance trouble shooting for load test.<br></span></div><div><span style="color:rgb(255,153,0)">Since nginx is event driven and </span><span style="color:rgb(255,153,0)">asynchronous based software,<br>it's good for performance, but not easy and natural for debugging and trouble shooting like </span><span style="color:rgb(255,153,0)">synchronous based, specially for load test.<br><br></span></div><div><span style="color:rgb(255,153,0)">DTrace certainly can trace the request in one worker process,<br>but only can trace entry/existence of one function.<br></span></div><div><span style="color:rgb(255,153,0)">But in nginx source code, there are some functions which has a lot of lines and "goto", <br>sometime need to trace the call flow at the middle of functions. <br>And DTrace depends on particular OS.<br><br></span></div><div><span style="color:rgb(255,153,0)">Why not use "--with-debug" or by default, there are two reasons: <br></span></div><div><span style="color:rgb(255,153,0)">1) want to has http-call-trace for release build means even no </span><span style="color:rgb(255,153,0)">"--with-debug", then developer can decide it by options.<br></span></div><div><span style="color:rgb(255,153,0)">2) currently, http-call-trace use http request nginx internal private header to store call stack</span><span style="color:rgb(255,153,0)">, so don't want to use by default.<br><br></span></div><div><span style="color:rgb(255,153,0)">This http-call-trace optional feature (like tool/utility functions) is mainly used to help troubleshooting for load test.<br></span></div><div><span style="color:rgb(255,153,0)">It do need to add trace code in nginx functions.<br><br></span></div><div><span style="color:rgb(255,153,0)">Regarding the code style and code quality, they can be refined accordingly.<br><br></span></div><div><span style="color:rgb(255,153,0)">Could you consider a bit more on http-call-trace feature? Especially from perspective of customization development based on nginx.<br><br></span></div><div><span style="color:rgb(255,153,0)">Thanks a lot.<br></span></div><div><span style="color:rgb(255,153,0)"><br></span></div><div><span style="color:rgb(255,153,0)"></span></div><div class="gmail_extra"><div class="gmail_quote">On Mon, Dec 25, 2017 at 10:12 PM, Maxim Dounin <span dir="ltr"><<a href="mailto:mdounin@mdounin.ru" target="_blank">mdounin@mdounin.ru</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello!<br>
<span class="gmail-"><br>
On Mon, Dec 25, 2017 at 11:24:51AM +0800, Xiaohua Wang wrote:<br>
<br>
> Hi Maxim,<br>
> Thanks for you reply.<br>
> Actually we already tried to use the dtrace method to do real-time tracing<br>
> as you mentioned.<br>
> dtrace is helpful in some scenarios.<br>
> But there are several issues we met while using dtrace,<br>
> 1) the drace usage is not so friendly, as reference guide mentioned, need<br>
> to define a lot of structure in dtrace script.<br>
> 2) in performance/load test, our purpose is to trace HTTP requests call in<br>
> nginx, instead of tracing some methods in one process.<br>
<br>
</span>DTrace certainly can be used for tracing particular requests,<br>
though you have to write appropriate D code to do this.<br>
<span class="gmail-"><br>
> And what I want to add http-call-trace in nginx source code,<br>
> 1) it is a separated module, can be controlled by configure options<br>
> (--with-http-call-trace), no impact any existence source code.<br>
> 2) it's very easy to use and support alll OS platforms which nginx can<br>
> support, no dependency on Dtrace tool.<br>
<br>
</span>And here are downsides, in no particular order:<br>
<br>
- As in the patch suggested, the code literally does nothing. To<br>
do something meaningful it additionally requires introducing<br>
trace calls in various functions.<br>
<br>
- The code is far from being in nginx coding style.<br>
<br>
- The code uses hacks to store its data.<br>
<br>
- The code is http-only for some reason (well, actually the reason<br>
is clear: because it uses a http-only hack).<br>
<br>
Note well that it's not a module as you claim, but rather an<br>
optional set of functions for call tracing, an optional feature<br>
similar to --with-debug.<br>
<br>
It is also not clear why it is made optional - rather, it should<br>
be made a part of --with-debug instead, or even the default, as it<br>
neither depends on any external libraries nor introduces<br>
additional calls by itself. The only reason for being optional<br>
seems to be the quality of the code.<br>
<span class="gmail-"><br>
> Could you help think it again?<br>
<br>
</span>Sorry, but the answer is still no.<br>
<div class="gmail-HOEnZb"><div class="gmail-h5"><br>
--<br>
Maxim Dounin<br>
<a href="http://mdounin.ru/" rel="noreferrer" target="_blank">http://mdounin.ru/</a><br>
______________________________<wbr>_________________<br>
nginx-devel mailing list<br>
<a href="mailto:nginx-devel@nginx.org">nginx-devel@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx-devel" rel="noreferrer" target="_blank">http://mailman.nginx.org/<wbr>mailman/listinfo/nginx-devel</a><br>
</div></div></blockquote></div><br></div></div>