Procedimientos recomendados para realizar pruebas comparativas del rendimiento de Azure Database for MySQL: servidor flexible

2024-11-27

El rendimiento es un distintivo de cualquier aplicación y es fundamental definir una estrategia clara para analizar y evaluar el rendimiento de una base de datos al controlar los requisitos de carga de trabajo variables de una aplicación.

En este artículo se proporcionan consideraciones y procedimientos recomendados para ejecutar pruebas comparativas de rendimiento en el servidor flexible de Azure Database for MySQL.

Pruebas de rendimiento

La realización de pruebas comparativas del rendimiento de los sistemas de bases de datos relacionales puede parecer, a primera vista, una tarea trivial. Después de todo, es relativamente fácil evaluar el rendimiento de las consultas individuales manualmente e incluso iniciar pruebas sintéticas simples mediante una de las herramientas de pruebas comparativas disponibles. Estos tipos de pruebas tardan poco tiempo y generan rápidamente resultados fáciles de entender.

Sin embargo, la prueba comparativa del rendimiento de los sistemas de producción del mundo real requiere mucho esfuerzo adicional. No es fácil diseñar, implementar y ejecutar pruebas que sean verdaderamente representativas de las cargas de trabajo de producción. Es aún más difícil tomar decisiones sobre las pilas de datos de producción en función de los resultados de una serie de pruebas comparativas que se realizan en un entorno aislado.

Metodologías de pruebas de rendimiento

Pruebas comparativas sintéticas

Las pruebas sintéticas están diseñadas para someter a estrés un sistema de base de datos mediante muestras artificiales de carga de trabajo que simulan resultados repetibles en un entorno de base de datos. Esto permite a los clientes realizar comparaciones entre varios entornos para medir el recurso de base de datos adecuado para sus implementaciones de producción.

Hay varias ventajas asociadas al uso de pruebas comparativas sintéticas. Por ejemplo, pueden:

Son predecibles, repetibles y permiten pruebas selectivas (por ejemplo, pruebas de solo escritura, pruebas de solo lectura, una combinación de pruebas de escritura y lectura, y pruebas dirigidas contra una tabla).
Proporcionan resultados generales que se pueden representar mediante métricas simples (por ejemplo, "consultas por segundo", "transacciones por segundo", etc.).
No requieren conocimientos específicos de la aplicación o del entorno para construirse y ejecutarse.
Se puede realizar rápidamente y sin apenas preparación. Sin embargo, también hay inconvenientes asociados, como que:
Los ejemplos de cargas de trabajo artificiales no son representativos del tráfico de aplicaciones del mundo real.
Los resultados no se pueden usar para predecir con precisión el rendimiento de las cargas de trabajo de producción.
Es posible que no expongan características de rendimiento específicas del producto cuando se usan para probar diferentes productos de base de datos.
Es fácil realizar las pruebas incorrectamente y generar resultados que sean aún menos representativos.

Las pruebas sintéticas son útiles para realizar comparaciones rápidas entre productos. También puede usarlas para implementar mecanismos de supervisión continua del rendimiento. Por ejemplo, puede ejecutar un conjunto de pruebas cada fin de semana para validar el rendimiento de línea base del sistema de base de datos, detectar anomalías y predecir patrones de rendimiento a largo plazo (por ejemplo, degradación de la latencia de consulta como resultado del crecimiento de los datos).

Pruebas comparativas reales

Con las pruebas reales, la base de datos se presenta con ejemplos de cargas de trabajo que se asemejan mucho al tráfico de producción. Para lograrlo directamente, se puede reproducir un registro de consultas de producción y medir el rendimiento de la base de datos. También se puede lograr esto indirectamente, ejecutando la prueba a nivel de aplicación y midiendo el rendimiento de la aplicación en un servidor de base de datos determinado.

El uso de pruebas comparativas reales tiene varias ventajas:

Proporciona una vista precisa del rendimiento del sistema en condiciones de producción reales.
Pueden revelar características específicas de la aplicación o de la base de datos que las pruebas sintéticas simplificadas no revelarían.
Ayuda con el planeamiento de capacidad relacionado con el crecimiento de las aplicaciones.

