Métricas de latencia

En esta página, se describen las métricas de latencia que ofrece Cloud Spanner. Si tu aplicación experimenta una latencia alta, usa estas métricas para ayudarte a diagnosticar y resolver el problema.

Puedes ver estas métricas en la consola de Google Cloud y en la consola de Cloud Monitoring. En la página Supervisión de Google Cloud Console, se muestran dos métricas relacionadas con la latencia. El primero es para la latencia y el segundo para la latencia por tipo de transacción.

Latencia

Las métricas de latencia de Spanner miden el tiempo que tardó en Spanner para procesar las funciones de solicitud de lectura (Read, StreamingRead, ExecuteSql, StreamingExecuteSql, ExecuteBatchDml) o escritura (Commit). Selecciona “Read/write” (Leer/escribir) para ver las métricas para ambos. La métrica captura la cantidad de tiempo real que transcurrió, no la cantidad de tiempo de CPU que usó Spanner.

Estas métricas de latencia no incluyen la latencia que ocurre fuera de Spanner, como la latencia de red y la latencia dentro de la capa de la aplicación. A fin de medir otros tipos de latencia, puedes usar Cloud Monitoring para instrumentar tu aplicación con métricas personalizadas.

Puedes ver las métricas de latencia en Google Cloud Console y en la consola de Cloud Monitoring. Puedes ver métricas de latencia combinadas que incluyen funciones de lectura y escritura, o puedes ver métricas distintas para lecturas y escrituras.

Según la latencia de cada solicitud, Spanner agrupa las solicitudes en percentiles. Puedes ver las métricas de latencia para el percentil 50 y la latencia del percentil 99:

  • Latencia del percentil 50: La latencia máxima, en segundos, para el 50% más rápido de todas las solicitudes. Por ejemplo, si la latencia del percentil 50 es de 0.5 segundos, Spanner procesó el 50% de las solicitudes en menos de 0.5 segundos.

    A veces, esta métrica se denomina latencia mediana.

  • Latencia del percentil 99: La latencia máxima, en segundos, para el 99% más rápido de las solicitudes. Por ejemplo, si la latencia del percentil 99 es de 2 segundos, Spanner procesó el 99% de las solicitudes en menos de 2 segundos.

Latencia y operaciones por segundo

Cuando una instancia procesa una pequeña cantidad de solicitudes durante un tiempo, las latencias de los percentiles 50 y 99 durante ese momento no son indicadores significativos del rendimiento general de la instancia. En estas condiciones, una cantidad muy pequeña de valores atípicos puede cambiar drásticamente las métricas de latencia.

Por ejemplo, supongamos que una instancia procesa 100 solicitudes durante una hora. En este caso, la latencia del percentil 99 para la instancia durante esa hora es la cantidad de tiempo que tomó procesar la solicitud más lenta. Una medición de latencia basada en una solicitud única no es significativa.

Latencia por tipo de transacción

Las métricas de Latencia por tipo de transacción de Spanner miden y muestran la cantidad de tiempo que Spanner tardó en procesar una transacción. Puedes ver las métricas de las transacciones de tipo de lectura y escritura y de solo lectura. El tipo de transacción “lectura-escritura” incluye todas las transacciones de lectura y escritura, y el tipo “solo lectura” incluye todas las transacciones de solo lectura y métodos de lectura única.

Al igual que las métricas de latencia, estos gráficos agrupan los datos en percentiles. Puedes ver la métrica Latencia por tipo de transacción para el percentil 50 y la latencia del percentil 99.

Una diferencia importante entre la métrica Latencia y la métrica Latencia por tipo de transacción es que el gráfico de Latencia por tipo de transacción te permite desglosar el tipo de transacción de solo lectura por “El líder está involucrado” o “No hay líderes involucrados”. Si seleccionas “El líder está involucrado”, se muestra un gráfico que incluye las solicitudes que involucraron al líder. Por ejemplo, si se solicita una lectura sólida de una réplica de solo lectura, se consulta al líder para garantizar que la réplica de solo lectura tenga los datos más recientes. En este caso, seleccionar “Leader isvolved” ayuda a evaluar la cantidad total de tiempo que tardó en procesarse la transacción de lectura sólida. Si seleccionas "No hay ningún líder involucrado", el gráfico muestra las lecturas en las que no hubo ningún líder. Por ejemplo, si se solicita una réplica inactiva con límite de marca de tiempo configurado en al menos 15 segundos desde una réplica de solo lectura, es posible que la réplica de solo lectura entregue la lectura inactiva sin involucrar al líder. En comparación, las lecturas que involucran a la líder pueden experimentar una latencia más alta. Puedes usar estos gráficos para evaluar la diferencia en la latencia entre lecturas sólidas y lecturas inactivas. Ten en cuenta que, en algunos casos, una lectura inactiva también puede entregarse un líder y, en esos casos, las lecturas inactivas aparecerán en el gráfico “El líder está involucrado”.

Para las transacciones de lectura y escritura, el líder siempre está involucrado en la transacción, por lo que los datos que se muestran en el gráfico siempre incluyen el tiempo que le llevó a la solicitud llegar al líder y recibir una respuesta.

Cómo diagnosticar problemas de latencia

En las siguientes secciones, se describe cómo diagnosticar varios problemas comunes que podrían provocar que la aplicación experimente una latencia alta de extremo a extremo.

Para obtener una vista rápida de las métricas de latencia de una instancia, usa Google Cloud Console. Para examinar las métricas más de cerca y encontrar correlaciones entre la latencia y otras métricas, usa la consola de Cloud Monitoring.

Latencia alta total, latencia baja de Spanner

Si tu aplicación experimenta una latencia mayor que la esperada, pero las métricas de latencia de Spanner son significativamente más bajas que la latencia total de extremo a extremo, es posible que haya un problema en el código de la aplicación. Si tu aplicación tiene un problema de rendimiento que hace que algunas rutas de código sean lentas, la latencia total de extremo a extremo de cada solicitud puede aumentar.

A fin de comprobar este problema, compara tu aplicación para identificar rutas de código más lentas de lo esperado.

También puedes comentar el código que se comunica con Spanner y, luego, volver a medir la latencia total. Si la latencia total no cambia mucho, es poco probable que Spanner sea la causa de la latencia alta.

Latencia alta total, latencia alta de Spanner

Si tu aplicación experimenta una latencia que es más alta de lo esperado y las métricas de latencia de Spanner también son altas, existen algunas causas posibles:

  • Tu instancia necesita más capacidad de procesamiento. Si tu instancia no tiene suficientes recursos de CPU, y su uso de CPU supera el máximo recomendado, es posible que Spanner no pueda procesar tus solicitudes con rapidez y eficiencia.

  • Algunas de tus consultas causan un uso de CPU elevado. Si tus consultas no aprovechan las características de Spanner que mejoran la eficiencia, como los parámetros de consulta y los índices secundarios, o si incluyen una gran cantidad de uniones o de otras operaciones de uso intensivo de CPU, las consultas pueden usar una gran parte de los recursos de CPU para tu instancia.

Para comprobar estos problemas, usa la consola de Cloud Monitoring a fin de buscar una correlación entre el uso elevado de CPU y la latencia alta. Además, verifica las estadísticas de consulta de tu instancia para identificar las consultas que requieren mucha CPU durante el mismo período.

Si descubres que la latencia y el uso de CPU son altos al mismo tiempo, toma las medidas necesarias para solucionar el problema:

¿Qué sigue?