Metrics dashboard graph docs

General
#1

I do not understand some of the graphs in the SQL metrics dashboard. The tooltips aren’t very helpful for my understanding.

Execution latency: The latency between query requests and responses over a 1 minute period. Values are displayed individually for each node.

Service latency: Over the last minute, this node executed queries within this time. This time does not include network latency between the node and client.

A breakdown or example of these values would be very beneficial. Thank you!

#2

The tooltips are not very good indeed. This needs to be repaired (@couchand, comments?)

Meanwhile:

  • when a client sends a SQL query this is processed as follows:
    1. the server receives the query
    2. the query is parsed
    3. the query is planned
    4. the query is executed; during execution, results are sent back to the client
    5. processing completes.
  • the “execution latency” is the time between steps 3 and 5 above.
  • the “service latency” is the time between steps 1 and 5.
#3

Our plan is to remove the execution latency chart entirely and focus on service latency on the SQL time-series dashboard. We’ve found that having both is generally confusing and rarely interesting.

Where the breakdown is interesting is when looking at the execution of individual statements, so we will definitely continue to highlight that information on the Statement Details page.

1 Like
#4

Thanks for the breakdown, that definitely helps clarify things.

Is it safe to assume then, that the time difference between service and execution latency is all spent in parsing? I ask because I have seen service latency ~20 seconds and execution latency < 100 ms.

Is that normal, or is time being spent somewhere else?

#5

The “Statement details” screen in the UI will detail where the query is spending its time. This will clarify where the 20s are spent.

Large parsing times are extremely unusual. What’s possible (even likely) is that the logical planning needs to take a lease on the descriptor of one of the tables involved, and that descriptor is being held up by a DDL transaction somewhere else.

To get a definite answer, you can trace one of those long queries.