También hay ciertas desventajas en el uso de pruebas comparativas reales:

Son difíciles de diseñar y ejecutar.
Deben mantenerse para garantizar la relevancia a medida que evoluciona la aplicación.
Proporcionan resultados que son significativos solo en el contexto de una aplicación determinada.

Al prepararse para un cambio importante en el entorno, por ejemplo, implementar un nuevo producto de base de datos, se recomienda usar pruebas reales. En tal situación, una prueba comparativa exhaustiva con la carga de trabajo real de producción es de gran ayuda. No solo proporcionará resultados precisos en los que puede confiar, sino que también eliminará o, al menos, reducirá considerablemente el número de "desconocimientos" sobre el sistema.

Elección de la metodología de prueba "correcta"

La metodología de prueba "correcta" para sus propósitos depende completamente del objetivo de las pruebas.

Si quiere comparar rápidamente diferentes productos de base de datos mediante ejemplos de carga de trabajo y datos artificiales, puede usar de forma segura un programa de pruebas comparativas existente que genere datos y ejecute la prueba automáticamente.

Para evaluar con precisión el rendimiento de una aplicación real que pretende ejecutar en un nuevo producto de base de datos, debe realizar pruebas comparativas reales. Cada aplicación tiene un conjunto único de requisitos y características de rendimiento, y se recomienda incluir pruebas comparativas reales en todas las evaluaciones de rendimiento.

Para instrucciones sobre cómo preparar y ejecutar pruebas comparativas sintéticas y reales, consulte las secciones siguientes más adelante en esta publicación:

Preparación y ejecución de pruebas sintéticas
Preparación y ejecución de pruebas reales

Procedimientos recomendados de pruebas de rendimiento

Recomendaciones específicas del servidor

Ajuste de tamaño del servidor

Al iniciar instancias de servidor flexible de Azure Database for MySQL para realizar pruebas comparativas, use un nivel de instancia de servidor flexible de Azure Database for MySQL, una SKU y un recuento de instancias que coincidan con el entorno de base de datos actual.

Por ejemplo:

Si el servidor actual tiene ocho núcleos de CPU y 64 GB de memoria, es mejor elegir una instancia basada en la SKU Standard_E8ds_v4.
Si el entorno de base de datos actual usa réplicas de lectura, use réplicas de lectura de servidor flexible de Azure Database for MySQL.

En función de los resultados de las pruebas comparativas, puede decidir usar diferentes tamaños y recuentos de instancias en producción. Sin embargo, sigue siendo un procedimiento recomendado asegurarse de que las especificaciones iniciales de las instancias de prueba se acercan a las especificaciones de su servidor actual para proporcionar una comparación más precisa y "de igual a igual".

Configuración del servidor

Si la aplicación o la prueba comparativa requiere que se habiliten ciertas características de base de datos, antes de ejecutar la prueba comparativa, ajuste los parámetros del servidor como corresponda. Por ejemplo, podría ser necesario:

Establecer una zona horaria de servidor no predeterminada.
Establecer un parámetro personalizado "max_connections" si el valor predeterminado no es suficiente.
Configure el grupo de subprocesos si la instancia del servidor flexible de Azure Database for MySQL ejecuta la versión 8.0.
Habilitar los registros de consultas lentas si espera usarlos en producción para poder analizar las consultas de cuello de botella.

Otros parámetros, como los relacionados con el tamaño de varios búferes y cachés de base de datos, ya están preajustados en el servidor flexible de Azure Database for MySQL y puede dejarlos inicialmente establecidos en sus valores predeterminados. Aunque puede modificarlos, es mejor evitar realizar cambios en los parámetros del servidor a menos que las pruebas comparativas de rendimiento muestren que un cambio determinado mejora realmente el rendimiento.

