QlikView + Qlik Sense Blog von Heldendaten

<add key="ServiceFailureAlertEmailAddresses" value="qlikviewadmins@heldendaten.net"/>
<add key="ServiceFailureAlertEmailSubject" value="PROD QlikView Server: [SERVICE-NAME] on URL [SERVICE-URL] is down."/>
<add key="ServiceFailureAlertEmailBody" value="PROD QlikView Server: [SERVICE-NAME] on [SERVICE-URL] is down. Go to http://yourserver:4780/QMC/ServiceStatusOverview.htm for details!"/>

<add key="UseSSLForSMTP" value="true"/>

Zeile 5-7 ergänzen. UseSSLForSMTP müsste schon in der .config zu finden sein.

Service Failure Email: Der QlikView Webserver (QVWS) ist down

QvsStatus.aspx vom QVWS sagt "Up" wenn QVS gut läuft

QVS hat zuerst nur 1.8 GB WorkingSet Low. Aber auch 24 GB sind zu wenig RAM für seine .qvws.

Eine Aussage wieviel Arbeitsspeicher der Publisher mit seinen Task-Executions (qvb.exe) gerne hätte, kann man mit dem QVS Log nicht treffen. Wenn Sie Ressourcen-Knappheit im Nachgang analysieren, und den Memory-Verbrauch des Publisher mit einbezieht möchten, dann ist es besser auf das Event 2004 im Windows System Event Log zu sehen.

Diese Woche war große Releasewoche bei Qlik: Qlik Sense, QlikView und NPrinting haben ein neues "November" Release bekomme.

Für Qlik Sense November 2017 gibt es ein  "What's New" Video:


QlikView November 2017 (oder vormals QlikView 12.20) hat als Hauptfeature sicherlich die Analytic Connections (Server Side Extensions) zu R und Python bekommen. Das ist nun der Vorteil der gemeinsamen Qix-Engine: Qlik Sense und QlikView profitieren beide von solchen Engine-Features!


In QlikView hat sich aber auch an der Oberfläche einiges getan. Vieles sind Gapfeatures zwischen IEPlugin und AJAX-Client. Hier einige Screenshots zu den wichtigsten Punkten:

Copy to Clipboard

Wer erinnert sich noch an meinen Post aus 2014 mit meiner Document Extension . Endlich kann man auch im AJAX-Client Zellenwerte in die Zwischenablage kopieren!Endlich kein Abtippen mehr!

 Attach/Detach Chart

Will man mehrere Selektionsstände gegenüberstellen, gab es in QlikView Desktop/IEPlugin immer die Möglichkeit ein Chart zu Detachen.  Wenn man danach eine Selektion tätigt, bleibt das Chart noch immer in der alten Selektion.

Funktioniert jetzt auch im AJAX Client. Wenn man Serverobjekte erlaubt, kann sich ein Analyst das Chart kopieren, detachen, und dann der aktuellen Analyse gegenüberstellen

Set Reference

Ähnliche Funktion wie Detach/Attach die auch aus QlikView Developer/IEPlugin bekannt ist. Sagt man in einer Graphik "Set Reference" wird im Hintergrund transparent der aktuelle Stand angezeigt. Ändert man die Selektion, hat man weiterhin den fixierten Wert als Referenz. Zum Löschen dann wieder "Clear Reference" klicken.

Language in AJAX Client

Sprache war bisher ein Serverweites Setting für den AJAX Client. Jetzt kann jeder User am Accesspoint rechts oben unter "Favorites & Profile" seine Menüsprache umstellen.

Send to Excel erzeugt .xlsx

Bisher hat Qlik nach .xls exportiert und alle 65k Datensätze ein neues Arbeitsblatt angelegt. Wir haben es getestet: Export von 1.000.000 Zeilen mit 2 Spalten hat als .xls funktioniert!

Der Beweis: Export von 1.000.000 Zeilen in ein .xlsx mit QlikView Nov 2017

 QMC Document Log und .qvw Name

Das gab es schon mal in QlikView 8.5! Jetzt endlich zurück: der Document Log des Tasks ist wieder in der QMC ersichtlich. Zum Taskname steht im Klammer jetzt auch noch der Pfad zur .qvw!

