QlikView + Qlik Sense Blog von Heldendaten

Die Qlik Knowledge Base zieht gerade um. Ich mochte die alte Qlik Knowledge Base eigentlich immer ganz gerne, wenn man eine konkrete Problemstellung/Logentry hatte. Die Suche hat stets sehr gut funktioniert. In der neuen Knowledge Base darf man zu den Artikeln Kommentare verfassen, um so direkt mit dem Qlik Support Mitarbeitern diskutieren und direktes Feedback geben zu können.

Die neue Qlik Support Section auf der Qlik Community

Wofür die Knowledge Base meiner Meinung nach nicht sehr gut funktioniert: sich einen Überblick über mögliche Einstellungen zu verschaffen. Man muss also zuerst auf ein Problem gestoßen sein, bevor man in der Knowledge Base etwas dazu finden kann. 

Sowohl in der alten als auch in der neuen Knowledge Base ist mir kein Eintrag bekannt, der alle Easter Egg Settings für den QlikView Server bzw. die Qlik Sense Engine auflistet. Über die letzten Jahre haben wir hier einige Einträge gesammelt und - wenn vorhanden - den jeweiligen Knowledge Base Artikel verlinkt. 

Die Liste ist ziemlich sicher nicht vollständig, aber über folgende Easteregg - die man in der Settings.ini manuell eintragen muss - sind wir bisher "gestolpert".

User Selektion im AJAX Client Excel Export

SelectionStampInBIFFExport=1

https://support.qlik.com/articles/000002517

QlikView 12.20 Fibre Loop Event Log entries

DisableCacheQueue=1

https://support.qlik.com/articles/000059269

 

AAALR Message in QlikView Server EventLog

DisableNewRowApplicator=0

https://support.qlik.com/articles/000019323

 

Lizenzinformationen von QVS auch als XML Datei

PgoAsXmlAlso=1

https://support.qlik.com/articles/000052992

 

Altes QlikView Set Analysis Verhalten (vor QlikView 12.20)

EnableSingleQuoteExactSearch=0

https://support.qlik.com/articles/000063567

 

QlikView Server Cache leeren

ClearCacheTimesPerDay=1
http://blog.heldendaten.net/2017/05/qlikview-server-das-gerucht-vom.html

 

QlikView 12.50 und Qlik Sense Sept 2019 Overload Protection

Dieses Setting ist so geheim, das hat nicht einmal einen Knowledge Base Artikel. Folgende Infos von R&D:

The new timeout setting is called OverloadExpireTimeSeconds.

 

It triggers before the working set parameter low (Min memory usage setting) is reached and it works "retroactively", so that a document that hasn't been used for that period of time is removed from memory the instant an overload situation is detected. The purpose is to preserve the QIX Engine's ability to cache results.

 

Please note: a worst-case scenario what happens with this setting on a server that is fundamentally overloaded, is that a document that is really needed could theoretically be unloaded over and over again, creating even greater load on the server.

In Qlik Sense we can't set the timeout per document. In Qlikview there is a document property that can specify the document's timout. By default this is not set, but it can be changed.

If this document timeout is set in the document, it still applies--overload or not. Which makes sense really, as it's an admin decision to set this timeout, with the purpose of controlling document life-time.

 

Bookmarks / Mail Bookmark as Link – wann verschwindet das Lesezeichen

ServerTempBookmarkDayTimeout=N

https://support.qlik.com/articles/000002746

 

Qlikview 12.30 SKIA Rendering back to GDI+

GraphicsBackEnd=0

https://support.qlik.com/articles/000063181

 

QlikView Server Debug Logging

Verbosity=900
SystemLogVerbosity=5

 https://support.qlik.com/articles/000003953

 

AJAX Container Box Darstellung – Labels abgeschnitten

NavigationAreaSizedOnlyByLabels=1
https://support.qlik.com/articles/000059276

 

Excel Export Settings

https://support.qlik.com/articles/000040322

 

Option Name	Meaning	Default Value
SELOG_Export	if print out log message related to Export function. 0: disable 1: enable	1
SendToExcelLegacyFormat	default "Send To Excel" behavior. 1: Legacy mode, export to xls 0: new mode, export to xlsx	0
QvExportTimeLimitSec	Time limit for exporting object to Xlsx. Integer number in seconds. Use -1 if you don't want time limit;	Server: 180 Desktop: -1
QvExportMemoryLimitMB	Memory limit for exporting object to Xlsx. Integer number in MB. Use 0 if you don't want memory limit;	0

 

ExcelExportMixedAsText = 1
https://support.qlik.com/articles/000004098

 