Al realizar pruebas que comparan el servidor flexible de Azure Database for MySQL con otros productos de base de datos, asegúrese de habilitar todas las características que espera usar en producción en las bases de datos de prueba. Por ejemplo, si no habilita la alta disponibilidad con redundancia de zona, las copias de seguridad y las réplicas de lectura en el entorno de prueba, es posible que los resultados no reflejen con precisión el rendimiento real.

Recomendaciones específicas del cliente

Todas las pruebas comparativas de rendimiento implican el uso de un cliente, por lo que independientemente de la metodología de pruebas comparativas elegida, asegúrese de tener en cuenta las siguientes recomendaciones del lado cliente.

Asegúrese de que existen instancias de cliente en la misma instancia de Azure Virtual Network (VNet) que la instancia de servidor flexible de Azure Database for MySQL que está probando. En el caso de aplicaciones sensibles a la latencia, se recomienda colocar instancias de cliente en la misma zona de disponibilidad (AZ) que el servidor de bases de datos.
Si se espera que una aplicación de producción se ejecute en varias instancias (por ejemplo, una flota de servidores de aplicaciones detrás de una instancia de Load Balancer), se recomienda usar varias instancias de cliente al realizar la prueba comparativa.
Asegúrese de que todas las instancias de cliente tengan una capacidad de proceso, memoria, E/S y red adecuadas para controlar la prueba comparativa. En otras palabras, los clientes deben poder generar solicitudes más rápido de lo que el motor de base de datos puede administrarlas. Todos los sistemas operativos proporcionan herramientas de diagnóstico (como "top", "htop", "dstat" o "iostat" en Linux) que pueden ayudarle a diagnosticar el uso de recursos en las instancias de cliente. Se recomienda usar estas herramientas y asegurarse de que todas las instancias de cliente siempre tengan capacidad de CPU, memoria, red y E/S de reserva mientras se ejecuta la prueba comparativa.

Incluso con una SKU grande, es posible que una única instancia de cliente no siempre pueda generar solicitudes lo suficientemente rápido como para saturar la base de datos. En función de la configuración de prueba, El servidor flexible de Azure Database for MySQL puede controlar cientos de miles de solicitudes de lectura y escritura por segundo, lo que puede ser más de un solo cliente. Para evitar la contención del lado cliente durante pruebas de rendimiento intensivas, es una práctica habitual ejecutar una prueba comparativa desde varias instancias de cliente en paralelo.

Importante

Si va a realizar pruebas comparativas de la aplicación mediante un script generador de tráfico o una herramienta de terceros (como Apache Benchmark, Apache JMeter o Siege), también debe evaluar el caso en el que la herramienta se ejecuta con las recomendaciones señaladas anteriormente.

Preparación y ejecución de pruebas sintéticas

Las herramientas de pruebas comparativas sintéticas, como sysbench, son fáciles de instalar y ejecutar, pero normalmente requieren un cierto grado de configuración y ajuste para que una prueba comparativa determinada pueda lograr resultados óptimos.

Recuento y tamaño de tabla

El número y el tamaño de las tablas generadas antes de realizar pruebas comparativas deben ser grandes. Por ejemplo, es poco probable que las pruebas realizadas en una sola tabla con 100 000 filas produzcan resultados útiles porque es probable que dicho conjunto de datos sea menor que prácticamente cualquier base de datos real. En comparación, una prueba comparativa que usa varias tablas (por ejemplo, de 10 a 25) con 5 millones de filas cada una podría ser una representación más realista de la carga de trabajo en tiempo real.

Modo de prueba

Con la mayoría de las herramientas de pruebas comparativas (incluida la conocida sysbench), puede definir el tipo de carga de trabajo que quiere ejecutar en el servidor. Por ejemplo, la herramienta puede generar:

Consultas de solo lectura con sintaxis idéntica, pero parámetros diferentes.
Consultas de solo lectura de diferentes tipos (selecciones de punto, selecciones de intervalo, selecciones con ordenación, etc.).
Instrucciones de solo escritura que modifican filas individuales o intervalos de filas.
Combinación de instrucciones de lectura y escritura.