Über das Memory & Cache-Verhalten des QlikView Servers wurde schon viel geschrieben. Trotzdem bleibt das Gerücht hartnäckig, dass der QlikView Server ein Memory Leak hat.



Wenn man sich jedoch einmal mit dem WorkingSetLimit-Setting in der QMC beschäftigt hat, wird einem  klar, dass der QlikView Server einfach gerne aggressiv cached. (Fast) jedes gerechnete "Chart", welches sich aus einer Userselektion ergibt, will der QlikView Server cachen, sofern er noch Memory (<= WorkingSetLimit Low) dafür zur Verfügung hat. Damit braucht ein QlikView Server immer weniger CPU-Zeit, "frisst" aber für gewöhnlich im Verlaufe eines Tages das Memory des Servers auf (und gibt es auch nicht mehr frei, sofern er das WorkingSetLimit Low getroffen hat).

Dieses Verhalt kann nerven - speziell wenn man am gleichen Server auch noch den Publisher/ServerReload laufen hat, und jemand zusätzlich mit dem QlikView Developer entwickelt. Dieses Deployment trifft auf  viele Testserver bei unseren Kunden zu!

Abhilfe kann ein Easteregg schaffen, das in der settings.ini des QlikView Servers gesetzt werden kann.


Das Setting löscht um Mitternacht den Cache des QlikView Server Services. Das bedeutet:

•  Memory das von den Daten der .qvws belegt wird, bleibt belegt
• Alle  gecachten Berechnungen werden gelöscht, und der QlikView Server gibt diesen Teil des Memorys wieder an das Betriebssystem frei.

Das Interessante an diesem Setting: man kann definieren wie oft der Cache geleert werden soll. Immer ausgehend von Mitternacht ergibt sich somit:

ClearCacheTimesPerDay=1	Einmal am Tag um Mitternacht 00:00
ClearCacheTimesPerDay=2	00:00 und 12:00
ClearCacheTimesPerDay=3	00:00 08:00 16:00
...	usw.
ClearCacheTimesPerDay=24	jede Stunde

Die Teststellung

Wir haben ClearCacheTimesPerDay=24 auf einer Teststellung bei uns überprüft.Und tatsächlich - zu jeder vollen Stunde wurde wieder das Memory des Caches freigegeben! Unterhalb unsere Vorgehensweise.

Server

Wir haben auf einem Win2016 Server mit 8GB RAM getestet. Das Workingset des Serves ist auf  50% beschränkt, damit sollte der QlikView Server Prozess bis maximal 4GB Daten cachen.

Workingset des QlikView Server Service auf 50% = 4GB

Das Testscript

Die .qvw für den Test ist recht simple. Das Script lautet:

load
  'A'&rowno() as row,
  rand() as value
autogenerate(1000000)

Im Layout gibt es eine einfache Tabelle. Wenn man einige Werte auswählt und dann Rechtsklick "Select excluded" wählt, füllt man mit jeder neuen Selektion den Server-Cache mit einigen Dutzend Megabytes.

Viele distinkte Daten füllen den Cache ganz gut!

Konfiguration & Test

1. QlikView Server Service stoppen. Settings.ini ändern, Service starten
   
2. Bis 09:43 haben wir den Cache des Servers durch "Klicken" in unserer Testapplikation  auf  2 Gigabyte hochgetrieben
   
3. Um 10:00 sieht man im Performance Monitor eine steile Flanke nach oben. Memory wird also freigegeben!  Die Größe des QlikView Server Prozesses ist im Taskmanager auf 192 Megabyte gefallen! Das Setting hat also 1,98 GB Cache geleert! Die restlichen 192 MB sind die Daten in unserer Testapplikation plus ein wenig Overhead des QlikView Server Prozesses.
   
4. Gleiches Spiel bis 10:40, nur dass wir mehr Zeilen im autogenerate()-Script der .qvw generiert haben  (ca 900 MB Daten im Memory). Damit füllt sich mehr Cache mit weniger Klick ;-)
   
   Diesmal haben wir den Cache bis an das Maximum von 4 Gigabytes hochgetrieben (wegen des definierten Workingset Low 50% von 8GB geht auch nicht mehr).
   
   
