clintropolis commented on code in PR #13420:
URL: https://github.com/apache/druid/pull/13420#discussion_r1041392870
##########
processing/src/main/java/org/apache/druid/query/QueryMetrics.java:
##########
@@ -396,6 +396,30 @@
*/
QueryMetrics<QueryType> reportParallelMergeTotalCpuTime(long timeNs);
+ /**
+ * Reports broker total "wall" time in nanoseconds from parallel merge start
sequence creation to total
+ * consumption.
+ */
+ QueryMetrics<QueryType> reportParallelMergeTotalTime(long timeNs);
+
+ /**
+ * Reports broker "wall" time in nanoseconds for the fastest parallel merge
sequence partition to be 'initialized',
+ * where 'initialized' is time to the first result batch is populated from
data servers and merging can begin.
+ *
+ * Similar to query 'time to first byte' metrics, except is a composite of
the whole group of data servers which are
+ * present in the merge partition, which all must supply an initial result
batch before merging can actually begin.
+ */
+ QueryMetrics<QueryType> reportParallelMergeFastestPartitionTime(long timeNs);
Review Comment:
>would the slowest ttfb node produce slowest partition and same for the
fastest? or could it be that the result batching changes the distribution of
slowest and fastest partition - hence these metrics might be different from ttfb
yeah, these times would include the batching so its not really the first
byte exactly, but they probably aren't that far off in practice. I would expect
the slowest probably will most of the time be the same-ish as the slowest ttfb,
though perhaps it is interesting if for some reason it isn't as it might mean
the pool is overloaded or something else interesting is going on. The fastest
ttfb should be faster than the fastest partition because the fastest partition
will be determined by the slowest first batch of results from the servers in
that partition.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
