This page:
- Describes the high-level components involved in a Cloud Spanner API request.
- Explains how to extract, capture, and visualize latencies associated with these components to know the source of the latencies.
The high-level components that are used to make a Spanner API request include:
Spanner client libraries, which provide a layer of abstraction on top of gRPC, and handle server communication details, such as session management, transactions, and retries.
The Google Front End (GFE), which is an infrastructure service that's common to all Google Cloud services, including Spanner. The GFE verifies that all Transport Layer Security (TLS) connections are stopped and applies protections against Denial of Service attacks. To learn more about the GFE, see Google Front End Service.
The Spanner API front end, which performs various checks on the API request (including authentication, authorization, and quota checks), and maintains sessions and transaction states.
The Spanner database, which executes reads and writes to the database.
When you make a remote procedure call to Spanner, the Spanner client libraries prepare the API request. Then, the API request passes through both the GFE and the Spanner API front end before reaching the Spanner database.
By measuring and comparing the request latencies between different components and the database, you can determine which component is causing the problem. These latencies include client round-trip, GFE, Spanner API request, and query latencies.
Client round-trip latency
Client round-trip latency is the length of time (in milliseconds) between the first byte of the Spanner API request that the client sends to the database (through both the GFE and the Spanner API front end), and the last byte of response that the client receives from the database.
Spanner client libraries provide statistics and traces with the use of the OpenCensus instrumentation framework. This framework gives insights into the internals of the client, and aids in troubleshooting end-to-end (round-trip) latency.
By default, the framework is disabled. To learn how to enable this framework, see Capture client round-trip latency.
The grpc.io/client/roundtrip_latency
metric provides the time between the first byte of the API request sent to the last byte of the response received.
Capture client round-trip latency
You can capture client round-trip latency for the following languages:
Java
Go
Visualize client round-trip latency
After retrieving the metrics, you can visualize client round-trip latency in Cloud Monitoring.
Here's an example of a graph that illustrates the 5th percentile latency for the client round-trip latency metric. To change the percentile latency to either the 50th or the 99th percentile, use the Aggregator menu.
The program creates an OpenCensus view called roundtrip_latency
. This string becomes part of the name of the metric when it's exported to Cloud Monitoring.
GFE latency
GFE latency is the length of time (in milliseconds) between when Google's network receives a remote procedure call from the client and when the GFE receives the first byte of the response. This latency doesn't include any TCP/SSL handshake.
Every response from Spanner, whether it's REST or gRPC, includes a header that contains the total time between the GFE and the back end (the Spanner service) for both the request and the response. This helps to differentiate better the source of the latency between the client and Google's network.
The cloud.google.com/[language]/spanner/gfe_latency
metric captures and exposes GFE latency for Spanner requests.
Capture GFE latency
You can capture GFE latency for the following languages:
Java
Go
Visualize GFE latency
After retrieving the metrics, you can visualize GFE latency in Cloud Monitoring.
Here's an example of a graph that illustrates the 5th percentile latency for the GFE latency metric. To change the percentile latency to either the 50th or the 99th percentile, use the Aggregator menu.
The program creates an OpenCensus view called gfe_latency
. This string becomes part of the name of the metric when it's exported to Cloud Monitoring.
Spanner API request latency
Spanner API request latency is the length of time (in seconds) between the first byte of request that the Spanner API front end receives and the last byte of response that the Spanner API front end sends. The latency includes the time needed for processing API requests in both the Spanner back end and the API layer. However, this latency doesn't include network or reverse-proxy overhead between Spanner clients and servers.
The spanner.googleapis.com/api/request_latencies
metric captures and exposes Spanner API front end latency for Spanner requests.
Capture Spanner API request latency
By default, this latency is available as part of Cloud Monitoring metrics. You don't have to do anything to capture and export it.
Visualize Spanner API request latency
You can use the Metrics Explorer charting tool to visualize the graph for the spanner.googleapis.com/api/request_latencies
metric in Cloud Monitoring.
Here's an example of a graph that illustrates the 5th percentile latency for the Spanner API request latency metric. To change the percentile latency to either the 50th or the 99th percentile, use the Aggregator menu.
Query latency
Query latency is the length of time (in milliseconds) that it takes to run SQL queries in the Spanner database.
Query latency is available for both the executeSql and the executeStreamingSql APIs.
If the QueryMode
parameter is set to PROFILE
, then Spanner's ResultSetStats
are available in the responses.
Setting QueryMode
to PROFILE
returns both the query plan, and the execution statistics along with the results. Also, ResultSetStats
includes the elapsed time for running queries in the Spanner database.
Capture query latency
You can capture query latency for the following languages:
Java
Go
Visualize query latency
After retrieving the metrics, you can visualize query latency in Cloud Monitoring.
Here's an example of a graph that illustrates the 5th percentile latency for the query latency metric. To change the percentile latency to either the 50th or the 99th percentile, use the Aggregator menu.
The program creates an OpenCensus view called query_stats_elapsed
. This string becomes part of the name of the metric when it's exported to Cloud Monitoring.
Troubleshoot latency issues
By using Cloud Monitoring to capture and visualize client round-trip, GFE, Spanner API request, and query latencies, you can compare them, side-by-side. This helps you identify the source of the latency.
In the following table, you can find some examples of latency issues and why they might be occurring:
For this latency issue... | The problem might be... |
---|---|
You have a high client round-trip latency, but a low GFE latency and a low Spanner API request latency. | There might be an issue in the application code, or there might be a networking issue between the client and the regional GFE. If your application has a performance issue that causes some code paths to be slow, then the client round-trip latency for each API request might increase. This latency can also be caused by issues on the computing infrastructure on the client side (for example, VM, CPU, or memory utilization, connections, file descriptors, and so on). |
You have a high client round-trip latency and a high Spanner API request latency. |
|
You have a high GFE latency, but a low Spanner API request latency. |
|
You have a high Spanner API request latency, but a low query latency. | Check the Google Cloud Status Dashboard to see if there are any ongoing networking issues in your region. If there aren't any issues, then open a support case and include this information so that support engineers can help with troubleshooting the Spanner API front end. |
You have a high query latency. | To view metrics for your query and to help you troubleshoot your query latency issue, see Query statistics. For better performance, optimize your schema, indexing, and query. For more information, see SQL best practices and Troubleshooting performance regressions. |
What's next
- Read about OpenCensus with Cloud Spanner.
- Learn more about OpenCensus.
- Understand custom metrics with OpenCensus.
- See how instance configuration affects latency.