5. Um 11:00 dann wieder der Drop auf 900 MB
   
   

Conclusio

Das Setting ClearCacheTimesPerDay funktioniert, und ist eleganter als ein net stop/start des QlikViewServer Services (bei dem alle Online-User aus ihrer QlikView Session fliegen). Für den Testserver kann es also sehr nützlich sein. Für den Produktiven Server ist es nicht zu empfehlen - da muss man schon ein sinnvolles HardwareSizing durchführen (gerne auch mit uns!).

Zuletzt habe ich auf einem Projekt gearbeitet, bei dem die QlikView Dashboards "Near Realtime" kontinuierlich geladen werden. Das funktioniert sehr gut - außer wenn der QlikView Publisher auf einen dauerhaften Fehler läuft - denn dann wird man mit Alert-Emails nur so zugespammt. Jeder fehlgeschlagener Reloadtask schickt eine eigene Email. Da kommen in der Stunde schnell 300 Emails zusammen.

Notification Connector For QlikView & Qlik Sense

Um die Emailflut einzudämmen, aber trotzdem über Fehler informiert zu werden, haben wir den Notification Connector For QlikView & Qlik Sense benutzt. Ende des Sommers hat Qlik unsere alten Freunde von qvsource.com übernommen, und dankenswerterweise einige Konnektoren zur freien Benutzung bereitgestellt. Darunter eben auch den Notification Connector, der es erlaubt, aus dem QlikView-Script heraus Emails zu verschicken.

Die freien, ehemaligen QVSource Connectoren, die Sie aus dem Qlik Market herunterladen können

Prinzipiell war der Emailversand auch mit den QlikView Alerts schon immer möglich. Aber die hübsche Formatierung in HTML, und die Flexibilität des QlikViewScripts ist  mit dem Notification Connector doch besser. In Qlik Sense ist der Connector überhaupt die erste Wahl um automatisiert Emails zu senden.

Fehlgeschlagene Tasks erkennen

Um Fehler aus den Publisher Logs zu lesen, haben wir uns bei den Skripten aus dem QlikView Governance Dashboard 2.0 bedient. Dort ist das Skript im versteckten Scriptreiter sichtbar, wenn man das Passwort "QVGD2.0" eingibt.

Das Hidden Script des Governance Dashboards

 Email Versand

Die .qvw  wird in unserem Projekt jede Stunde vom Publisher angestoßen, und sucht nach allen Taskfehlschlägen die seit dem letzten Run passiert sind.  Findet es Fehler, so schickt es eine Email mit allen betroffenen Applikationsnamen und den Log-Pfaden. So hat man mit einem Klick die Möglichkeit den Grund des Fehlers zu analysieren.

Email des Notification Connetors, insgesamt sind in der letzten Stunde 7 Tasks fehlgeschlagen

Einmal am Tag schickt die Applikation außerdem eine "Alive"-Email und sagt wie viele Reloads erfolgreich durchgeführt wurden. 

Email des Notification Connectors: von den 137 Reloads in der letzen Stunde waren alle erfolgreich. Kein Grund zur Sorge

Auch wenn Sie keine häufigen Reloads haben, so ist der Notification Connector hilfreich. Anstatt morgens in die QMC zu sehen, können Sie sich hier beliebige Informationen der nächtlichen Beladung zukommen lassen. Natürlich können Sie sich mit dem Notification Connector alle möglichen Informationen&Alarme versenden (Umsatzgrenze unterschritten, Datenqualitätsprobleme, etc.). Ihrer Phantasie ist da im QlikView Script keine Grenze gesetzt.

Die .qvw finden Sie zum Download hier. Sie müssen den Notification Connector am gleichen Rechner wie den Publisher auf Port 5555 installiert haben. In der .qvw müssen Sie am Reiter "Main" Ihre Einstellungen in den Variablen vornehmen. Bei Fragen stehen wir gerne zur Verfügung!


 

Oft werden wir gefragt, welche Funktionalität der QlikView Publisher umfasst. Leider kenne ich keine gutes Dokument, das alle Features übersichtlich listet. Unterhalb also mein Versuch die wichtigsten Punkte kurz zu beleuchten.

