I think we should consider switching to something like this for debug tracing:
https://godbolt.org/z/Xj1VXZ It will reduce the performance impact when all debug output is disabled. It will also reduce the impact even when some debug output is enabled. This may be helpful for bugs due to race conditions, where changes in performance can prevent the bug from happening. On Mon, Oct 15, 2018 at 10:37 AM Alan Carroll <solidwallofc...@oath.com.invalid> wrote: > > It's generally accepted that enable logging messages will decrease ATS > performance by roughly an order of magnitude, but as Dan points out, based > on this, we might be able to do better if the output was sent to an AIO > thread. OTOH, if you're trying to track timing / ordering issues, have the > messages come out asynchronously might negate much of the utility. > > On Sun, Oct 14, 2018 at 10:52 PM Daniel Xu <d...@apache.org> wrote: > > > Yeah that sounds suboptimal. Maybe it’d be good enough to leave a > > documentation note and mark fixing this as an intern project or > > something. > > Writing some off thread logging code and writing a poor man’s multi > > producer queue sounds like a pretty nice project. > > > > Daniel > > > > > > On Tue, Oct 9, 2018, at 7:34 PM, Pushkar Pradhan wrote: > > > I was going through the code in Diags.cc and I saw that if debug > > > logging is> on, ATS calls vfprintf in the thread that handles the client > > request.> E.g. > > > > > https://github.com/apache/trafficserver/blob/master/src/tscore/Diags.cc#L301 > > > > > > Is this a good idea? > > > Or is the assumption that if you have turned on debug logging you > > > make this> trade off? > > > > > > -- > > > pushkar > > > > > > -- > *Beware the fisherman who's casting out his line in to a dried up riverbed.* > *Oh don't try to tell him 'cause he won't believe. Throw some bread to the > ducks instead.* > *It's easier that way. *- Genesis : Duke : VI 25-28
