trafficserver-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Peach <jpe...@apache.org>
Subject Re: Ownership of proxy.process.ssl.total_success_handshake_count
Date Thu, 07 Jul 2016 18:56:59 GMT

> On Jul 7, 2016, at 9:55 AM, Shrihari Kalkar <Shrihari.Kalkar@riverbed.com> wrote:
> 
> Guys,
> I understand that in code, if a stat is registered under 'proxy.process' it is owned
by traffic_server.

That is by convention. In the code RECT_PROCESS metrics are owned by traffic_server. Ownership
of metrics is not a particularly strong concept though :-/

> Also, if a stat is registered under stats.config.xml or metrics.config, the 'destination'
is owned by traffic_manager.
> 
> Since proxy.process.ssl.total_success_handshake_count is listed in stats.config.xml and
metrics.config, do you think that this is a conflict of ownership?

Grovelling through the git history will probably clear this up for you. IIRC total_success_handshake_count
was moved to the derived metrics for compatibility when total_success_handshake_count_in and
total_success_handshake_count_out were introduced. Maybe it makes sense now to make total_success_handshake_count
the sum of in and out?

> I see that on my instance, traffic_manager keeps sending an 'RECG_SET' event for this
stat to traffic_server even when nothing is happening. As a result, I am seeing an issue where
traffic_server blocks for a very long time for initializing.

Hmm. I'm not sure that slow initialization would be related to this. One common cause of initialization
lag is setting proxy.config.http.wait_for_cache. I think you need to debug this one further
:)

> I wanted to know if my understanding of ownership is correct. And if it is, can I open
a new bug to track the definition of this stat?

Yes, it sounds like it is worth revisiting SSL stats to make sure they still make sense. Last
time I looked at these, there were a few problems.

J



Mime
View raw message