Cuando representas gráficamente el rendimiento a lo largo del tiempo a medida que se modifica otra variable, normalmente el rendimiento aumenta hasta que se agotan los recursos.
En la siguiente figura se muestra un gráfico de escalado de rendimiento típico. A medida que aumenta el número de clientes, la carga de trabajo y el rendimiento también aumentan hasta que se agotan todos los recursos.
Lo ideal es que, al duplicar la carga del sistema, el rendimiento también se duplique. En la práctica, habrá una contención de recursos que provocará aumentos de rendimiento menores. En algún momento, el agotamiento o la contención de recursos hará que el rendimiento se estabilice o incluso disminuya. Si estás optimizando el rendimiento, es fundamental que identifiques este punto, ya que te ayudará a centrar tus esfuerzos en ajustar la aplicación o el sistema de base de datos para mejorar el rendimiento.
Estos son algunos de los motivos habituales por los que el rendimiento puede estabilizarse o disminuir:
- Agotamiento de los recursos de CPU en el servidor de la base de datos
- Agotamiento de los recursos de CPU en el cliente, por lo que no se envía más trabajo al servidor de la base de datos
- Contención de bloqueo de base de datos
- Tiempo de espera de E/S cuando los datos superan el tamaño del grupo de búfer de PostgreSQL.
- Tiempo de espera de E/S debido a la utilización del motor de almacenamiento
- Cuellos de botella en el ancho de banda de la red al devolver datos al cliente
La latencia y el rendimiento son inversamente proporcionales. A medida que aumenta la latencia, disminuye el rendimiento. Intuitivamente, tiene sentido. Cuando empieza a producirse un cuello de botella, las operaciones tardan más y el sistema realiza menos operaciones por segundo.
El gráfico de escalado de latencia muestra cómo cambia la latencia a medida que aumenta la carga de un sistema. La latencia se mantiene relativamente constante hasta que se produce fricción debido a la contención de recursos. El punto de inflexión de esta curva suele corresponderse con el aplanamiento de la curva de rendimiento en el gráfico de escalado del rendimiento.
Otra forma útil de evaluar la latencia es mediante un histograma. En esta representación, agrupamos las latencias en contenedores y contamos cuántas solicitudes corresponden a cada contenedor.
Este histograma de latencia muestra que la mayoría de las solicitudes tardan menos de 100 milisegundos y que hay latencias superiores a 100 milisegundos. Conocer la causa de las solicitudes con latencias de cola más largas puede ayudar a explicar las variaciones en el rendimiento de la aplicación. Las causas de la cola larga de latencias aumentadas corresponden a las latencias aumentadas que se observan en el gráfico de escalado de latencia típico y al aplanamiento del gráfico de rendimiento.
El histograma de latencia es más útil cuando hay varias modalidades en una aplicación. Una modalidad es un conjunto normal de condiciones de funcionamiento. Por ejemplo, la mayoría de las veces, la aplicación accede a páginas que están en la caché de búfer. La mayoría de las veces, la aplicación actualiza las filas, pero puede haber varios modos. En ocasiones, la aplicación recupera páginas del almacenamiento, inserta filas nuevas o experimenta conflictos de bloqueo.
Cuando una aplicación se encuentra con estos diferentes modos de funcionamiento a lo largo del tiempo, el histograma de latencia muestra estas modalidades.
Esta cifra muestra un histograma bimodal típico en el que la mayoría de las solicitudes se atienden en menos de 100 milisegundos, pero hay otro clúster de solicitudes que tardan entre 401 y 500 milisegundos. Conocer la causa de esta segunda modalidad puede ayudarte a mejorar el rendimiento de tu aplicación. También puede haber más de dos modalidades.
La segunda modalidad puede deberse a operaciones normales de la base de datos, a una infraestructura y una topología heterogéneas o al comportamiento de la aplicación. Estos son algunos ejemplos que puedes tener en cuenta:
- La mayoría de los accesos a datos proceden del grupo de búferes de PostgreSQL, pero algunos proceden del almacenamiento.
- Diferencias en las latencias de red de algunos clientes al servidor de bases de datos
- Lógica de aplicación que realiza diferentes operaciones en función de la entrada o la hora del día
- Contención de bloqueo esporádica
- Picos en la actividad del cliente