Introducción
En este artículo, se desarrollarán conceptos básicos de pruebas de carga sobre el motor relacional de SQL Server con HammerDB. Los conceptos que veremos a continuación son aplicables a otros motores como MySQL, MariaDB, Oracle o PostgresSQL.
En primer lugar, veremos una breve introducción al concepto de carga en bases de datos OLTP y, a continuación, desarrollaremos un ejemplo de carga con la herramienta HammerDB que nos permitirá definir parámetros que nos ayudará a simular cargas transaccionales al estilo de aplicaciones transaccionales del tipo SAP, Baan u otros sistemas de información del estilo.
Pruebas de carga en entorno OLTP
Concepto de entorno OLTP
En este artículo nos centraremos en pruebas de carga para entornos OLTP que, a diferencia de un entorno con procesos analíticos y/o bussiness intelligent, es una carga de trabajo típicamente identificada por una base de datos que recibe solicitudes y cambios de los datos (transacciones) de multitud de usuarios a lo largo del tiempo.
| OLTP | OLAP |
| Los datos se atomizan | Los datos se resumen |
| Los datos son actuales | Los datos son históricos |
| Procesa pocos registros en cada operación | Procesa multitud de registros simultáneamente |
| Orientada a procesos | Orientada a analítica |
| Diseñada para el proceso repetitivo altamente estructurado | Diseñada para el proceso analítico altamente desestructurado |
Sin entrar en detalles, toda operación transaccional parte de un punto inicial consistente que, tras su ejecución, devuelve a su vez otro punto con el mismo nivel de consistencia aunque en dicha transacción se incluyan operaciones de cambios y lecturas en coexistencia con otros procesos transacciones concurrentes. Para asegurar estas premisas una transacción debe mantener las siguientes propiedades conocidas con el acrónimo de ACID:
- Atomicidad: Una transacción consta de una serie de operaciones, básicamente, de lectura y escrituras. La propiedad de atomicidad asegura que estas operaciones se ejecutan correctamente todas o ninguna, es decir, las transacciones son completas sin posibilidad de ejecución de transacciones parciales.
- Consistencia (Integridad): Toda transacción parte de un estado consistente y, esta propiedad asegura que, tras la ejecución de la transacción, los datos afectados en dicha transacción deben quedar en estado consistente, por lo tanto, solo se ejecutan aquellas operaciones que no van a romper las reglas y directrices de integridad de la base de datos.
- Aislamiento (Isolation): Esta propiedad asegura que una operación no puede afectar a otras. Las transacciones son operaciones que actual sobre el mismo conjunto de datos sean independientes y no generen ningún tipo de error. Esta propiedad define cómo y cuándo los cambios producidos por una operación se hacen visibles para las demás operaciones concurrentes.
- Durabilidad (Persistencia): Esta propiedad asegura que una vez realizada la operación, esta persistirá y no se podrá deshacer aunque falle el sistema y que de esta forma los datos sobrevivan de alguna manera.
La dificultad de la administración de los sistemas OLTP se centran en garantizar el acceso concurrente de los usuarios de forma aislada, manteniendo la base de datos consistente y recuperable con un rendimiento que permita la ejecución efectiva y eficiente de los procesos de negocio.
Diseño de prueba de carga OLTP simuladas en el motor relacional de SQL Server con TPCC
El objetivo que marcamos en este artículo es analizar la capacidad transaccional de una instancia de SQL Server con la ejecución de distintos escenarios de carga a partir de un sistema OLTP de referencia (TPC-C o TPROC-C).
En resumen, TPC-C simula un entorno OLTP completo en el que un conjunto de usuarios ejecuta transacciones contra una base de datos similares a las que se ejecutan sistemas de información del tipo SAP (ERP), Salesforce (CRM). El entorno TPC-C centra su operativa en las principales actividades (transacciones) de un entorno de entrada de pedidos. Estas transacciones incluyen ingresar y entregar pedidos, registrar pagos, verificar el estado de los pedidos y monitorear el nivel de existencias en los almacenes en un entorno de un proveedor mayorista sin limitarse a la actividad de ningún segmento comercial en particular, sino que representa a cualquier industria que debe administrar, vender o distribuir un producto o servicio.
Instalación y preparación de HammerDB para pruebas de carga en sistemas OLTP
Descarga e instalación de HammerDB
Como se ha visto en el apartado introductorio, para ejecutar cargas se utilizará HammerDB. Podemos descargar la última versión de HammerDB del siguiente link:
https://www.hammerdb.com/download.html
Nota: En el desarrollo del artículo se utilizará la versión 4.3
Para la instalación de HammerDB, se ejecutará el archivo descargado de link anterior, en nuestro caso HammerDB-4.3-Win-x64-Setup.exe y seguiremos indicaciones por pantalla. La instalación el básicamente: “siguiente, siguiente, siguiente, …, finalizar”.
Por defecto, la instalación de HammerDB no crea acceso directo de ejecución en el menú de “Inicio”, por tanto, se ha de crear manualmente dicho acceso directo o iniciarlo directamente a partir del ejecutable que se ubica en el directorio de ejecución (C:\Program Files\HammerDB-<<versión>>.
Preparación de HammerDB para pruebas con SQL Server
En este apartado veremos la primera prueba de carga para un entorno transaccional con SQL Server. HammerDB tiene una amplia diversidad de pruebas de carga que se irán desarrollando en artículos posteriores. Para iniciarnos en las pruebas de carga con HammerDB, empezaremos con un escenario básico en el que simularemos la interacción de un usuario en un entorno OLTP.
Para las pruebas iniciales nos marcaremos los siguientes objetivos:
- Configurar SQL Server para las pruebas de carga
- Instalar y ejecutar HammerDB
- Recopilar estadísticas de entorno de ejecución
- Ejecutar la prueba de carga TPC-C
Creación y configuración de la base de datos TPCC para pruebas de carga en SQL Server
1.- Ejecutamos HammerDB desde el directorio de ejecución.
2.- Preparamos el entorno para ejecución sobre motores SQL Server.
3.- Creación de la base de datos TPC-C en la instancia de SQL Server sobre la que se ejecutan los tests
4.- Por la carga transaccional que vamos a simular en la base de datos, es importante configurar el modelo de recuperación a ‘Simple’ para evitar el llenado del log de transacciones.
Configuración de opciones HammerDB
HammerDB tiene multitud de opciones de configuración para ejecutar las pruebas de carga (concurrencia, tiempos de ejecución, usuarios, etc.).
El alcance de las pruebas y configuraciones de este primer artículo será la ejecución de transacciones en un solo hilo, en próximos artículos se desarrollarán pruebas con múltiples usuarios concurrentes. Para esta primera fase de pruebas se ha de tener:
- La creación de la base de datos tpcc en la instancia a testear desde la opción ‘Schema Build’ de HammerDB que se ha desarrollado en apartados anteriores.
- Configuración de parámetros de la carga en ‘Driver Script’ de HammerDB que se muestra a continuación.
Con la configuración mostrada anteriormente, se configura un lanzamiento de hasta 10.000.000 transacciones (Total Transactions per User) durante 10 minutos (Minutes for Test Duration).
Ejecución de pruebas de carga
Como se ha indicado en apartados anteriores, las pruebas que se lanzarán en el ejemplo de este primer artículo serán con un solo hilo de ejecución (1 usuario). En próximos artículos se desarrollarán pruebas de cargas con varios usuarios de forma concurrente (opción ‘Virtual User’ de HammerDB).
1.- Configuración el número de usuarios concurrentes desde la opción ‘Virtual Users’
2.- Lanzamiento de la carga
3.- Seguimiento de la prueba
Antonio Llompart Freire 