Cada vez que un módulo es abierto por primera vez el servidor carga en RAM el contenido del modelo de datos. En el momento que ese usuario hace selecciones, los cálculos y gráficos resultantes se van almacenando en la RAM del servidor, de manera que estos cálculos se pueden compartir entre todos los usuarios, agilizando futuras consultas. Mientras tanto, QlikView va almacenando el estado de la sesión actual para cada usuario.
La vida de la caché se gestiona desde el Qlikview Manager Console (QMC) configurando el working set con dos parámetros:
- LOW: memoria RAM mínima que puede utilizar QV (no quiere decir que la reserve, es el máximo de memoria a partir del cual debe limpiar caché y purgar sesiones para liberar espacio).
- HIGH: máximo RAM disponible para QV en caso de que sea necesario.
Cuando el consumo de RAM alcanza el valor indicado en el LOW (en nuestro caso, el 50% de la RAM disponible), se limpia la caché y se purgan sesiones. Pero si esto no es suficiente, QV puede utilizar hasta el 70% de la RAM del servidor o bien puede usar el disco como Memoria Virtual (según criterios internos de QV). Si de nuevo fuese necesaria más memoria, QV está obligado a utilizar el disco como Memoria Virtual. El rendimiento de este tipo de memoria es mucho peor que la RAM.
Una solución paliativa para optimizar el rendimiento en los picos de consumo sería subir el parámetro HIGH al 90% y NO ejecutar ninguna aplicación dentro del servidor, es decir, no abrir ni recargar módulos desde QV Desktop. Cuando finalice el valle, se recupera la configuración original.
Buenas prácticas en la configuración de Qlikview Server
- Incrementar recursos de hardware: ampliar memoria RAM o Cores.
- Limitar cantidad de sesiones concurrentes permitidas: Normalmente no se limita para evitar problemas de acceso. Si fuera necesario, se puede limitar en paralelo a asignar un timeout bajo para liberar rápidamente las sesiones en desuso.
- Desarrollar aplicaciones para un correcto uso de memoria: implicaría revisar scripts (tablas sintéticas, bucles, expresiones complejas, set analysis, etc) y rediseñar aplicaciones con menor número de objetos, macros, acciones y lógica en general.
- Reducir la cantidad de tareas programadas en el servidor: En caso de que haya tareas programadas en Qlikview Server (Publisher). Otra opción es realizar las cargas en horas de bajo consumo (madrugada).
- Limitar el desarrollo de aplicaciones en el servidor: desarrollar y recargar módulos en otra máquina y luego copiarlos al servidor. Lo ideal sería trabajar en un entorno de desarrollo y explotar la información desde un servidor operacional.
- Liberar recursos deshabilitando otras aplicaciones: en el caso de que se ejecuten otras aplicaciones en la misma máquina.
Buenas prácticas en diseño de modelo de datos en Qlikview
Qlikview puede analizar múltiples orígenes de datos pero la forma más eficiente es con un modelo de datos de Estrella o Copo de nieve.
Normalmente los esquemas de Estrella son la mejor solución, pero en muchas situaciones necesitaremos varias tablas de hechos. La forma correcta de conectarlas es mediante tablas de enlace para evitar claves sintéticas y loops. Se puede abordar de tres formas diferentes:
- CONCATENATE
Una opción es concatenar dos tablas de hechos, ya sea de forma física mediante la sentencia CONCATENATE o de forma lógica utilizando los nombres de los campos (por ejemplo, CAMPO1_A y CAMPO1_B).
En el caso de dos tablas de hechos A y B, el número de registros de la nueva tabla será la suma de los registros de ambas. Las métricas de la tabla A que no estén en B estarán a NULL y viceversa.
Los nombres de los campos deben ser exactamente los mismos (podemos renombrarlos con AS). La tabla que manda será siempre la que se cargue primero (antes del CONCATENATE).
Cuando se concatenan dos tablas, es necesario crear una referencia manual para identificar el tipo u origen de los datos, por ejemplo “Tipo”.
- ÚNICA TABLA DE HECHOS
Si es posible, otra solución es fabricar una única tabla de hechos a nivel de SQL o Script.
- TABLA DE ENLACE CENTRAL
Es la forma habitual de romper las claves sintéticas. Se crean campos de enlace entre las tablas de hecho y las maestras/lookup mediante alias de campos.
