Cuando realices comparativas de rendimiento, define qué esperas aprender de la prueba antes de comenzar. Por ejemplo:
- ¿Cuál es la capacidad de procesamiento máxima que puede alcanzar el sistema?
- ¿Cuánto tiempo tarda una consulta o carga de trabajo en particular?
- ¿Cómo cambia el rendimiento a medida que aumenta la cantidad de datos?
- ¿Cómo se compara el rendimiento de dos sistemas diferentes?
- ¿Cuánto reduce el motor de columnas el tiempo de respuesta del rendimiento de mis consultas?
- ¿Cuánta carga puede soportar una base de datos antes de que deba considerar actualizarla a una máquina más potente?
Comprender los objetivos de tu estudio de rendimiento te permite saber qué comparativas ejecutar, qué entorno se requiere y qué métricas debes recopilar.
Repetibilidad
Para sacar conclusiones de las pruebas de rendimiento, los resultados de las pruebas deben ser repetibles. Si los resultados de tus pruebas tienen una gran variación, será difícil evaluar el impacto de los cambios que realizaste en la aplicación o en la configuración del sistema. Ejecutar pruebas varias veces o durante períodos más prolongados para proporcionar más datos puede ayudar a reducir el importe de la variación.
Idealmente, las pruebas de rendimiento se deben ejecutar en sistemas que estén aislados de otros sistemas. Ejecutar la prueba en un entorno en el que los sistemas externos pueden afectar el rendimiento de tu aplicación puede llevarte a sacar conclusiones incorrectas. A menudo, no es posible lograr un aislamiento completo cuando se ejecuta en un entorno de nube multiusuario, por lo que debes esperar ver una mayor variabilidad en los resultados.
Parte de la repetibilidad es garantizar que la carga de trabajo de prueba permanezca igual entre las ejecuciones. Se acepta cierta aleatoriedad en la entrada de una prueba, siempre y cuando no cause un comportamiento de la aplicación significativamente diferente. Si la entrada del cliente generada de forma aleatoria cambia la combinación de lecturas y escrituras de una ejecución a otra, el rendimiento variará de forma significativa.
Tamaño de la base de datos, almacenamiento en caché y patrones de E/S
Asegúrate de que la cantidad de datos con la que realizas las pruebas sea representativa de tu aplicación. Ejecutar pruebas con una pequeña cantidad de datos cuando tienes cientos de gigabytes o terabytes de datos probablemente no dará una representación real del rendimiento de tu aplicación. El tamaño del conjunto de datos también influye en las elecciones que realiza el optimizador de consultas. Las consultas en tablas de prueba pequeñas pueden usar análisis de tablas que tienen un rendimiento deficiente en escalas más grandes, y no identificarás los índices faltantes en esta configuración.
Intenta replicar los patrones de E/S de tu aplicación. La proporción de lecturas y escrituras es importante para el perfil de rendimiento de tu aplicación.
Duración de la comparativa
En un sistema complejo, hay mucha información de estado que se mantiene a medida que se ejecuta el sistema: se establecen conexiones de base de datos, se propagan las cachés y se generan procesos y subprocesos. Al comienzo de una prueba de rendimiento, la inicialización de estos componentes podría consumir recursos del sistema y afectar negativamente el rendimiento medido si el tiempo de ejecución de la carga de trabajo es demasiado corto.
Te recomendamos que ejecutes pruebas de rendimiento durante al menos 20 minutos para minimizar los efectos de la preparación del sistema. Mide el rendimiento durante un estado estable después del inicio y durante el tiempo suficiente para garantizar que se incluyan todos los aspectos de las operaciones de la base de datos. Por ejemplo, los puntos de control de la base de datos son una función fundamental de los sistemas de bases de datos y pueden tener un impacto significativo en el rendimiento. Si ejecutas una comparativa breve que se completa antes del intervalo de puntos de control, se ocultará este factor importante en el comportamiento de tu aplicación.
Pruebas metódicas
Cuando ajustes el rendimiento, cambia solo una variable a la vez. Si cambias varias variables entre ejecuciones, no podrás aislar la variable que mejoró el rendimiento. De hecho, varios cambios pueden compensarse entre sí, por lo que no verás el beneficio de un cambio adecuado. Si el servidor de la base de datos se usa en exceso, intenta cambiar a una máquina con más CPU virtuales mientras mantienes la carga constante. Si el servidor de la base de datos está infrautilizado, intenta aumentar la carga mientras mantienes constante la configuración de la CPU.
Topología y latencias de red
La topología de red de tu sistema puede afectar los resultados de la prueba de rendimiento. La latencia entre las zonas varía. Cuando se realizan pruebas de rendimiento, asegurarse de que el cliente y el clúster de la base de datos estén en la misma zona minimiza la latencia de red y produce el mejor rendimiento, en especial para las aplicaciones con alta capacidad de procesamiento y transacciones cortas, ya que la latencia de red puede ser un componente importante del tiempo de respuesta general de la transacción.
Cuando compares el rendimiento de dos sistemas diferentes, asegúrate de que la topología de red sea la misma para ambos. Ten en cuenta que la variabilidad de la latencia de red no se puede eliminar por completo, incluso dentro de la misma zona puede haber diferencias en la latencia debido a las topologías de red subyacentes.
Cuando implementes tu aplicación, es posible que quieras comprender mejor el impacto de las latencias entre zonas considerando una aplicación web típica de alto volumen. La aplicación tiene un balanceador de cargas que envía solicitudes a varios servidores web implementados en varias zonas para lograr alta disponibilidad. Las latencias pueden variar según el servidor web que procese una solicitud debido a las diferencias de latencia entre zonas.
En la siguiente figura, se muestra la arquitectura típica de una aplicación web que usa AlloyDB Omni. Un balanceador de cargas controla las solicitudes de los clientes y reenvía cada una a uno de los muchos servidores web. Todos los servidores web están conectados a AlloyDB Omni. Algunos servidores se encuentran en una zona diferente de donde se ejecuta AlloyDB Omni y tendrán latencias más altas cuando realicen solicitudes a la base de datos.
Supervisión de recursos
Para optimizar el rendimiento de tu sistema de base de datos, debes supervisar el uso de recursos tanto del sistema de base de datos como de los sistemas cliente que lo usan. Si supervisas ambos sistemas, puedes asegurarte de que los sistemas cliente proporcionen suficiente carga de trabajo para obtener mediciones significativas en el sistema de base de datos. Es fundamental supervisar el uso de recursos del sistema que estás probando. Supervisar el uso de recursos de los sistemas cliente que usas para impulsar la carga de trabajo es igual de importante. Por ejemplo, si quieres determinar la cantidad máxima de clientes que puede admitir tu sistema de base de datos antes de que se agoten los recursos de CPU, necesitarás suficientes sistemas de clientes para generar la carga de trabajo necesaria para usar todos los recursos de CPU en el sistema de base de datos. No podrás exigir lo suficiente al sistema de base de datos si las máquinas cliente que generan la carga no tienen suficiente CPU.
Pruebas de escalabilidad
Las pruebas de escalabilidad son otro aspecto de las pruebas de rendimiento. La escalabilidad se refiere a cómo cambian las métricas de rendimiento a medida que varía una característica de una carga de trabajo. Estos son algunos ejemplos de estudios de escalabilidad:
- ¿Cómo cambia la capacidad de procesamiento y los tiempos de respuesta cuando aumenta la cantidad de solicitudes simultáneas?
- ¿Cómo afecta un aumento en el tamaño de la base de datos a la capacidad de procesamiento y los tiempos de respuesta?
Las pruebas de escalabilidad consisten en varias ejecuciones de una carga de trabajo en la que se varía una sola dimensión entre las ejecuciones y se recopilan y trazan una o más métricas. Este tipo de pruebas fundamenta las decisiones sobre qué cuellos de botella existen en el sistema, cuánta carga puede manejar el sistema según una configuración específica, la carga máxima que puede admitir un sistema y cuál es el comportamiento del sistema cuando la carga aumenta más allá de esos niveles.
Consideraciones sobre el tamaño de la máquina
AlloyDB Omni presenta muchas funciones nuevas para Postgres que mejoran la confiabilidad y la disponibilidad de la base de datos. La supervisión necesaria para hacer esto usa recursos en la máquina que ejecuta AlloyDB Omni. En los tamaños de máquina muy pequeños, los recursos de memoria y CPU son limitados para empezar, por lo que, para realizar comparativas, recomendamos usar tamaños de máquina de cuatro CPUs virtuales como mínimo.