Dimensionierung der Hardware und Caching

Überblick

Wichtige Voraussetzung für eine hohe Benutzerzufriedenheit ist die gute Performance des Viewers. Die Performance hängt dabei stark von der zugrundeliegenden Hardwaredimensionierung und der damit einhergehenden Verfügbarkeit zugehöriger Ressourcen ab. Zeitgleich existiert in Projekten die betriebswirtschaftliche Anforderung die Kosten für die eingesetzte Hardware zu minieren. Aus Anwendersicht sollte die Hardware also möglichst großzügig dimensioniert werden, aus betriebswirtschaftlicher Sicht sollte die Dimensionierung möglichst knapp ausfallen. Eine Lösung für diese konkurrierenden Anforderungen stellt dabei die für die vorliegende Kundensituation passende Cachingstrategie dar, weil dadurch existierende Ergebnisse (insbesondere bereits gerenderte Seiten) mit geringem Ressourcenverbrauch bei erneuter Anfrage dem Viewer schnell zur Verfügung gestellt werden können.

Typischer Ressourcenverbrauch

Das jadice web toolkit besitzt zum einen einen serverseitigen Teil, der das anzuzeigende Dokument aus dem angebundenen Archivsystem abholt und anschließend für jede betrachtete Seite ein Rendering durchführt. Zum anderen besteht die Anwendung aus einer Vielzahl von browserbasierten Clients, über die die tatsächliche Anzeige für die Endanwender erfolgt. Da diese beiden Teile räumlich voneinander getrennt existieren, muss sowohl auf Server- als auch auf Clientseite dimensioniert werden.

Auf Clientseite kommt jeweils ein Browser als Standardanwendung zum Einsatz. Die Anforderungen an die CPU-Leistung fallen dabei typischerweise nicht ins Gewicht. Der Browser lädt die anzuzeigenden Seiten als Bilddateien im PNG-Format vom Serverteil und stellt diese dann dar. Dieses Vorgehen unterscheidet sich nicht von der Bildanzeige einer gewöhnlichen Website. Die heruntergeladenen Bilder können dabei vom Browser in seinem Standardcache gespeichert werden. Falls der Benutzer innerhalb des selben, geöffneten Dokuments scrollt und dabei auf eine bereits besuchte Seite zurückkehrt, wird diese nicht mehr vom Server heruntergeladen, sondern es wird die zugehörige Bilddatei aus dem Cache angezeigt. Damit erhöht sich die Performance und es findet eine Entlastung des Serverteils statt. Die Einstellungen für Größe und Verhalten des Browsercaches finden sich in der Dokumentation des jeweiligen Browserherstellers. Da die Anforderungen an die Größe des Caches stark von der Struktur der anzuzeigenden Dokumente und dem Nutzerverhalten abhängt, kann es keine generelle Empfehlung dafür geben. Eine passende Größe könnte so gewählt sein, dass beim Scrollen innerhalb eines Dokuments keine unnötigen Requests an den Serverteil ausgelöst werden.

Auf Serverseite kommt ein Servlet-Container oder Application Server zum Einsatz. Die Anforderungen an die CPU-Leistung werden dort zum überwiegenden Teil durch das Rendering bestimmt. Dabei wird der eine Seite repräsentierende Datenbereich einer Quelldatei (z.B. PDF, TIFF, AFP, etc.) in eine PNG-Datei gewandelt und dem Client zum Download zur Verfügung gestellt. Da jede von einem Client angezeigte Seite serverseitig gerendert wird, konzentrieren sich die zugehörigen Render-Requests an dieser Stelle. Um ein zügiges Abarbeiten der eintreffenden Render-Requests zu gewährleisten, sollten serverseitig ausreichend viele, leistungsstarke CPUs vorgesehen werden. Da die Anforderungen an die Rechenkapazität stark von der Struktur der anzuzeigenden Dokumente und dem Nutzerverhalten abhängt, kann es keine generelle Empfehlung dafür geben. Die empfohlene Methode für die Ermittlung, ob die serverseitige Rechenkapazität ausreicht, ist ein repräsentativer Performance-Test.

Jedes in einem Client anzuzeigende Dokument wird im ersten Schritt serverseitig geladen. Dabei wird das Dokument aus dem angebundenen Archivsystem entnommen und der zugehörige Stream komplett eingelesen. Beim Einlesen entstehen Strukturinformationen, wie z.B. die Anzahl der Seiten des Dokuments, etwaige Annotationen und deren Position innerhalb des Dokuments und viele mehr. Diese Informationen werden über einen anwendungsspezifischen, serverseitigen Cache im Arbeitsspeicher abgelegt. Zusätzlich werden dort auch diverse Zwischenergebnisse im Rahmen eines späteren Renderings abgelegt. Um eine gute Performance der Anwendung zu gewährleisten muss serverseitig ausreichend Arbeitsspeicher für diesen Cache vorgesehen werden. Da die Anforderungen an die Größe des Caches stark von der Struktur der anzuzeigenden Dokumente und dem Nutzerverhalten abhängt, kann es keine generelle Empfehlung dafür geben. Die empfohlene Methode für die Ermittlung, ob die Kapazität des serverseitigen Arbeitsspeichers ausreicht, ist ein repräsentativer Performance-Test.

