Cuando compares el 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?
- ¿En cuánto reduce el motor de columnas el tiempo de respuesta del rendimiento de mis consultas?
- ¿Cuánta carga puede controlar 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é comparativa ejecutar, qué entorno se requiere y qué métricas debes recopilar.
Repetibilidad
Para sacar conclusiones de las pruebas de rendimiento, los resultados deben ser repetibles. Si los resultados de las 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 largos para proporcionar más datos puede ayudar a reducir la cantidad de variación.
Lo ideal es que las pruebas de rendimiento se ejecuten en sistemas aislados de otros sistemas. Ejecutar pruebas en un entorno en el que los sistemas externos pueden afectar el rendimiento de tu aplicación puede llevar a conclusiones incorrectas. El aislamiento completo a menudo no es posible cuando se ejecuta en un entorno de nube de múltiples usuarios, por lo que debes esperar una mayor variabilidad en los resultados.
Parte de la repetibilidad es garantizar que la carga de trabajo de la 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 significativamente diferente de la aplicación. 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á significativamente.
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 te dará una representación real del rendimiento de tu aplicación. El tamaño del conjunto de datos también influye en las decisiones que toma el optimizador de consultas. Las consultas en tablas de prueba pequeñas pueden usar análisis de tablas que brindan un rendimiento bajo a mayor escala, 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, se mantiene mucha información de estado a medida que se ejecuta el sistema: se establecen conexiones de bases de datos, se completan cachés, 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 del calentamiento 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. Ejecutar una comparativa de referencia corta que se complete antes del intervalo de puntos 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 el beneficio de un cambio adecuado. Si el servidor de la base de datos está sobreutilizado, intenta cambiar a una máquina con más CPU virtuales y mantén la carga constante. Si el servidor de la base de datos no se utiliza lo suficiente, intenta aumentar la carga y mantener constante la configuración de la CPU.
Topología y latencias de la 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 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, 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 la 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 desees 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 una 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 y 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 experimentará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 utilizan. 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 la utilización de recursos del sistema que estás probando. También es importante supervisar la utilización de recursos de los sistemas cliente que usas para controlar la carga de trabajo. Por ejemplo, si deseas determinar la cantidad máxima de clientes que puede admitir tu sistema de bases de datos antes de que se agoten los recursos de CPU, necesitarás suficientes sistemas cliente para generar la carga de trabajo necesaria para usar todos los recursos de CPU en el sistema de bases de datos. No podrás exigirle lo suficiente al 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 afecta el aumento en la cantidad de solicitudes simultáneas a la capacidad de procesamiento y los tiempos de respuesta?
- ¿Cómo afecta el aumento del tamaño de la base de datos al procesamiento y los tiempos de respuesta?
Las pruebas de escalabilidad consisten en varias ejecuciones de una carga de trabajo en las que se varía una sola dimensión entre las ejecuciones y se recopilan y registran una o más métricas. Este tipo de prueba proporciona información para tomar 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 introduce muchas funciones nuevas en Postgres para mejorar la confiabilidad y la disponibilidad de la base de datos. El monitoreo necesario para esto usa recursos en la máquina que ejecuta AlloyDB Omni. En los tamaños de máquinas muy pequeños, los recursos de CPU y memoria son limitados desde el principio, por lo que, para realizar comparativas, recomendamos usar tamaños de máquinas de cuatro CPU virtuales como mínimo.