• Thomas Pollinger
• 05.07.2019
• DE

How-To: Performance-Steigerung durch intelligente Prozess-Verteilung

Im Artikel Gewusst wie! "Optimierung der Asynchronen Prozesse" hatte ich schon mal erläutert, dass man die asynchrone Prozess-Queue selbst auf seine Bedürfnisse anpassen kann. Mit diesem Artikel möchte ich gerne eine Erkenntnis teilen, welche die Performace innerhalb eines Management Server Clusters für die Publizierung steigern kann. Zusätzlich erläutere ich noch wie man zeitgleich dies für bestimmte Projekte individuell einstellen kann.
 

Beobachtung

Wir haben bei uns über unser Monitoring für eine sehr lange Zeit beobachtetet, dass einzelne Nodes während der nächtlichen Publizierung immer mehr Last hatten als andere:

Wir haben uns dann immer gefragt, warum das so ist. Dazu haben wir uns ebenfalls angeschaut, welche Publizierungsaufträge auf welchem Knoten innerhalb des Clustern verarbeitet werden.
 

Erkenntnisse

Man muss wissen, dass die Verteilung der Publizierungsaufträge in der Queue aktuell wie folgt durchgeführt wird:

• Alle Aufträge werden zentral in eine Queue gepackt, egal aus welchem Projekt.
• Der erste Server, welcher diese Queue abfragt ob es was zu tun gibt, nimmt sich soviele Aufträge wie Platz in seiner Prozess-Queue ist.
• Der nächste Server, sofern man mehrere hat, macht das gleiche.
• Dies wird solange durchgeführt, bis die zentrale Queue keine Aufträge mehr mehr.

Nehmen wir mal folgendes Beispiel an:

• Innerhalb des Clusters stehen 4 Knoten für die Publizierung zur Verfügung.
• Jeder dieser Knoten darf bis zu 25 Aufträge verarbeiten. 
• Es werden um 21:00 Uhr aus 4 Projekte je 15 Publizierungs-Aufträge gestartet.

Nun passiert folgendes:

• Einer dieser 4 Knoten, fragt an die zentrale Prozess-Queue an und 25 Slots frei.
• Dann nimmt dieser Knoten von den 60 Aufträgen die ersten 25 raus und startet die Verarbeitung.
• Nun kommt der nächste Knoten und schaut auch in die Queue, dieser hat auch 25 Slots frei.
• Jetzt schnapp sich dieser Server die nächsten 25 Aufträge und startet die Verarbeitung.
• Wenn nun der nächste Server (auch 25 Slots) anfragt, würde dieser noch die leutzten 10 Auträge bekommen.
• Sobald dann der letzte Knoten seine Abfrage startet, ist nichts mehr vorhanden.
• Dieser Knoten legt sich dann wieder schlafen.

Man kann sehr gut daran erkennen, dass von 4 Publizierungs-Knoten im Cluster gerade mal 3 was zu tun haben. Davon 2 leider dann sehr viel und einer macht nichts.

Der Management Server teilt also keine Aufträge nach bestimmten Regeln zu. Es wird das Prinzip "Wer zu erst fragt, bekommt die soviele Aufträge wie verarbeitet werden können". Das ist bei großen Systemen mit vielen Aufträgen ungeschickt. Hier wäre z.B. eine Verteilmechanik wie RoundRobin oder nach aktueller Auslastung besser.
 

Lösung

Mit der Erkenntnis haben wir uns nun gefragt, wie könnte man das Verhalten so in den Griff bekommen, dass die Verteilung nahezu optimal wird. In diesem Moment kam mir mein alter Artikel Gewusst wie! "Optimierung der Asynchronen Prozesse" wieder in den Sinn.

Wir sind dann viel folgt vorgegangen:

• Wir haben die Projekte bestimmte, welche die meisten Aufträge erzeugt.
• Dann haben wir die Prozess-Queue für die restlichen Projekte auf (Asynchronous Queue) 10 Prozesse je Knoten beschränkt.
• Anschließend haben wir für jedes zuvor ermittelte Projekt eine individuelle Queue (Asynchronous Queue) mit je 5 Prozessen konfiguiert.
• Dies wurde dann je Publizierungsserver vorgenommen.

