En este documento, se describen las recomendaciones para ejecutar pruebas de rendimiento en AlloyDB Omni en una VM. En este documento, se supone que estás familiarizado con PostgreSQL.
Cuando realices comparativas de rendimiento, define lo que 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 demora 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?
- ¿En cuánto reduce el motor de columnas el tiempo de respuesta del rendimiento de mis consultas?
- ¿Cuánta carga puede manejar una base de datos antes de que deba considerar actualizar a una máquina más potente?
Comprender los objetivos de tu estudio de rendimiento te permite saber qué comparativa ejecutar, qué entorno se requiere y qué métricas debes recopilar.
Reproducibilidad
Para sacar conclusiones de las pruebas de rendimiento, los resultados de las pruebas deben ser repetibles. Si los resultados de la prueba 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 largos para proporcionar más datos puede ayudar a reducir el importe de la variación.
Lo ideal es que las pruebas de rendimiento se ejecuten en sistemas aislados de otros. Ejecutar una prueba en un entorno en el que los sistemas externos pueden afectar el rendimiento de tu aplicación puede llevar a 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 siga siendo la misma entre las ejecuciones. Se acepta cierta aleatoriedad en la entrada de una prueba, siempre y cuando no cause un comportamiento de la aplicación muy diferente. Si la entrada del cliente generada de forma aleatoria cambia la combinación de operaciones de lectura y escritura 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 la prueba sea representativa de tu aplicación. Es probable que ejecutar pruebas con una pequeña cantidad de datos cuando tienes cientos de gigabytes o terabytes de datos no proporcione 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 a tablas de prueba pequeñas pueden usar análisis de tablas que tienen un rendimiento bajo a escalas más grandes y no identificarás los índices faltantes en esta configuración.
Esfuérzate por replicar los patrones de E/S de tu aplicación. La proporción de operaciones de lectura y escritura 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, se generan procesos y subprocesos. Al comienzo de una prueba de rendimiento, la inicialización de estos componentes podría ocupar 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 del calentamiento del sistema. Mide el rendimiento durante un estado estable después del inicio y durante el tiempo suficiente para asegurarte de 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. Ejecutar una comparativa breve que se complete antes del intervalo del punto de control oculta 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 qué variable mejoró el rendimiento. De hecho, varios cambios pueden compensarse entre sí, por lo que no verás los beneficios de un cambio adecuado. Si el servidor de base de datos está sobrecargado, intenta cambiar a una máquina con más CPU virtuales y mantén la carga constante. Si el servidor de base de datos no se usa por completo, intenta aumentar la carga y mantener 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 difiere. Cuando realices pruebas de rendimiento, asegúrate de que el cliente y el clúster de bases de datos estén en la misma zona para minimizar la latencia de red y obtener el mejor rendimiento, especialmente para aplicaciones con transacciones cortas y alta capacidad de procesamiento, 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 no se puede eliminar por completo la variabilidad de la latencia de la red. 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, te recomendamos que consideres una aplicación web típica de alto volumen para comprender mejor el impacto de las latencias entre zonas. 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 diferir 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, que reenvía cada solicitud 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 la que 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 del sistema de bases de datos, debes supervisar el uso de recursos del sistema de bases de datos y 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 bases de datos. Es fundamental supervisar el uso de recursos del sistema que estás probando. Supervisar el uso de recursos de los sistemas de clientes que usas para impulsar la carga de trabajo es igual de importante. Por ejemplo, si deseas determinar la cantidad máxima de clientes que puede admitir tu sistema de bases de datos antes de que se le agoten los recursos de la CPU, necesitarás suficientes sistemas de clientes para generar la carga de trabajo necesaria para agotar todos los recursos de la CPU en el sistema de bases de datos. No podrás aprovechar al máximo el sistema de bases de datos si las máquinas cliente que generan 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 un aumento en la cantidad de solicitudes simultáneas?
- ¿Cómo cambia el aumento del tamaño de la base de datos el rendimiento 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 grafican una o más métricas. Este tipo de pruebas informa las decisiones sobre los cuellos de botella que existen en el sistema, la cantidad de carga que puede manejar el sistema con una configuración específica, la carga máxima que puede admitir un sistema y 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 en Postgres para mejorar la confiabilidad y la disponibilidad de la base de datos. La supervisión necesaria para hacerlo usa recursos en la máquina que ejecuta AlloyDB Omni. En tamaños de máquinas muy pequeños, los recursos de memoria y CPU son limitados, por lo que, para las comparativas, recomendamos usar tamaños de máquinas de cuatro CPU virtuales como mínimo.