What is the intent of collecting these values?

@deweerdt @robguima What do you think?

FWIW, I can understand that you might want to track how the average latency changes over time. To do that, I can see that you would periodically collect the stats, and calculate (cur_latency - prev_latency) / (cur_handshake_count - prev_handshake_count) to obtain the average latency between the previous stats collection and the current stats collection.

What I wonder is how you would use the data. Even though it is a nice-have, I am not sure if it can be used for analyzing issues, etc., because the time spent to finish a handshake not only depends on the mode of the handshake (i.e. full vs. resume) but also on the version of TLS, use of false start, use of HRR (in case TLS 1.3 is used).

I think I might be fine with merging the PR as-is (we might want to change the name of to "accumulated_latency" or something, though), but I am wondering if the information being exposed here is sufficient.

@kazuho even though I agree that the latency measurements may be of limited usefulness, they could be useful in determining if say, lack of resources (e.g. busy CPU) may be impairing handshakes and increasing latency. So, if a spike in latency is detected externally, these stats may help in determining why (providing finer grained detail). Granted, CPU monitoring would accomplish the same, but that may not be avail at all times. Also, if something like neverbleed is in the picture (vs not), its effect on latency, if any, would be more easily measured.

Regarding the impl, it does lgtm as well 👍
However, I have a more generic suggestion around stats, and not entirely about this PR: couldn't perhaps the whole implementation of stats/counters (or at least the majority of them) be made lock free? Considering these are cumulative stats, which already are per worker and with per-thread data, reckon stats could be using thread-local variables/arrays (with an aggregator to sum the values when needed). (have a sample impl doing just that that I could share)

@robguima The reason I asked is because lack of resources is not the only factor that affects the latency. In TLS before 1.2, I assume that the numbers will reflect 1 RTT + time spent to process handshake messages. In TLS 1.3, in most cases, the time will just reflect the time spent to processing handshake messages (if HRR is not used), or 1 RTT + time spent to process the handshake messages.

Considering the fact that the measured value includes RTT, and that we are going to start seeing TLS 1.3 connections for which the measured value does not include RTT, I would be cautious about using this value for detecting issues, though I am not generally against measuring and using this value to support the verification of other metrics.

However, I have a more generic suggestion around stats, and not entirely about this PR: couldn't perhaps the whole implementation of stats/counters (or at least the majority of them) be made lock free?

Actually, it's lock free. The stats are tied to h2o_context_t which is a per-event-loop (also means pre-thread) structure. When the stats handler is called, it gathers the information from all the threads (this is when a mutex is used) and reports them back to the client.

Ah I see. Hmm wondering what would be the best solution then... Perhaps splitting it further into the different categories (esp once 1.3 is in use and esp 0RTT)?

On the stats, good to know thanks for the explanation. 👍 On the other hand, the aggregator could also be made lock free (w/ preallocated/registered thread-local data). Anyway, does not seem that important now considering that the contention around locking the aggregator is probably very low (and infrequent).

I am inclined to have this property as-is, and see how it goes, considering the fact that nobody has argued against having it, and maintaining it is easy.

We will have the chance to improve the metrics (by adding new ones).