QlikView Server & Publisher auf zwei getrennte Maschinen

Kleine QlikView Installationen starten gerne mit einer Maschine die gleich zwei Aufgaben übernehmen muss: Das Beladen der QlikView Applikationen sowie die In Memory-Analyse über den QlikView Accesspoint.

Technisch übernehmen diese beide Aufgaben einerseits das QlikView Distribution Service (Beladung) und andererseits das QlikView Server Service (In Memory Analysen). Meist geht das eine Weile gut, doch eigentlich sind sich die beiden Services spinnefeind! Beide Services sind sehr Memory- und CPU-intensiv und wollen eigentlich alle Ressourcen für sich alleine!

Kastriert man den QlikView Server über seine WorkingSet-Limits, kann das Service weniger Cachen und die QlikView Anwendungen werden CPU-intensiver. Nutzt der QlikView Server alle Ressourcen um die Useranfragen schnellst möglich bereitzustellen, bleibt kein "Platz" mehr für die Beladung der Applikationen.

Wenn also über die Jahre die Datenmengen in den Applikationen wachsen, die Beladungen auch untertags stattfinden sollen oder immer mehr Kunden auf die Applikationen zugreifen - kurz gesagt wenn das Qlik Projekt ein Erfolg ist - dann streiten sich die beiden Services immer mehr um die beschränkten Rechner-Ressourcen, worunter die Gesamtperformance leidet. Am Sinnvollsten ist es dann,  die Services auf zwei getrennten Servern zu konfigurieren. Lizenztechnisch ist das aber nur mit einer Publisher Lizenz möglich.

Aus unserer Erfahrung schlagen wir immer folgendes Deployment vor, welches auf Dauer viel stabiler als eine "Single Server"-Lösung läuft, die Ressourcen besser nutzt und leichter zu Warten ist.

Empfohlenes Deployment: Publisher und QlikView Server auf zwei Maschinen trennen

Cluster Publisher

Haben Sie eine Publisher-Lizenz, so dürfen Sie damit einen Server betreiben. Benötigen Sie eine Lastverteilung der Beladungen über mehrere Server, so können Sie das Distribution Service clustern. Die Taskdefinition in der QMC bleibt gleich, und Qlik entscheidet aufgrund eines Loadbalancing-Algorithmus auf welchem Reload-Server der Task dann tatsächlich ausgeführt wird.

Mehrere Distribution Services sind sinnvoll, wenn sehr viele Beladetasks vorhanden sind

And Trigger - On Multiple Events completed

Sehr häufig sehen wir bei  Nicht-Publisher Kunden ewig lange Taskketten, da die QVD-Generatoren "seriell" nacheinander angestoßen werden. Das ist weder bezüglich Übersicht in der QMC, noch von der Laufzeit ideal.

Mit der Publisher-Lizenz wird ein weiterer Trigger-Typ freigeschalten: der "On Multiple Events Completed" oder auch "AND"-Trigger.

Typischerweise benötigt ein QlikView Datamart (Datenmodell) mehrere QVD-Generator als Vorgänger, da man oft pro Quellsystem einen eigenen QVDGenerator anlegt. Anstatt diese QVD-Generatoren seriell nacheinander laufen zu lassen, können Sie alle gleichzeitig wegstarten. Sobald der Langsamste fertig wird, startet der Datenmodell-Task. So lässt sich die Durchlaufzeit erheblich reduzieren.

Der Task startet, wenn der "langsamste" der drei  (parallel laufenden) Vorgängertasks fertig ist

Simple Reduce  und Loop&Reduce

Sie haben eine große Applikation, die Sie in mehrere kleine Tortenstücke "schneiden" möchten? Mit der Publisher-Lizenz erhalten Sie den Menüpunkt "Reduce".

Typisches Anwendungsgebiet ist, dass Sie für Ihre Niederlassungen (US, EU, Asia) getrennte Applikationen berechtigen möchten, während die User im Stammhaus weiterhin alle Daten in einer großen Applikation im Zugriff haben sollen. Aus der Gesamtapplikation lässt sich in der QMC manuell oder als "Seriendruck" mehrere kleinere .qvws schneiden und automatisch für die User berechtigen.