Puede usar cargas de trabajo de solo lectura o de solo escritura si quiere probar el rendimiento y la escalabilidad de la base de datos en estos escenarios específicos. Sin embargo, una prueba comparativa representativa debería incluir una buena combinación de instrucciones de lectura y escritura, ya que este es el tipo de carga de trabajo que la mayoría de las bases de datos OLTP tienen que administrar.

Nivel de simultaneidad

El nivel de simultaneidad es el número de subprocesos que ejecutan simultáneamente operaciones en la base de datos. La mayoría de las herramientas de pruebas comparativas usan un único subproceso de forma predeterminada, que no es representativo de los entornos de base de datos reales, ya que las bases de datos rara vez las usa un solo cliente a la vez.

Para probar el rendimiento máximo teórico de una base de datos, use el siguiente proceso:

Ejecute varias pruebas con un recuento de subprocesos diferente para cada prueba. Por ejemplo, comience con 32 subprocesos y, luego, aumente el número de subprocesos para cada prueba subsiguiente (64, 128, 256, etc.).
Continúe aumentando el número de subprocesos hasta que se estabilice el rendimiento de la base de datos: este es el rendimiento teórico máximo.
Cuando determine que el rendimiento de la base de datos deja de aumentar a un nivel de concurrencia determinado, puede intentar aumentar el número de hilos un par de veces más, lo que mostrará si el rendimiento permanece estable o comienza a degradarse. Para más información, consulte la entrada de blog Prueba comparativa de Azure Database for MySQL: servidor flexible con Sysbench.

Preparación y ejecución de pruebas reales

Cada aplicación es única en términos de características de datos y requisitos de rendimiento. Como resultado, es difícil presentar una única lista universal de pasos que sería suficiente para preparar y ejecutar una prueba comparativa representativa y real en un entorno de base de datos arbitrario.

Las ideas presentadas en esta sección están pensadas para facilitar un poco los proyectos de pruebas de rendimiento.

Preparación de los datos de prueba

Antes de realizar pruebas comparativas de rendimiento en el servidor flexible de Azure Database for MySQL, asegúrese de que el servidor se rellena con un ejemplo representativo del conjunto de datos de producción.

Siempre que sea posible, use una copia completa del conjunto de producción. Cuando esto no sea posible, use las siguientes sugerencias para ayudarse a determinar qué partes de los datos debe incluir siempre y qué datos puede dejar.

El servidor de pruebas debe incluir todos los objetos (es decir, esquemas, tablas, funciones y procedimientos) que la prueba comparativa usa directamente. Cada tabla debe rellenarse completamente, es decir, debe contener todas las filas que contiene en producción. Si las tablas no se rellenan completamente (por ejemplo, solo contienen una pequeña muestra del conjunto de filas), los resultados de las pruebas comparativas no serán representativos.
Excluya las tablas que usan las aplicaciones de producción, pero que no forman parte del tráfico operativo continuo. Por ejemplo, si una base de datos contiene un conjunto de datos operativo activo, así como datos históricos usados para el análisis, es posible que los datos históricos no sean necesarios para ejecutar pruebas comparativas.
Rellene todas las tablas que copie en el servidor de prueba con datos de producción reales en lugar de muestras artificiales generadas mediante programación.

Diseño de pruebas comparativas de aplicaciones

El proceso de alto nivel para realizar pruebas comparativas de aplicaciones es el siguiente:

Cree una instancia de Servidor flexible de Azure Database for MySQL y rellenela con una copia de los datos de producción.
Implemente una copia de la aplicación en Azure.
Configure la aplicación para usar la instancia de servidor flexible de Azure Database for MySQL.
Ejecute pruebas de carga en la aplicación y evalúe los resultados.

Este enfoque es principalmente útil cuando se puede implementar fácilmente una copia de la aplicación en Azure. Le permite realizar una evaluación del rendimiento de la manera más exhaustiva y precisa, pero todavía hay ciertas recomendaciones que se deben tener en cuenta.

