[PROPOSAL] HTTP Metrics Overhaul

2018-10-15 Thread Masaori Koshiba
Hi all, I’d like to propose some HTTP metrics changes. Because current HTTP metrics doesn’t have consistent naming rules. 1. Define `proxy.process.http.*` is HTTP version general metrics. 2. Introduce `proxy.process.http1.*` metrics for HTTP/1.1 specific metrics. 3. Split general metric into

Re: [API] Proposal for cleaning up the TLS server verify options

2018-10-15 Thread Susan Hinrichs
I put up a PR with the code changes, docs, and tests. https://github.com/apache/trafficserver/pull/4414 On Thu, Oct 11, 2018 at 1:16 PM Susan Hinrichs wrote: > Since we will want to pull this back sooner, I'll probably have to go > through the "backwards compatibility" pain in any case. > > On T

Re: Blocking I/O in network thread

2018-10-15 Thread Alan Carroll
That's interesting - I think we could do that incrementally even. One of the goals of the BufferWriter formatting effort was to improve performance for debugging messages as well, mainly by avoiding local argument formatting if the trace wasn't enabled. IP addresses are the classic example - to pa

Re: Blocking I/O in network thread

2018-10-15 Thread Walt Karas
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 co

Re: Blocking I/O in network thread

2018-10-15 Thread Alan Carroll
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 messag