In unserer Knowledge-Base finden Sie Erfahrungswerte, die als Starthilfe dienen können:
(JKB) Dimensionierung und Konfiguration des jadice web toolkit bei Inbetriebnahme

Serverseitiges Caching

Das Rendering von Dokumenten erfolgt im jadice web toolkit auf Serverseite. Die gerenderten Seiteninhalte eines Dokuments werden dabei in sogenannten Tiles (Kacheln) in Form von PNG- oder WebP-Bilddateien an den Browser zur Darstellung übermittelt. Bedingt durch die hohe Rechenintensität des Rendering-Prozesses werden erzeugte Tiles im Browsercache abgelegt. Soll eine bereits gerenderte Seite oder ein Thumbnail, z.B. wegen Hin- und Her-scrollen des Anwenders, erneut zur Anzeige gebracht werden, wird dies clientseitig erkannt und das bereits existierende Tile aus dem Browsercache entnommen. Dadurch reduzieren sich Rechenzeit und Prozessorauslastung und Seiteninhalte werden auf dem Client schneller angezeigt. Das clientseitige Caching wird durch den Expires-HTTP-Header und eine eindeutige URL der Tiles gewährleistet. Dieses Caching funktioniert in allen modernen Browsern sehr zuverlässig, ein serverseitiges Caching von Tiles wird daher in aller Regel nicht mehr benötigt.

Konfiguration

Die Konfiguration des serverseitigen Caches erfolgt programmatisch. Für gewöhnlich sind hier keine Anpassungen notwendig.

Programmatische Konfiguration

Standardmäßig ist ein passender Cache voreingestellt und das Caching von Tiles deaktiviert.

• Eigene Cache-Implementierung setzen

  Die API ermöglicht das Setzen eines alternativen Caches aus den levigo utils oder sogar das Setzen einer externen eigenen Cache-Implementierung. Letzteres ist z.B. dann nützlich, falls ein Application Server oder eine vergleichbare Komponente bereits besteht, die einen eigenen Cache mitbringt.

  Zur Nutzung des Fremd-Caches ist lediglich ein Adapter zu erstellen, der das Interface com.levigo.util.mm.Cache implementiert.

  Die integrationsseitige Initialisierung der Caches wird im Kapitel Einstiegspunkt des Webtoolkits beschrieben.

  Zudem werden von jadice web toolkit Caches mit den folgenden Namen benötigt:

  "jwt-documents"
  Wird unter anderem für Dokumenteninformationen benötigt. Die Inhalte dieses Caches lassen sich nicht serialisieren.

  "jwt-pagesegments" Wird unter anderem für Seiteninformationen benötigt. Die Inhalte dieses Caches lassen sich nicht serialisieren.

  "jwt-tile" Wird für das Tile-Caching benötigt. Die Inhalte dieses Caches können auch problemlos auf die Festplatte oder Off-Heap ausgelagert werden.

Diese Caches können ebenfalls über den CacheManager bekannt gemacht werden:
com.levigo.util.mm.CacheManager.setNamed("jwt-tile", myCacheImplementation)

• Tile-Caching aktivieren

  Das serverseitige Caching von Tiles lässt sich ganz einfach anschalten; Dokumentstrukturinformationen und andere Aspekte werden unabhängig davon immer gecached:

  ConfigurationManager.getServerSettings().setTileCachingEnabled(true)

• JCache (JSR 107)

  Um die Kompatibilität mit einem JCache herzustellen, existieren zwei Extensions, die im jadice web toolkit verwendet werden können.

  webtoolkit-extension-jsr107
  Diese Erweiterung enthält die Klasse com.jadice.web.ext.jsr107.JSR107CacheAdapter, welche einen JCache-kompatiblen Cache entgegennimmt und dann an den jadice CacheManager übergeben werden kann.

  webtoolkit-extension-jadice-jcache
  Wenn diese Erweiterung im Klassenpfad liegt, wird der jadice CacheManager als Cache-Provider registriert und die jadice Caches können als JCaches verwendet werden. Wird Spring Boot zusammen mit spring-boot-starter-cache verwendet, nutzt Spring Boot fortan jadice Caches, beispielsweise für mit @Cacheable annotierte Methodenaufrufe.

Konfiguration über die "Jadice.properties"

Deprecated

Die Konfiguration über Jadice.properties funktioniert zwar noch, sie ist jedoch nicht der empfohlene Weg. In zukünftigen Versionen kann diese Konfigurationsmöglichkeit möglicherweise entfallen. Die Konfiguration sollte nur noch programmatisch erfolgen. Sie haben so auch die Möglichkeit, eigene Properties-Dateien einzulesen, um die Konfiguration auf diesem Wege vorzunehmen.