Bei uns sieht die prozessserver.config nun wie folgt aus:

<?xml version="1.0" encoding="utf-8" ?>
<Configuration>
    <!-- ProcessServer -->
    <ProcessServer>
        <!-- ProcessServer Worker -->
        <WorkerAssemblies>
            <!-- Worker SpikeWorker -->
            <Worker type="OpenText.WS.MS.ProcessServer.SupportInformation.SupportInformationWorker">
                <Assemblies>
                    <Assembly driver="C:\OpenText\WS\MS\Assemblies\OpenText.WS.MS.Server.dll" />
                    <Assembly typecontains="1" driver="C:\OpenText\WS\MS\Assemblies\OpenText.WS.MS.Server.dll" />
                </Assemblies>
            </Worker>
            <!-- Worker RQLWorker -->
            <Worker type="OpenText.WS.MS.ProcessServer.Rql.RQLWorker">
                <Assemblies>
                    <Assembly name="OpenText.WS.MS.Server" typecontains="1" driver="C:\OpenText\WS\MS\Assemblies\OpenText.WS.MS.Server.dll" />
                </Assemblies>
            </Worker>
        </WorkerAssemblies>
        <!-- ProcessManagers Settings -->
        <ProcessManagers>
            <ProcessManager name="Default Manager" threads="10" priority="3" default="1">
                <Processes>
                    <Process name="OpenText.WS.MS" />
                </Processes>
            </ProcessManager>
            <ProcessManager name="Instant Manager" threads="100" priority="2">
                <Processes>
                    <Process name="OpenText.WS.MS.PageCache.Directory.Delete" />
                    <Process name="OpenText.WS.MS.PageCache.Update" />
                    <Process name="OpenText.WS.MS.ImageCache.Update" />
                    <Process name="OpenText.WS.MS.Page.Saveversion" />
                </Processes>
            </ProcessManager>
            <ProcessManager name="Asynchronous Queue" threads="10" priority="3">
                <Processes>
                    <Process name="OpenText.WS.MS.Publishing" />
                    <Process name="OpenText.WS.MS.Publishing.Queue" />
                    <Process name="OpenText.WS.MS.Task" />
                    <Process name="OpenText.WS.MS.Application.Start" />
                    <Process name="OpenText.WS.MS.Escalation" />
                    <Process name="OpenText.WS.MS.Page.Forwarding" />
                    <Process name="OpenText.WS.MS.Search" />
                    <Process name="OpenText.WS.MS.Validate" />
                    <Process name="OpenText.WS.MS.ExportSettings.Copy" />
                    <Process name="OpenText.WS.MS.Pages.Delete" />
                    <Process name="OpenText.WS.MS.WebCompliance.Validate" />
                </Processes>
            </ProcessManager>
            <ProcessManager name="Publishing Supporter" threads="20" priority="3">
                <Processes>
                    <Process name="OpenText.WS.MS.Publishing.Transfer" />
                    <Process name="OpenText.WS.MS.Cleaner.Ftp" />
                </Processes>
            </ProcessManager>
            <ProcessManager name="Live Server Cleaning" threads="5" priority="3">
                <Processes>
                    <Process name="OpenText.WS.MS.Cleaner" />
                </Processes>
            </ProcessManager>
            <ProcessManager name="Translation processes" threads="5" priority="3">
                <Processes>
                    <Process name="OpenText.WS.MS.Translation" />
                </Processes>
            </ProcessManager>
            <ProcessManager name="Asset Manager processes" threads="3" priority="3">
                <Processes>
                    <Process name="OpenText.WS.MS.Media.UpdateMetadata" />
                </Processes>
            </ProcessManager>
            <ProcessManager name="Asset Manager Folder Updates" threads="1" priority="3">
                <Processes>
                    <Process name="OpenText.WS.MS.Media.Folder.Update" />
                </Processes>
            </ProcessManager>
            <ProcessManager name="AskVodafone: Asynchronous Queue > Publishing + Publishing Queue" threads="5" priority="3">
                <Processes>
                    <Process name="OpenText.WS.MS.Publishing.8C681C01ECE44FC8B1FB45C4A7760501" />
                    <Process name="OpenText.WS.MS.Publishing.Queue.8C681C01ECE44FC8B1FB45C4A7760501" />
                </Processes>
            </ProcessManager>
            <ProcessManager name="AskVodafone: Publishing Supporter > Transfer" threads="10" priority="3">
                <Processes>
                    <Process name="OpenText.WS.MS.Publishing.Transfer.8C681C01ECE44FC8B1FB45C4A7760501" />
                </Processes>
            </ProcessManager>
            <ProcessManager name="AskVodafone: Publishing Supporter > Cleaner FTP" threads="10" priority="3">
                <Processes>
                    <Process name="OpenText.WS.MS.Cleaner.Ftp.8C681C01ECE44FC8B1FB45C4A7760501" />
                </Processes>
            </ProcessManager>
            <ProcessManager name="Vodafone Internet: Asynchronous Queue > Publishing + Publishing Queue" threads="5" priority="3">
                <Processes>
                    <Process name="OpenText.WS.MS.Publishing.072D6659A806425BACA8D29F37FD6E7D" />
                    <Process name="OpenText.WS.MS.Publishing.Queue.072D6659A806425BACA8D29F37FD6E7D" />
                </Processes>
            </ProcessManager>
            <ProcessManager name="Vodafone Internet: Publishing Supporter > Transfer" threads="10" priority="3">
                <Processes>
                    <Process name="OpenText.WS.MS.Publishing.Transfer.072D6659A806425BACA8D29F37FD6E7D" />
                </Processes>
            </ProcessManager>
            <ProcessManager name="Vodafone Internet: Publishing Supporter > Cleaner FTP" threads="10" priority="3">
                <Processes>
                    <Process name="OpenText.WS.MS.Cleaner.Ftp.072D6659A806425BACA8D29F37FD6E7D" />
                </Processes>
            </ProcessManager>
        </ProcessManagers>
    </ProcessServer>