Files/Pics aus dem Internet (zB Google Maps) werden nicht geladen

https://support.qlik.com/articles/000036107

 

WebFileUseWinAPI = 1 für Server und QVB.exe in Settings.ini ergänzen

AllowGeneralAccessToImagesThroughURL =1

https://support.qlik.com/articles/000023882

WebFileConnectorProxyServer=http://proxy server address
WebFileConnectorProxyPort=proxy server port

 

AJAX Hide Print und Export für neue Tables

PrintAndXLIconsForNewTables=0

https://support.qlik.com/articles/000003846

 

No/some mapping between account names and security IDs was done

 TranslateNameDisabled=1

https://support.qlik.com/articles/000002530

 

 

Session Recovery Bookmark ohne Layout

EnableApplyLayoutState=0

QlikView 11.20 SR13 introduces a server side setting that allows disabling layout state information from the session recovery bookmark. With the layout state disabled, only selections are saved in the session recovery bookmark. This means that a session will not recover to the sheet where the session was close, but instead to the application's default sheet. A bookmark without layout state information is smaller and will not require as much CPU time to be processed.

 

https://support.qlik.com/articles/000102075

https://support.qlik.com/articles/000036135

https://support.qlik.com/articles/000007868

 

Thumbnail am Accesspoint schneller aktualisieren

QvThumbnailCacheUpdateInterval=2

https://support.qlik.com/articles/000038326

ChartLegendCutoff=5000

https://support.qlik.com/articles/000047154

QvMetaInterval=5

If QvMetaInterval is set to 0, preloads are performed every time the folders are scanned. QvMetaSecondsToWaitBetweenScans

 https://support.qlik.com/articles/000019962

Bevor in der Current Selection Box "9 von 123" Werten steht kann man hier den Wert erhöhen

MaxCurSelEntries=100

https://support.qlik.com/articles/000002564

https://support.qlik.com/articles/000062587

 

QixPerformanceLogVerbosity=3

 

Enter desired values for the four measurement levels

WarningProcessTimeMs=30000

ErrorProcessTimeMs=60000

WarningPeakMemory= 1073741824

ErrorPeakMemory= 2147483648

MaxRecurLevelForDefaultMissingAggr=nnn

https://support.qlik.com/articles/000005552

ServerTempSecTimeout=15

RemoveExcelAfterDownload=1

https://support.qlik.com/articles/000002443

MaxActionLevel=N

https://support.qlik.com/articles/000027187

Aus den QlikView 12.20 SR1 Release Notes

For AJAX clients, it is now possible to change the default value for who is allowed to see a note connected to an object.

 

To change the sharing settings, you must modify the following entry in the settings.ini file:

NoteSharingDefaultAccess=0 Only the creator can see the note.

NoteSharingDefaultAccess=1 The note visibility is set to public and anyone can see the object (Default setting).

NoteSharingDefaultAccess=2 Visibility is restricted to specific user

SilentErrorInChart=1

https://support.qlik.com/articles/000014364

Ü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!).

QlikView 12 ist Ende 2015 auf der Download-Seite verfügbar gemacht worden. Und endlich (erstmals seit QlikView 9) wurde auch das Entwickler-Team Bild wieder aktualisiert! Schön die alten (und viele neue) Kollegen mal wieder zu Gesicht zu bekommen :-)

In QlikView 12  GA wurde das DevTeam.jpg EasterEgg aktualisiert

Wie man bei unseren altem Blogpost von März 2013 nachlesen kann, war das versteckte Bild jetzt einige QlikView Versionen gleich geblieben. Nutzt man die .qvw Applikation in QlikView 12, sieht man jetzt das aktualisierte Bild. Danke an Johan Asplund, der diese alte Tradition scheinbar wieder zum Leben erweckt hat :-)

Erste Reviews und Änderungen findet man zB bei Rob Wunderlich. Bei einer Serverinstallation bitte momentan noch mit Bedacht vorgehen! Die Publisher Reloads dürften in einigen Fällen langsamer laufen als in QlikView 11.20SR13. Ein Workaround ist bekannt, wir raten unseren Kunden aber vorerst noch auf Version 11 zu bleiben.

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.

Der Hitze geschuldet nur ein schnelles Update: Der Hauptgrund für das QlikView 11.20 Service Release 12 haben wir unseren Kunden natürlich sofort kommuniziert. Das neue Verhalten des QlikView Developers bei ungültigen Expressions seit SR11 führt zu einigen weißen Boxen wo früher Diagramme waren. Wer sich damit nicht abfinden möchte, findet das Easter Egg bei Rob Wunderlich zum Nachlesen um wieder das alte Verhalten herzustellen.