La herramienta que se usa para generar tráfico de aplicaciones debe poder generar una combinación de solicitudes representativas de la carga de trabajo de producción. Por ejemplo, no pruebe accediendo repetidamente a la misma dirección URL de la aplicación, ya que es probable que esto no sea representativo de cómo sus clientes usan la aplicación en el mundo real.
El grupo de instancias de cliente y de aplicación debe ser lo suficientemente eficaz como para generar solicitudes, administrarlas y recibir respuestas de la base de datos sin introducir cuellos de botella.
El nivel de simultaneidad (el número de solicitudes paralelas generadas por la herramienta de pruebas comparativas) debe coincidir o superar ligeramente el nivel de simultaneidad máximo esperado observado en la aplicación.

Diseño de pruebas comparativas de base de datos

Si no puede implementar fácilmente una copia de la aplicación en Azure, debe realizar la prueba comparativa mediante la ejecución de instrucciones SQL directamente en la base de datos. Para ello, utilice el procedimiento siguiente de nivel superior:

Identifique las instrucciones SQL que suelen aparecer en la carga de trabajo de producción.
En función de la información recopilada en el primer paso, prepare una muestra grande de instrucciones SQL para probar.
Cree un nodo servidor flexible de Azure Database for MySQL y rellene con una copia de los datos de producción.
Inicie instancias de cliente de máquina virtual (VM) de Azure en Azure.
En las máquinas virtuales, ejecute el ejemplo de carga de trabajo de SQL en la instancia del servidor flexible de Azure Database for MySQL y evalúe los resultados.

Hay dos enfoques principales para generar la carga de prueba (muestras de instrucciones SQL):

Observar o registrar el tráfico SQL que se produce en la base de datos actual y, luego, generar muestras de SQL en función de esas observaciones. Para más información sobre cómo registrar el tráfico de consultas mediante una combinación de registros de auditoría y el registro de consultas lentas en el servidor flexible de Azure Database for MySQL.
Usar los registros de consulta reales como carga útil. Las herramientas de terceros como "Percona Playback" pueden generar cargas de trabajo multiproceso basadas en registros de consultas lentas de MySQL.

Si decide generar manualmente muestras de SQL, asegúrese de que el ejemplo contenga:

Un número suficientemente grande de instrucciones únicas.

Ejemplo: si determina que la carga de trabajo de producción usa 15 tipos principales de instrucciones, no basta con que la muestra contenga un total de 15 instrucciones (una por tipo). Para una muestra así de pequeña, la base de datos almacenaría fácilmente en caché los datos necesarios en memoria, lo que hace que la prueba comparativa no sea representativa. En su lugar, proporcione una muestra de consulta grande para cada tipo de instrucción y use las siguientes recomendaciones adicionales.
Instrucciones de diferentes tipos en las proporciones adecuadas.

Ejemplo: si determina que la carga de trabajo de producción usa 12 tipos de instrucciones, es probable que algunos tipos de instrucciones aparezcan con más frecuencia que otros. La muestra debe reflejar estas proporciones: si la consulta A aparece 10 veces más a menudo que la consulta B en la carga de trabajo de producción, también debería aparecer 10 veces más a menudo en la muestra.
Parámetros de consulta que son aleatorios de forma realista.

Si ha seguido recomendaciones anteriores y la muestra de consulta contiene grupos de consultas del mismo tipo o sintaxis, los parámetros de dichas consultas deben ser aleatorios. Si la muestra contiene un millón de consultas del mismo tipo y son todas idénticas (incluidos los parámetros en condiciones WHERE), los datos necesarios se almacenarán fácilmente en caché en la memoria de la base de datos, lo que hace que la prueba comparativa no sea representativa.
Orden de ejecución de instrucciones que es aleatorio de forma realista.

Si sigue las recomendaciones anteriores y la carga útil de prueba contiene muchas consultas de diferentes tipos, debe ejecutar estas consultas en un orden realista. Por ejemplo, la muestra puede contener 10 millones de SELECT y 1 millón de UPDATE. En tal caso, ejecutar todas las instrucciones SELECT antes que todas las UPDATE puede no ser la mejor opción, ya que es probable que esta no sea la forma en que la aplicación ejecuta consultas en el mundo real. Lo más probable es que la aplicación intercale las instrucciones SELECT y UPDATE, y la prueba debe intentar simular esto.

