[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC)：2025-09-05。"],[],[],null,["# Use metrics to diagnose latency\n\nThis page describes the latency metrics that Spanner provides. If your\napplication experiences high latency, use these metrics to help you diagnose and\nresolve the issue.\n\nYou can view these metrics [in the Google Cloud console](/spanner/docs/monitoring-console) and [in\nthe Cloud Monitoring console](/spanner/docs/monitoring-cloud).\n\nOverview of latency metrics\n---------------------------\n\nThe latency metrics for Spanner measure how long it takes for the\nSpanner service to process a request. The metric captures the actual\namount of time that elapses, not the amount of CPU time that Spanner\nuses.\n\nThese latency metrics do not include latency that occurs outside of\nSpanner, such as network latency or latency within your application\nlayer. To measure other types of latency, you can use Cloud Monitoring to\n[instrument your application with custom metrics](/monitoring/custom-metrics).\n\nYou can view charts of latency metrics [in the\nGoogle Cloud console](/spanner/docs/monitoring-console#view-history) and [in the\nCloud Monitoring console](/spanner/docs/monitoring-cloud). You can view combined\nlatency metrics that include both reads and writes, or you can view separate\nmetrics for reads and writes.\n\nBased on the latency of each request, Spanner groups the requests into\npercentiles. You can view latency metrics for 50th percentile and 99th\npercentile latency:\n\n- **50th percentile latency**: The maximum latency, in seconds, for the fastest\n 50% of all requests. For example, if the 50th percentile latency is 0.5 seconds,\n then Spanner processed 50% of requests in less than 0.5 seconds.\n\n This metric is sometimes called the *median latency*.\n- **99th percentile latency**: The maximum latency, in seconds, for the fastest\n 99% of requests. For example, if the 99th percentile latency is 2 seconds, then\n Spanner processed 99% of requests in less than 2 seconds.\n\n### Latency and operations per second\n\nWhen an instance processes a small number of requests during a period of time,\nthe 50th and 99th percentile latencies during that time are not meaningful\nindicators of the instance's overall performance. Under these conditions, a very\nsmall number of outliers can drastically change the latency metrics.\n\nFor example, suppose that an instance processes 100 requests during an hour. In\nthis case, the 99th percentile latency for the instance during that hour is the\namount of time it took to process the slowest request. A latency measurement\nbased on a single request is not meaningful.\n\nHow to diagnose latency issues\n------------------------------\n\nThe following sections describe how to diagnose several common issues that could\ncause your application to experience high end-to-end latency.\n\nFor a quick look at an instance's latency metrics, [use the\nGoogle Cloud console](/spanner/docs/monitoring-console). To examine the metrics more closely\nand [find correlations](/spanner/docs/monitoring-cloud#create-charts) between latency and other\nmetrics, [use the Cloud Monitoring console](/spanner/docs/monitoring-cloud).\n\n### High total latency, low Spanner latency\n\nIf your application experiences latency that is higher than expected, but the\nlatency metrics for Spanner are significantly lower than the total\nend-to-end latency, there might be an issue in your application code. If your\napplication has a performance issue that causes some code paths to be slow, the\ntotal end-to-end latency for each request might increase.\n\nTo check for this issue, benchmark your application to identify code paths that\nare slower than expected.\n\nYou can also comment out the code that communicates with Spanner, then\nmeasure the total latency again. If the total latency doesn't change very much,\nthen Spanner is unlikely to be the cause of the high latency.\n\n### High total latency, high Spanner latency\n\nIf your application experiences latency that is higher than expected, and the\nSpanner latency metrics are also high, there are a few likely causes:\n\n- **Your instance needs more compute capacity.** If your instance does not have enough\n CPU resources, and its CPU utilization exceeds the [recommended\n maximum](/spanner/docs/cpu-utilization#recommended-max), then Spanner might not be able to process\n your requests quickly and efficiently.\n\n- **Some of your queries cause high CPU utilization.** If your queries do not\n take advantage of Spanner features that improve efficiency, such as\n [query parameters](/spanner/docs/reference/standard-sql/lexical#query_parameters) and [secondary indexes](/spanner/docs/secondary-indexes),\n or if they include a large number of [joins](/spanner/docs/reference/standard-sql/query-syntax#join_types) or other CPU-intensive\n operations, the queries can use a large portion of the CPU resources for your\n instance.\n\nTo check for these issues, use the Cloud Monitoring console to [look\nfor a correlation](/spanner/docs/monitoring-cloud#create-charts) between high CPU utilization and\nhigh latency. Also, check the [query statistics](/spanner/docs/introspection/query-statistics) for your\ninstance to identify any CPU-intensive queries during the same time period.\n\nIf you find that CPU utilization and latency are both high at the same time,\ntake action to address the issue:\n\n- If you did not find many CPU-intensive queries, [add compute capacity to the\n instance](/spanner/docs/create-manage-instances#change-compute-capacity).\n\n Adding [compute capacity](/spanner/docs/compute-capacity) provides more CPU resources and enables\n Spanner to handle a larger workload.\n- If you found CPU-intensive queries, review the [query execution\n plans](/spanner/docs/query-execution-plans) to learn why the queries are slow, then update\n your queries to follow the [SQL best practices for\n Spanner](/spanner/docs/sql-best-practices).\n\n You might also need to review the [schema design](/spanner/docs/schema-design) for the\n database and update the schema to allow for more efficient queries.\n\nWhat's next\n-----------\n\n- Monitor your instance with the [Google Cloud console](/spanner/docs/monitoring-console) or the [Cloud Monitoring console](/spanner/docs/monitoring-cloud).\n- Learn how to [find correlations between high latency and other\n metrics](/spanner/docs/monitoring-cloud#create-charts).\n- Understand how to reduce read latency by following [SQL best\n practices](/spanner/docs/sql-best-practices) and using [timestamp bounds](/spanner/docs/timestamp-bounds).\n- Find out about [latency metrics in query statistics\n tables](/spanner/docs/introspection/query-statistics), which you can retrieve using SQL statements.\n- Understand [how instance configuration affects latency](/spanner/docs/instances)."]]