Simple Reduce über Land=Deutschland, Österreich und den Kategorienamen=Getränke

Loop&Reduce über das Feld "Land"  erzeugt und berechtigt pro Land eine Applikation

Distribute zu Email/Netzlaufwerk/Accesspoint

Ohne Publisher Lizenz muss die .qvw immer am Ort beladen werden, wo auch der User via Accesspoint darauf zugreift. Mit dem Publisher sind Sie hier flexibler: Sie können QlikView Auswertungen via Email verschicken, auf einem Netzlaufwerk bereitstellen, oder auf einen Ihrer Accesspoints verteilen. Der Menüpunkt "Distribute", über den Sie auch die Userberechtigungen steuern, wird mit der Publisherlizenz freigeschalten.

Der Distribute Reiter verteilt und berechtigt die QlikView Applikation

Notify

Ein kleines Feature, aber nicht unwichtig: Sie wollen Ihre Mitarbeiter informieren, dass eine aktualisierte Version der Qlik Applikation am Accesspoint bereitsteht: setzen Sie den Haken "Notify" um alle Berichtsempfänger zu informieren. Unter "System" können Sie das Notify-Emailtemplate bearbeiten.

Allen Empfängern eine Email schicken wenn QlikView Applikation frisch beladen wurde

Mehr als ein Task pro .qvw möglich

Oft ärgerlich ohne Publisher-Lizenz: man kann pro .qvw nur einen Task anlegen. Manchmal möchte man aber den Task jeden Montag und am Monatsende laufen lassen. Oder man möchte neben einer zeitgesteuerten Ausführung den Task auch von einem externen System angestoßen lassen.

Mit der Publisher Lizenz können Sie pro .qvw beliebig viele Tasks anlegen.

Mehrere Tasks auf einer .qvw

EDX (über schönen Tasknamen ansprechbar)

Hier geht es darum, die QlikView Tasks von extern anzustoßen. Ein Beispiel wäre, dass ein externer Scheduler den QlikView Task erst startet, nachdem das Data Warehouse fertig beladen wurde (da dies zu unterschiedlichen Uhrzeiten eintreten kann).

EDX oder "Event Driven Execution" geht genaugenommen auch ohne Publisher Lizenz. Aber man muss schon ziemlich gut im "Tasknamen Raten" sein, um den Task von einem Vorsystem anstoßen zu können. Mit der Publisher-Lizenz können Sie jedem Task einen Namen und eine Description geben, damit wird das Anstoßen der QlikView-Tasks durch das Vorsystem deutlich komfortabler.

Ein externer Scheduler kann den Publisher Task mit dem Namen anstarten

Supporting Tasks

Neben dem reinen Beladen von QlikView Applikationen, können Sie mit dem Publisher auch weitere Tasks durchführen. Dazu zählt:

• Das Ausführen von External Programs (zB Powershell/Batch-File um Daten zu löschen/kopieren, CacheWarming, etc.)
• Database Command Tasks (zB Inserts in Log-Datenbank wenn alle Tasks erfolgreich durchgelaufen sind)
• QVD Creation Tasks: Erzeugen und Berechtigen von .QVD Datentöpfen auch ohne QlikView Applikation. Berechtigte Self Service BI-User können dann diese .qvds nutzen um Ihre eigenen Applikationen aufzubauen
• Pause Task: Dieser Tasktyp macht einfach mal Pause :-)

Supporting Tasks  unabhängig von .qvws

Document Administrator

Sie haben Fachabteilungen die sich Ihre Dashboards selbst beladen/schedulen und berechtigen können? Gleichzeitig wollen Sie aber vermeiden, dass diese User Systemeinstellungen Ihrer QlikView Umgebung ändern können!

Der Publisher erlaubt mit dem Document Administrator Feature, dass bestimmte User nur bestimmte Applikationen in der QMC verwalten dürfen. Typischerweise definiert man pro Fachabteilung einen Mount-Point in dem alle Applikationen sind, die die Document Adminstrators selbst verwalten sollen. Die anderen Abteilungs-Applikationen sowie der Reiter "System" bleiben für diese Document Administrator verborgen.