Cuando la muestra de consultas esté lista, ejecútela en el servidor mediante un cliente MySQL de línea de comandos o una herramienta como mysqlslapv.

Ejecución de las pruebas

Con independencia de si ejecuta una prueba comparativa sintética o una prueba de rendimiento real de aplicaciones, hay varias reglas generales que se deben seguir para ayudar a garantizar que se obtienen resultados más representativos.

Ejecución de pruebas en varios tipos de instancia

Supongamos que decide ejecutar pruebas comparativas en un servidor db.r3.2xlarge y que el rendimiento de la aplicación o de las consultas satisface sus requisitos. También se recomienda ejecutar pruebas en tipos de instancia más pequeños y más grandes, lo que proporciona dos ventajas:

Las pruebas con tipos de instancia más pequeños pueden seguir dando buenos resultados de rendimiento y revelar posibles oportunidades de ahorro de costos.
Las pruebas con tipos de instancia más grandes pueden proporcionar ideas o información sobre las opciones de escalabilidad futuras.

Medición del rendimiento sostenido y máximo

La estrategia de prueba que elija debe proporcionar respuestas a si la base de datos proporcionará unos valores adecuados de:

Rendimiento sostenido: ¿tendrá el rendimiento esperado con una carga de trabajo normal, cuando el tráfico de usuarios sea fluido y esté dentro de los niveles previstos?
Rendimiento máximo: ¿garantizará la capacidad de respuesta de la aplicación durante los picos de tráfico?

Tenga en cuenta las directrices siguientes:

Asegúrese de que las ejecuciones de prueba sean lo suficientemente largas como para evaluar el rendimiento de la base de datos en un estado estable. Por ejemplo, una prueba compleja que solo dura 10 minutos probablemente genere resultados inexactos, ya que es posible que las memorias caché y los búferes de la base de datos no puedan prepararse en tan poco tiempo.
Las pruebas comparativas pueden ser mucho más significativas e informativas si los niveles de carga de trabajo varían a lo largo de la prueba. Por ejemplo, si la aplicación normalmente recibe tráfico de 64 clientes simultáneos, inicie la prueba comparativa con 64 clientes. A continuación, mientras se sigue ejecutando la prueba, agregue 64 clientes más para determinar cómo se comporta el servidor durante un pico de tráfico simulado.

Inclusión de pruebas de "blackout/brownout" en el procedimiento de prueba comparativa

El rendimiento sostenido del servidor es una métrica importante, que probablemente se convierta en el principal punto de atención durante sus pruebas. Sin embargo, para las aplicaciones críticas, las pruebas de rendimiento no deben limitarse a medir el comportamiento del servidor en estado estable.

Considere la posibilidad de incluir los siguientes escenarios en las pruebas.

Pruebas de "blackout", diseñadas para determinar cómo se comporta la base de datos durante un reinicio o un bloqueo. El Servidor Flexible de Azure Database for MySQL introduce mejoras significativas en lo que respecta a los tiempos de recuperación tras fallos, y las pruebas de reinicio y fallos son fundamentales para comprender cómo el Servidor Flexible de Azure Database for MySQL ayuda a reducir el tiempo de inactividad de su aplicación en estas situaciones.
Pruebas de "brownout", que están diseñadas para medir la rapidez con que una base de datos logra niveles de rendimiento nominales después de un reinicio o bloqueo. A menudo, las bases de datos necesitan tiempo para lograr un rendimiento óptimo y el servidor flexible de Azure Database for MySQL también presenta mejoras en esta área.

En caso de problemas de estabilidad que afecten a la base de datos, cualquier información recopilada durante las pruebas comparativas de rendimiento ayuda a identificar cuellos de botella o a ajustar aún más la aplicación para satisfacer las necesidades de la carga de trabajo.