Yeah looks like you're right. I thought it might be less work to convert
data members first to read-only rather than directly to private/protected.
So I experimented with the hdr_info field in the State struct in the
HTTPTransact class (
https://github.com/apache/trafficserver/blob/master/proxy/ht
> On Jun 11, 2019, at 6:13 PM, Walt Karas
> wrote:
>
> I'm wondering if we should add this template to our core utilities:
> https://godbolt.org/z/4X-5wR . We could use it to conduct a gradual
> campaign of "creeping encapsulation", to pull up the pants of our many
> classes with (often lots
Since I'm still relatively new to this application, there are limits to
what I can take on on my own initiative. I don't see how anything I've
proposed would interfere with any higher-priority work.
On Wed, Jun 12, 2019 at 12:41 PM Leif Hedstrom wrote:
> Also, I’d like to reiterate my call to a
Also, I’d like to reiterate my call to arms on v9.0.0:
Please, everyone lets focus on the things that are critical to ATS v9.0.0
readiness!
This includes:
1) Fixing all the critical bugs (and there’s a lot of them)
2) Testing “master"
3) Doing the incompatible chan
I would guess the performance increase would be well under 1%. But it's a
fairly simple change. The biggest performance increase I think would come
from avoiding a PCRE match, to see if the specific debug tag was enabled.
For some TSDebug calls, there can be many arguments to push, and perhaps a
I meant wouldn’t in the last sentence. :)
-Bryan
> On Jun 12, 2019, at 9:47 AM, Bryan Call wrote:
>
> The RFC isn’t clear on what can be normalized for generating cache keys. In
> practice I have done other methods for normalizing URLs such as sorting query
> parameters. I have also lowerc
I am surprised you are seeing this as a performance issue. Looking at the code
it looks like 1 function call and a couple pointer dereferences.
If you wanted to speed up TSDebug and make the code harder to maintain you
could create a structure that looks like like DiagsConfig in ts.h and then s
> On Jun 12, 2019, at 10:47 AM, Bryan Call wrote:
>
> The RFC isn’t clear on what can be normalized for generating cache keys. In
> practice I have done other methods for normalizing URLs such as sorting query
> parameters. I have also lowercased paths knowing that the origin would be
> d
> On Jun 12, 2019, at 11:00 AM, Walt Karas
> wrote:
>
> What do you mean by "exposing diags"?
>
> On Wed, Jun 12, 2019 at 11:50 AM Bryan Call wrote:
>
>> I would rather see TSDebug be optimized and exposing diags instead of
>> creating a new type of debug.
For a while now, we’ve talked a
What do you mean by "exposing diags"?
On Wed, Jun 12, 2019 at 11:50 AM Bryan Call wrote:
> I would rather see TSDebug be optimized and exposing diags instead of
> creating a new type of debug.
>
> -Bryan
>
>
> > On Jun 12, 2019, at 9:44 AM, Walt Karas
> wrote:
> >
> > I don't believe so. The i
I would rather see TSDebug be optimized and exposing diags instead of creating
a new type of debug.
-Bryan
> On Jun 12, 2019, at 9:44 AM, Walt Karas
> wrote:
>
> I don't believe so. The issue I'm trying to address is that there is still
> significant execution time overhead for debug output
The RFC isn’t clear on what can be normalized for generating cache keys. In
practice I have done other methods for normalizing URLs such as sorting query
parameters. I have also lowercased paths knowing that the origin would be
doing the same, which I would recommend in this case.
-Bryan
>
I don't believe so. The issue I'm trying to address is that there is still
significant execution time overhead for debug output calls when
proxy.config.diags.debug.enabled is 0. This change would make the
execution time overhead negligible (if TSFastDbg is used or TSDebug is
changed to be like th
When I dived into the code it looks like this is separate code from generating
the cache key.
Cache::generate_key > URL::hash_get() > url_CryptoHash_get()
Vs
TSHttpTxnEffectiveNormalizedUrlStringGet() > HTTPHdr::url_string_get()
-Bryan
> On Jun 12, 2019, at 7:09 AM, Sudheer Vinukonda
> wr
How would this be controlled on the command line when running trafic_server -T?
It looks like it is a departure from how debug tags and controlled now.
-Bryan
> On Jun 11, 2019, at 1:21 PM, Walt Karas
> wrote:
>
> Any +1's for simply replacing TSDebug with the proposed TSFastDbg ?
>
> On Mo
That sounds reasonable. However, it does cause a compatibility issue for
someone upgrading in that, I think this API might change the cache key and
could potentially break cache.
Given that, wouldn’t we prefer to break the API in a more obvious fashion (e.g.
modify the signature to require a “
Didn't that PR do the normalization at a lower level? I like zwoop's idea,
that TSEffectiveUrlGet always return a normalized URL. It's kind of the
point of the call, to get the "real" URL from the request. I don't even
think that breaks compatibility since that's the correct value to return.
On Tu
17 matches
Mail list logo
