Cuando compares el rendimiento, define qué quieres obtener de la prueba antes de empezar. Por ejemplo:
- ¿Cuál es el rendimiento máximo que puede alcanzar el sistema?
- ¿Cuánto tiempo tarda una consulta o una carga de trabajo concretas?
- ¿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 gestionar una base de datos antes de que deba plantearme actualizar a una máquina más potente?
Para saber qué prueba comparativa debes realizar, qué entorno necesitas y qué métricas debes recoger, es importante que conozcas los objetivos de tu estudio de rendimiento.
Repetibilidad
Para sacar conclusiones de las pruebas de rendimiento, los resultados deben ser repetibles. Si los resultados de las pruebas varían mucho, será difícil evaluar el impacto de los cambios que hayas hecho en la aplicación o en la configuración del sistema. Realizar pruebas varias veces o durante periodos más largos para obtener más datos puede ayudar a reducir la cantidad de variación.
Lo ideal es que las pruebas de rendimiento se realicen en sistemas aislados de otros sistemas. Si ejecutas pruebas en un entorno en el que los sistemas externos pueden afectar al rendimiento de tu aplicación, puedes llegar a conclusiones incorrectas. A menudo, no es posible conseguir un aislamiento completo cuando se ejecuta en un entorno de nube multiinquilino, por lo que es de esperar que los resultados varíen más.
Parte de la repetibilidad consiste en asegurarse de que la carga de trabajo de la prueba siga siendo la misma entre ejecuciones. Es aceptable que haya cierta aleatoriedad en la entrada de una prueba, siempre que no provoque un comportamiento significativamente diferente de la aplicación. Si la entrada del cliente generada aleatoriamente 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 estás haciendo pruebas sea representativa de tu aplicación. Si realizas pruebas con una pequeña cantidad de datos cuando tienes cientos de gigabytes o terabytes de datos, es probable que no obtengas una representación fiel 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 tabla que ofrecen un rendimiento deficiente a mayor escala, y no identificarás los índices que faltan 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 rellenan cachés y se generan procesos e hilos. Al inicio de una prueba de rendimiento, la inicialización de estos componentes podría consumir recursos del sistema y afectar negativamente al rendimiento medido si el tiempo de ejecución de la carga de trabajo es demasiado corto.
Te recomendamos que realices 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 incluyen 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 prueba comparativa breve que se completa antes del intervalo del punto de control, se 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 ha mejorado 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 la base de datos está sobreutilizado, prueba a cambiar a una máquina con más vCPUs manteniendo la carga constante. Si el servidor de la base de datos no se utiliza lo suficiente, prueba a aumentar la carga manteniendo constante la configuración de la CPU.
Topología y latencias de la red
La topología de red de tu sistema puede afectar a los resultados de la prueba de rendimiento. La latencia entre zonas es diferente. Cuando se realizan pruebas de rendimiento, asegurarse de que el cliente y el clúster de bases de datos estén en la misma zona minimiza la latencia de la red y ofrece el mejor rendimiento, especialmente en el caso de las aplicaciones con un alto rendimiento y transacciones cortas, ya que la latencia de la red puede ser un componente importante del tiempo de respuesta general de las transacciones.
Al comparar el rendimiento de dos sistemas diferentes, asegúrate de que la topología de red sea la misma en ambos sistemas. Ten en cuenta que la variabilidad de la latencia de la red no se puede eliminar por completo. Incluso en la misma zona, puede haber diferencias en la latencia debido a las topologías de red subyacentes.
Al implementar su aplicación, puede que le interese conocer mejor el impacto de las latencias entre zonas. Para ello, puede considerar una aplicación web típica de gran volumen. La aplicación tiene un balanceador de carga que envía solicitudes a varios servidores web desplegados en varias zonas para conseguir una alta disponibilidad. Las latencias pueden variar en función del 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 carga gestiona 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 están en una zona diferente de donde se ejecuta AlloyDB Omni y experimentarán latencias más altas al hacer solicitudes de bases de datos.
Monitorización de recursos
Para optimizar el rendimiento de su sistema de base de datos, debe monitorizar el uso de recursos tanto del sistema de base de datos como de los sistemas cliente que lo utilizan. Si monitorizas 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 monitorizar la utilización de recursos del sistema que estás probando. También es importante monitorizar la utilización de recursos de los sistemas cliente que usas para gestionar la carga de trabajo. Por ejemplo, si quieres determinar el número máximo de clientes que puede admitir tu sistema de base de datos antes de quedarse sin recursos de CPU, necesitarás suficientes sistemas cliente para generar la carga de trabajo necesaria para agotar todos los recursos de CPU del sistema de base de datos. No podrá exigir lo suficiente al sistema de base de datos si los ordenadores 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 influye el aumento del número de solicitudes simultáneas en el rendimiento y los tiempos de respuesta?
- ¿Cómo afecta el aumento del tamaño de la base de datos al rendimiento y a los tiempos de respuesta?
Las pruebas de escalabilidad constan de varias ejecuciones de una carga de trabajo en las que se varía una sola dimensión entre las ejecuciones y se recogen y representan una o varias métricas. Este tipo de pruebas proporciona información sobre los cuellos de botella del sistema, la carga que puede gestionar con una configuración específica, la carga máxima que puede admitir y el comportamiento del sistema cuando la carga supera esos niveles.
Consideraciones sobre el tamaño de la máquina
AlloyDB Omni incorpora muchas funciones nuevas a Postgres para mejorar la fiabilidad y la disponibilidad de la base de datos. La monitorización necesaria para hacerlo 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 desde el principio, por lo que, para realizar pruebas comparativas, recomendamos usar tamaños de máquina de cuatro vCPUs como mínimo.