Dieser Document Administrator sieht nur seine Tasks im Mountpoint Default und HR. Der Reiter "Users" und "System" ist ebenfalls ausgeblendet

User Suche und Section Access Management

Wenn  die Berechtigungen nicht aus dem Vorsystem übernommen werden können, dann können Sie diese mit der Publisher-Lizenz zentral in der QMC managen. Benötigen Sie applikationsspezifische Berechtigungen (User X darf nur Kostenstelle Y sehen) so steht Ihnen hierfür der Menüpunkt "Section Access Management" zur Verfügung.

Zentrales Management von User Rollen für Section Access

  

Parameter

Ähnlich gelagert wie "Loop & Reduce" können sie mittels Scriptparameter eine Variable an das QlikView-Skript übergeben. Wenn Sie  im QlikView Script etwa eine Variable vMandant haben, die im Skript wiefolgt genutzt wird

Select

*

from Fakten where MANDANT = $(vMandant); 

so können Sie die Variable in der QMC als Script Parameter setzen. So können Sie eine .qvw als Vorlage benutzen, um mit dem Publisher mehrere Varianten der Applikation zu verteilen.

Das Script in der .qvw würde dreimal ausgeführt werden: für den Mandanten 200, 300 und 500.

Remote Management Service

Wenn Sie in Ihrem Test/Quality System ebenfalls eine Publisher Lizenz haben, so können Sie in der Produktivumgebung dieses System als "Remote Distribution Service" eintragen. Damit können Sie die Taskdefinitionen aus dem Test/Quality System in die Produktivumgebung übernehmen.

Remote Management Service am Server "testsystem"

Backup QVPR einstellbar

Die Taskdefinitionen der QMC werden defaultmäßig in einem XML-Repository abgelegt. Dieses liegt für gewöhnlich unter  C:\ProgramData\QlikTech\ManagementService\QVPR. Dort wird auch täglich ein Backup angelegt. Mit der Publisher-Lizenz können Sie diese Backups auch in einem Ordner ablegen, der sowieso schon in Ihrem Backup-Plan enthalten ist.

QVPR Einstellungen für Pfad + Backup

Supervisor User

Anstatt die Administratoren (zB die User der IT-Abteilung) in jeder einzelnen Applikation zu berechtigen, gibt es das Konzept der Supervisor User. Diese User werden automatisch in jedem Distribution Task angehängt und dürfen alle QlikView Applikationen sehen.

Supervisor User für "Whole Server" definiert

Number of Task Attempts  bei Taskdefinition einstellbar

Leider laufen Beladetasks manchmal auf einen Fehler. Weil das Quellsystem nicht da ist, weil die Netzwerkverbindung weg ist, oder weil am Server nicht genügend Ressourcen bereit stehen. Viele Administratoren starten dann den Task frühmorgens nochmal, und dann läuft er plötzlich durch. Mit der Publisher-Lizenz können Sie die Tasks so definieren, dass der Publisher nach einem "Fehlschlag" die Beladung nochmal versucht. Oft klappt es dann beim zweiten Mal!

Number of tries bevor der Publisher den Task "aufgibt"

 Audit 

Vertrauen ist gut, Kontrolle ist besser. In manchen Anwendungsgebieten muss man einfach nachvollziehen können, welcher User wann welche Änderungen durchgeführt hat (Task Trigger geändert, User berechtigt). Mit der Publisher Lizenz haben Sie die Option einen Audit-Log für die QMC zu aktivieren. Das Logfile kann dann natürlich mit QlikView ausgewertet werden.

Audit Log für Änderungen in QMC kann in Config File aktiviert werden

Häufig wird bei Hardware Sizing nur über das Qlik Server Service gesprochen. Die harte Arbeit der Datenaufbereitung übernimmt in der Nacht jedoch das Publisher Modul. Viele kleinere bis mittlere Qlik Installationen nutzen für diese (nächtliche) Beladung die gleiche Maschine. Das geht oft gut, doch kämpfen Server und Publisher dann häufig um die gleichen Memory- und CPU-Ressourcen, was über die Zeit bei wachsenden Datenmengen zu unerwünschten Verhalten führt. Um die notwendigen Ressourcen für den Publisher besser monitoren zu können, installiert Qlik - gut versteckt - einige Indikatoren in Microsoft Perfmon.

