• Thomas Pollinger
• 22.07.2019
• DE

How-To: Optimierung einer Cluster-Installation

Damit ein Web Site Management (WSM) Server Cluster optimal arbeiten kann, ist es notwendig von der Grundeinstellung des Systems abzuweichen und sich der optimalen Einstellung schrittweise zu nähern. Der Management Server liefert dazu zahlreiche Möglichkeiten, an denen man Verändungen vornehmen kann. In diesem Artikel möchte ich die Erfahrungen mit unserem Management-Server-Cluster teilen und erläutern, wie man sich schrittweise einer solchen Konfiguration annähert.
 

Welche Möglichkeiten gibt es denn zur Optimierung?

Als erstes möchte ich euch eine Auflistung der bekannten Möglichkeiten zur Optimierung eines Single- und Cluster-Nodes aufzeigen. Dazu gab es vereinzelt schon mehrere Artikel und diese möchte ich hier nach Themenbereichen auflisten:

Logging:

• Schon gewusst? "Anpassung der Log-Level für Standardkomponenten"
• Kleine Tipps für Zwischendurch (Nr. 3)
• Zentrale Logdateiverwaltung in einem Management Server Cluster

Prozesse:

• Gewusst wie! "Cluster-Communication optimieren"
• How-To: Performance-Steigerung durch intelligente Prozess-Verteilung

Session-Handling:

• How-To: Asset-Manager zu Asset-Folder (Tipps & Tricks)
• Root Cause Analysis: "Session Timeout bei Asset-Folder und Template Editor"
• Gewusst wie! "Session-Timeout im Template-Editor oder AssetFolder?"

Projektbau:

• oshyn: OpenText Delivery (Live) Server Performance tuning strategies
• Schon gewusst?: "Minifizierung von Stylesheets und Javascript-Dateien"
• Schon gewusst? "Projektreports"
• Schon gewusst? "Ordner-Freigabe und Seite exportieren sind ein Team!"
• Gewusst wie! "Recycling mit der Ordner-Freigabe"
• Gewusst wie!: "Projekthygiene leicht gemacht"
• Kleine Tipps für Zwischendurch (Nr. 1)
• Kleine Tipps für Zwischendurch (Nr. 5)

RQL/RenderTags:

• OpenText™ | RQL-Commands
• OpenText™ | RenderTags
• OpenText™ | RDExecute & PreExecute
• Kleine Tipps für Zwischendurch (Nr. 15)

Updates:

• Warum lässt sich ein Update einmal schnell installieren und das andere mal nicht mehr?

 

Was kann man nun noch machen, damit ein Cluster effizienter läuft?

Es gibt noch weitere Möglichkeiten, wie man seinen Management Server Cluster optimieren kann. Dazu ist es aber nötig, dass man sein System gut kennt. Wie z.B. Hardware, Auslastung über einen bestimmten Zeitraum (ideal 30-90 Tage) und die Projekte bzw. die Publizierungslast.

Wenn man diese Daten gesammelt und ausgewertet hat, dann ist man in der Lage diese Einstellungen zu optimieren:

Main.config:

<PageBuilder>
    <!-- The threshold in MB of used ServerService memory that triggers a PagebuilderCache clean up operation. -->
    <PageCacheMemoryThreshold>12288</PageCacheMemoryThreshold> <!-- 33% -->
</PageBuilder>

ObjectProcessServer.config:

<appSettings>
    <add key="RenderSpotError" value="false"/>
    <add key="UsePreCaching" value="false"/>
    <!-- Use multiple threads to render NavigationOutputAreas  -->
    <add key="MultiThreadRendering" value="true"/>
    <!-- The number of threads that are used to render NavigationOutputAreas -->
    <add key="RenderThreads" value="80"/>
    <!-- The number of threads used to work on cluster updates -->
    <add key="ClusterThreads" value="100"/>
    <!-- The time between cache cleanup runs -->
    <add key="CacheServiceTimer" value="00:01:00"/>
    <add key="CacheTimeStampTimer" value="00:00:05"/>
    <add key="CacheMonitoring" value="0"/>
    <!-- Threshold for cache release in MB -->
    <add key="CacheMemory" value="12288"/> <!-- ca. 35% -->
    <!-- Release percentual number of items in the cache in case of a cache memory threshold violation  -->
    <add key="CacheRelease" value="30"/>
    <add key="ClientSettingsProvider.ServiceUri" value=""/>
</appSettings>

Nach einer weile haben wir folgendes Berechnungsmuster erarbeitet, welches bei uns die besten Ergebnisse geliefert:

<add key="RenderThreads" value="80"/>

Berechnung:   1 Core  =  4 RenderThreads
Einstellung: 20 Cores = 80 RenderThreads

<add key="ClusterThreads" value="100"/>

Berechnung:  1  Cluster-Node  =  10 ClusterThreads
Einstellung: 10 Cluster-Nodes = 100 ClusterThreads

<add key="CacheMemory" value="12288"/>

Berechnung:  ca. 35% des verfügbaren RAM
Einstellung: bei 32.768 MB = 12.288 MB (12x 1024MB)

<PageCacheMemoryThreshold>12288</PageCacheMemoryThreshold>

Berechnung:  ca. 35% des verfügbaren RAM
Einstellung: bei 32.768 MB = 12.288 MB (12x 1024MB)

Mehr haben wir abweichend vom den Default-Einstellungen nicht verändertund das Ergebnis konnte sich mehr als nur sehen lassen.

• 80-90%ige Auslastung der verfügbaren Hardware (CPU, Speicher).
• Bessere und schnellere Kommunikation zwischen den Cluster-Nodes.
• Optmimiertes Gesamtsystemverhalten (Antwortzeiten).
• Signifikant weniger Warnungen und Fehlermeldungen im wsms.log.

 

Fazit

Ein System mit den Default-Einstellungen zu betreiben ist erstmal nicht verkehrt, aber auch nicht optimial. Man sollte den Management Server immer an die eigenen Gegebenheiten anpassen und diese kontinuierlich überwachen bzw. nachjustieren. Denn ohne Grund gibt es nicht diese Möglichkeiten der Optimierung in den Konfigurationsdateien seitens OpenText. 

Ebenso ist eine Systemüberwachung, CPU, Speicher, I/O, Netzwerk, Threads und Prozesse nicht schädlich. Es erweitert das Verständnis für das eigene System. Liefert Erkenntnisse über das Systemverhalten bei unterschiedlichen Szenarien und kann auch selten auftretende Fehlverhalten ggfs. schneller aufdecken. 

Nun viel Spaß beim überwachen und optimieren :)

---

Über den Autor: