5DE9E6D2579F48DEBD46D81D4E248FF2
  • 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:

Prozesse:

Session-Handling:

Projektbau:

RQL/RenderTags:

Updates:

 

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:
Thomas Pollinger

... ist Senior Site Reliability Engineer bei der Vodafone GmbH in Düsseldorf. Seit dem Jahr 2007 betreut er zusammen mit seinen Kollegen die OpenText- (vormals RedDot-) Plattform Web Site Management für die deutsche Konzernzentrale.

Er entwickelt Erweiterungen in Form von Plug-Ins und PowerShell Skripten. Seit den Anfängen in 2001 (RedDot CMS 4.0) kennt er sich speziell mit der Arbeitweise und den Funktionen des Management Server aus.