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 requiere 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 mi consulta?
- ¿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 informa qué comparativa ejecutar, qué entorno es necesario 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 las pruebas tienen una gran variación, será difícil evaluar el impacto de los cambios que realizaste en la aplicación o 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. La ejecución 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 no suele ser 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 prueba siga siendo la misma entre las ejecuciones. Se acepta cierta aleatoriedad en la entrada de una prueba, siempre que 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 manera 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 estás probando sea representativa de tu aplicación. Si ejecutas 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 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 ofrecen 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 a 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 propagan las memorias caché y 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 de manera adversa 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 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 corta 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 por 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 mientras mantienes la carga constante. Si el servidor de la base de datos está subutilizado, intenta aumentar la carga mientras mantienes constante la configuración de la CPU.
Topología de red y latencias
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 la base de datos estén en la misma zona para minimizar la latencia de la red y obtener el mejor rendimiento, en especial para las aplicaciones con alta capacidad de procesamiento y transacciones cortas, ya que la latencia de la 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 sistemas. 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 quieras comprender mejor el impacto de las latencias entre zonas considerando una aplicación web típica de gran 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 del cliente, que reenvía cada solicitud a un servidor web de muchos. 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 de bases de datos.
Supervisión de recursos
Para optimizar el rendimiento de tu sistema de base de datos, debes supervisar el uso de recursos del sistema de base 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 base de datos. Es fundamental supervisar la utilización de recursos del sistema que estás probando. Supervisar la utilización de recursos de los sistemas cliente 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 base de datos antes de que se quede sin 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 base de datos. No podrás impulsar el sistema de base de datos lo suficiente 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. Algunos ejemplos de estudios de escalabilidad incluyen los siguientes:
- ¿Cómo afecta un aumento en la cantidad de solicitudes simultáneas a la capacidad de procesamiento y los tiempos de respuesta?
- ¿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 constan de 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 prueba informa las decisiones sobre qué cuellos de botella existen en el sistema, cuánta carga puede manejar el sistema con 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 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 para empezar, por lo que, para las comparativas, recomendamos usar tamaños de máquinas de cuatro CPU virtuales como mínimo.