Can someone explain how to understand these two metrics: query/segment/time and query/segmentAndCache/time. Is this assumption is correct? • query/segment/time = time to get segment from RAM or if it's not in RAM , then time to get it from disk into RAM also included • query/segmentAndCache/time = time to get segment from cache (which is in heap), if this cache is enabled on historicals When we run test with query cached enabled on historicals, but disabled in the query context, I see both metrics are identical on the graph, if the query cache is enabled in the query context instead, then the query/segmentAndCache/time is much lower than the query/segment/time.

I believe /query/segment/time is the (wall clock) time to process a segment from disk. And /query/segmentAndCache/time is the time to process either a segment from disk, or from the cache. average segmentAndCache time would be lower if cache is being used, as you saw. And if cache is being used, count(query/segment/time) will probably be lower than count(query/segmentAndCache/time). ("Probably" because these metrics are sampled, and not reported 100% of the time.)

While I don't have exact knowledge, I just want to chip in that Druid memory maps the segment files and thus can't even tell the difference between "comes from ram" and "comes from disk"

yes, I admit to a little confusion about segment cache (from memory-mapped / RAM) and caching that uses caffeine or something like memcached, and which one this "cache" refers to in "segmentAndCache".