Die Konfigurationsdatei Jadice.properties der jadice document platform 5 wird als Teil der Bibliothek jadice-document-VERSION.jar ausgeliefert. Sie kann dort extrahiert und bei Bedarf so angepasst werden, dass sich der Cache anders verhält.

• Maximalzahl von Cache-Einträgen: maxNumberOfCacheEntries

  Mögliche Werte: Integer. Default: 30000.

  Beispiel: Konfiguration der maximalen Anzahl an Objekten auf 30000

  jadice.viewer.cache.maxNumberOfCacheEntries=30000

  Die Größe des Caches kann unter anderem über die maximale Anzahl an Elementen, die enthalten sein dürfen, begrenzt werden. Wird diese Grenze überschritten, werden so lange Elemente aus dem Cache entfernt, bis er sich wieder unterhalb der gegebenen Obergrenze befindet.

• Maximalgröße des Caches in Bytes (HighwaterMark): sizeHighwaterMark

  Mögliche Werte: Integer (in Bytes).

  Beispiel: Konfiguration von maximal 512MB (512*1024*1024=536870912 Byte) Cache-Speicher

  jadice.viewer.cache.sizeHighwaterMark=536870912

  Neben der maximalen Anzahl von Elementen kann die Größe des Caches auch (zusätzlich oder ausschließlich) über seinen maximalen Speicherverbrauch definiert werden. Da die Größe in Bytes eine angenäherte Größe ist, kann man hier keine Exaktheit erwarten. Wird sie überschritten, werden so lange Elemente aus dem Cache entfernt, bis man wieder unterhalb dieser Grenze ist. Es ist auch möglich, eine dynamische Grenze für den Speicherverbrauch zu setzen, siehe sizeHighwaterMarkPercent.

• Maximalgröße des Cache in Bytes in Abhängigkeit des maximalen Heapspaces: sizeHighwaterMarkPercent

  Mögliche Werte: Integer (in Prozent). Default: 10.

  Beispiel: Konfiguration von maximal 25% des maximalen Heapspaces als Cache-Speicher

  jadice.viewer.cache.sizeHighwaterMarkPercent=25

  Ist keine sizeHighwaterMark gesetzt, so wird die Maximalgröße des Cache-Speichers anteilig zur Maximalgröße des Heapspaces ermittelt. Der in sizeHighwaterMarkPercent angegebene Wert gibt folglich an, wie viel Prozent des Heapspace dem Cache zustehen sollen. Ist dieser Wert fehlerhaft oder nicht angegeben, wird ein Default von 10% angenommen.

• Minimale Dauer, wie lange ein Eintrag gehalten werden soll: minimumExpiryAge

  Mögliche Werte: Integer (in Millisekunden).

  Beispiel: Konfiguration des Mindestalters auf 1 Sekunde (1000 Millisekunden)

  jadice.viewer.cache.minimumExpiryAge=1000

  Dieser Wert legt fest, wie lange Elemente mindestens im Cache verweilen, bevor sie beim Aufräumen entfernt werden.

• Prozentualer Anteil an Elementen, die beim Aufräumen verworfen werden sollen: maximumExpiryObjectCountRatio

  Mögliche Werte: Integer (in Prozent).

  Beispiel: Konfiguration des Anteils von Elementen, die jeweils entfernt werden sollen, auf 10%

  jadice.viewer.cache.maximumExpiryObjectCountRatio=10

  Dieser Wert gibt an, wie viel Prozent der aktuellen Elemente bei jedem Aufräumvorgang zwingend entfernt werden sollen, um Platz für neue Elemente zu schaffen.

Zusätzliche Konfigurationen in den Jadice.properties

Zusätzlich zu den Einstellmöglichkeiten der jadice document platform 5 bietet das jadice web toolkit einige weitere Konfigurationsmöglichkeiten in den jadice.properties. Eine Beispielkonfiguration ist in der Enterprise Demo enthalten.

• Aufräumen von überalterten Cacheeinträgen: maxAgeExpiryEnabled

  Mögliche Werte: true/false. Default: true.

  Beispiel: Cacheeinträge sollen nicht automatisch nach Erreichen des Maximalalters entfernt werden.

  jadice.viewer.cache.maxAgeExpiryEnabled=false

  Diese Einstellung legt fest, ob Cacheeinträge, die das in maxAge definierte Maximalalter überschreiten, aus dem Cache entfernt werden sollen.

• Maximalalter für Cacheeinträge: maxAge und maxAge.timeUnits

  Mögliche Werte: Integer bzw. String. Default: 60 MINUTES.

  Beispiel: Cacheeinträge sollen maximal 120 Minuten im Cache verbleiben dürfen.

  jadice.viewer.cache.maxAge=120 jadice.viewer.cache.maxAge.timeUnit=MINUTES

  Diese Einstellung legt fest, dass Cacheeinträge nach ihrer letzten Verwendung maximal 120 Minuten im Cache verbleiben dürfen. Die Werte für timeUnit müssen den Enum-Werten von java.util.concurrent.TimeUnit entsprechen.