Ein neues Setting möchte ich den Fans von gestapelten Balkendiagrammen natürlich nicht vorenthalten: Um neben den Segmentwerten auch die Gesamthöhe des Balkens zu beschriften, gibt es nun die Einstellung "Still Show Total on Top". Siehe Screenshot unterhalb.

SR5 kann es noch nicht. Aber SR12 zeigt die Summe des Balkens nun dank "Still Show Total on Top"

Ältere QlikView Versionen (wie links im Screenshot SR5) ignorieren die Einstellung. Mit SR12 sehen Sie nun auch die Summe auf den Balken. Finden wir gut! Aber jetzt ab ins Freibad :-)

Selbst dem erfahrensten QlikView Entwickler passiert es manchmal: man baut ein Diagramm, das nicht und nicht zu rechnen aufhören will. Vermutlich hat man unabsichtlich ein kartesisches Produkt, oder irgendetwas Ähnliches produziert.

Der QlikView Developer ist äußerst gutmütig und versucht jedes Objekt "fertig" zu rechnen. Entweder kann man auf eine ausgedehnte Kaffeepause gehen, oder man verliert die Nerven und beendet die Qv.exe im Taskmanager. Besonders bitter wenn das letzte Speichern der .qvw Stunden zurückliegt ("Benutzereinstellungen|Speichern|Wiederherstellungsdatei anlegen" hilft doch manchmal).

Der QlikView Server kennt die Einstellung "Object Calculation Time Limit". Defaultmäßig gibt der Server  das Berechnen eines Objektes nach 60 Sekunden auf. 60 Sekunden stimmt nicht ganz, denn meiner Meinung nach multiplizieren sich diese 60 Sekunden mit Anzahl der Cores am Server. Hat man also 8 Cores, versucht der Server 8 Minuten lang ein Objekt zu berechnen >> viel zu lange, weswegen wir dieses Setting gerne auf 5 oder 10 Sekunden stellen.

Der Screenshot zeigt einen QlikView Server mit "Object Calculation Time Limit" von 10Sek*4Cores = 40 Sek

Am QlikView Developer gibt es diese Einstellung ebenfalls --> allerdings nur  versteckt mittels Eintrag "ObjectTimeLimitSec" in den QlikView Easter Eggs. Defaultmäßig ist der Wert auf -1 (unendlich), weswegen der QlkView Developer eben nie aufhört das Objekt zu rechnen. Gerade während der Entwicklung ist es jedoch sinnvoll, die Berechnung von fälschlicherweise definierten "Langläufern" nach einer gewissen Zeit abzubrechen. Unterhalb ein Video und ein Screenshot wie Sie den Wert ändern können.

Rechtsklick auf das QlikView Logo zeigt den Easter Egg Dialog.

Wer also vor sich selbst und seinen Entwicklungskünsten in Schutz genommen werden möchte, setzt den Wert "ObjectTimeLimitSec" zum Beispiel auf 10! Zum Testen können Sie diese .qvw herunterladen, die ein Tabellendiagramm mit kartesischen Produkt beinhaltet. --> Haben Sie "ObjectTimeLimitSec" korrekt gesetzt, sehen Sie die Fehlermeldung "Timeout bei Berechnung".

Auf den Versuch das fehlerhafte Chart zu rechnen....

... folgt die Fehlermeldung "Timeout bei der Berechnung"

PS: die meisten Einstellungen in den Easter Eggs lassen sich über den normalen Benutzereinstellungen-Dialog ändern. Einige "Versteckte" gibt es trotzdem.  Einen zweiten Eintrag den ich gerne setze ist "DataPreviewSize" --> dann bekommt man mehr Zeilen  in der Tabellen-Vorschau unter der CTRL+T "Tabellenstruktur" Ansicht.

1000 statt 100 Zeilen im Tabellenstruktur Preview

PPS: Support gibt es für diese Easter Eggs natürlich keine :)

Bevor sich alle auf die Suche nach ihren Ostereiern begeben, hier noch schnell ein Beitrag über ein schönes Easter Egg im QlikView Developer: Seit der ersten QlikView-Version gibt es in jedem Release ein verstecketes Bild der QlikView-Entwicklungsmannschaft aus Schweden.

Die ganz alten Versionen finden sich leider nicht mehr zum Download, aber folgende Bilder lassen sich seit der Version 7 finden:

Version 7 & 8 - scheinbar das Bild aus Qlikview 6

Version 9 und aufwärts

qmem://<bundled>/DevTeam.jpg

und wählen Sie unter Eigenschaften|Allgemein|Representation den Eintrag Bild! Oder Sie laden sich die Applikation hier herunter!