Das QlikView Server Service ist sehr aggressiv in seiner Memory-Consumption. Ähnlich eines Datenbankservers reserviert es Memory (WorkingSet) vor, da es annimmt, das wichtigste Service am ganzen System zu sein. Auch in der Nacht hält das  QlikView Server Service sein Memory (vor allem wenn es das untere Workingset schon einmal erreicht hat), was dazu führt, dass für die Reloads nur wenig freier Speicher zur Verfügung steht. Laufen dann noch mehrere Reloads gleichzeitig, kann es mit Memory auf einer einzelnen Maschine schnell knapp werden.

Für QMC-Administratoren ist es oft schwierig zu sagen, wann wieviel Tasks gleichzeit laufen und wieviel Last vom Publisher (bzw den qvb.exe des Distribution Services) dabei produziert wird. Seit QlikView 11.20 SR7 kann man sich zwar in jedem TaskLog eine Summary zeigen lassen, das gibt aber kein vollständiges Bild wie sich die Beladungen über einen vollen Nacht-Zyklus inklusive aller Abhängigkeiten verhält.

Um zu verstehen was nächtens bei den Reloads am Server so passiert, gibt es ein gut verstecktes Feature: Das QlikView Distribution Service registriert einige Performance Counter Indikatoren in Microsoft's PerfMon Tool das in jeder Windows Version zur Verfügung steht.

PerfMon - Performance Counter Indikatoren vom QlikView Distribution Service

Nicht alle Indikatoren sind ganz verständlich (und werden wohl nur vom Qlik Support genutzt), aber um sich einen Überblick zu verschaffen, benutze ich gerne

• # of running tasks .. wieviele Tasks (qvb.exe) laufen gerade
• Current QVB CPU Load .. CPU Zeit die von den Reload Tasks verbraucht wird.
• Current QVB memory Usage .. den absoluten Wert kann ich nicht ganz nachvollziehen, aber er zeigt Arbeitsspeicher-Ausreißer bei großen JOINs usw.

Zusätzlich kann man einige Standard Windows-Indikatoren wie Arbeitsspeicher und Prozessorzeit (%) dazuhängen, um das Gesamtsystem zu überwachen.

Die nächsten Sceenhshots zeigen ein Beispiel wie Perfmon den Verlauf über die Zeit mitprotokolliert.



Die hellgrüne Linie zeigt die 4 gerade laufenden Tasks der QMC. Die Dunkelgrüne zeigt die Summe der verbrauchte CPU Zeit dieser Tasks (in Summe vier qvb.exe, in Screenshot sieht man nur eine qvb.exe im Taskmanager, da alle anderen gerade keine CPU verbrauchen). Rot+Blau gestrichelt zeigen den Zustand des gesamten Servers. Die gelbe Linie "Current QVB memory usage" kann ich in absoluten Zahlen nicht deuten, ist aber eine interessante Information um ressourcenfressende Skripte zu entdecken.

Werden die Reloads nach der Reihe fertig abgearbeitet, fallen auch die zwei grünen Linien entsprechend. Siehe unterhalb Screenshot mit nur noch einem laufenden Reloadtask.





Bei größeren Installationen - oder falls Sie viele untertägige Reloads fahren - empfehlen wir immer das Aufteilen der zwei Services "QlikView Server Service" und "QlikView Distribution Service (aka Publisher)".  Im Zeitalter der Virtualisierung und noch immer fallender Memory-Preise ist ein Deployment mit zwei Maschinen vorzuziehen. Beide Services können die vollen Ressourcen Ihrer Maschine nutzen, und kommen sich auch unter hoher Last nicht in die Quere.

Ein exemplarisches Deployment auf  zwei Maschinen für "PRODUKTIV"

 Wo das ManagementService und der Webserver läuft, ist zu vernachlässigen. Manchmal setzt man dafür auch eine dritte Maschine ein.