Una técnica utilizada en SSIS 2005 para mejorar el rendimiento a través de forzar nuevos árboles de ejecución (con nuevos hilos para la ejecución tendríamos más velocidad aprovechando el paralelismo) era colocar componentes Union All aunque no sean necesarios si hablásemos sólo de lógica del proceso. Esto es beneficioso siempre y cuando los procesos sean dependientes del Union All (aquellos que están a continuación en el flujo de datos) sean susceptibles a la paralelización. Si no es así, el coste de la generación y el tratamiento de los nuevos buffers que se crean al entrar en acción el Union All es mayor al beneficio que podríamos obtener.Con los siguientes ejemplos veremos que este supuesto beneficio puede ser un arma de doble filo y también entenderemos mejor qué implica la creación de un árbol de ejecución.Como primera situación tenemos:
donde cacheamos una tabla muy pequeña con el componente Lookup, estamos generando 100 millones de filas con un Script Component y donde tenemos también un componente de columna derivada para simular un entorno algo más real. En mi equipo, la ejecución completa tarda 3min 40seg.
Veamos lo que ocurre con otro ejemplo donde evitamos el Union All.
Tenemos exactamente el mismo comportamiento excepto que obviamos los fallos que pueda tener el Lookup (aunque no los tendrá porque el ejemplo está construido para que siempre encuentre coincidencias) y no tenemos el componente Union All antes del “Destino dummy” que utilizamos para simular uno real. En mi equipo, bajo las mismas condiciones que el anterior, éste tarda 2min 44seg.
Si lo reflejamos en segundos para verlo más claro y comparamos los tiempos de ejecución tenemos:
(220 * 100) / 164 = 134,14%
Nuestro ejemplo lento (Figura 1) ha tardado un 34.14% más que nuestro ejemplo rápido (Figura 3). Esta penalización se debe al trabajo que debe hacer la CPU generando el nuevo árbol de ejecución y los hilos asociados pero, sobre todo, copiando la información a los nuevos buffers generados. Aquí perdemos uno de los mayores beneficios de SSIS que, como veíamos en el capítulo 1 de la serie, es el hecho de que los datos estén fijos en memoria y no se hayan de mover de un sitio a otro.
Podemos comprobar que las operaciones que hay por debajo del Union All en la Figura 1 no conseguirían beneficio de un nuevo árbol de ejecución forzado por nosotros al ejecutar en SSIS 2008 el ejemplo de la Figura 3 y no obtener ninguna sub-ruta.
Los procesos dependientes del Union All no aprovecharán para nada los efectos de un nuevo árbol de ejecución y por tanto los costes asociados a generarlo son mayores que el beneficio que pueda reportar.
Como hemos visto, es muy recomendable monitorizar mediante las opciones de logging de SSIS y el registro de eventos lo que va ocurriendo en nuestros paquetes SSIS para entender por completo qué estamos provocando con nuestros diseños. Así podremos escudriñar cómo se comporta SSIS por muy complejo que sea el caso.
Además, si estamos trabajando en entornos con mucho ruido (diversos procesos atacando la BD, procesador con mucha carga de trabajo sostenida, etc.) es conveniente aislar todo lo posible nuestro entorno de pruebas. Ajustar los niveles de aislamiento de nuestra BD, realizar las pruebas en horas de baja carga, o incluso usar otra instancia de nuestro motor relacional en otro disco o entorno de preproducción si disponemos de ello donde levantemos un backup de nuestra BD original son medidas que nos pueden servir para poder analizar correctamente qué pasa en el corazón de SSIS.