</Configuration>

Wie man dies macht, steht im Artikel Gewusst wie! "Optimierung der Asynchronen Prozesse" und auch in der Online-Hilfe genau beschrieben.
 

Ergebnis

Direkt nach der Umstellung konnte man den positiven Effekt bereits sehen:

Die Verteilung der Publizierung wurde durch die o.g. Umstellung der Queue viel gleichmäßiger vorgenommen. Es ist zwar immer noch nicht perfekt, jedoch der Effekt wurde sogar bei unserern Anwendern bemerkt. Wir hatten, ohne aktives Nachfragen, folgende Rückmeldungen bzw. Rückfragen bekommen:

• Veröffentlichen von Seiten geht scheller, habt ihr irgend was gemacht?
• Meine vielen kleine Publizierungen waren sehr schnell online, liegt das an dem letzten Update?
• usw.

Wir waren selbst überrascht, dass man diese Änderungen so extrem positiv sogar bei den Anwendern bemerkt. Aber auch als Systemadministrator sieht man direkt den positiven Effekt.

Die Systeme werden weniger belastet, es wird besser verteilt und alle Knoten haben annähernd gleich viel zu tun.
 

Fazit

Die OotB-Einstellungen sind gut, aber nicht für jede Umgebung optimal. Doch dafür bietet der Management Server eine sehr flexible Möglichkeit, um das Systemverhalten für die Anforderungen entsprechend zu verändern. Dies bedeutet aber auch, dass man sein System (Cluster) beobachtet, kennt und so ein Verhalten darüber erkennt.

Wir sind derzeit mit der neuen Konfiguration der ProzessServerQueues sehr zufrieden und auch die Anwender haben dies sehr positiv bemerkt.

Jedoch würde ich mir auch wünschen, dass mit der Zeit die aktuelle Implementierung durch eine bessere Methode ersetzt wird, wie z.B. RoundRobin.

Jetzt viel Spaß bei der Systemoptimierung ;)

---

Über den Autor: