• Thomas Pollinger
• 21.11.2016
• DE

Gewusst wie! "Optimierung der Asynchronen Prozesse"

Um ein System zu optimieren gibt es immer mehrere Möglichkeiten. Man kann z.B. die Hardware großzügig ausstatten oder Netzwerkanbindung leistungsstärker machen. Es gibt noch viele weitere Maßnahmen, welche für eine Leistungssteigerung eines Systems oder am Betriebssystem möglich machen.

Jedoch all dies bringt nichts, wenn die eigenliche Applikation auf diesem System nicht selbst optimiert. Das passiert, wenn nicht das komplette System für eine optimale Leistung und Skalierung betrachtet.

Denn man hat zwar mit leistungsstarker Hardware und Netzwerk-Instraktur den Tiger in den Tank gepackt. Jedoch wenn man auf das Gaspedal drückt, ist man immer noch nicht schneller oder optimal unterwegs ;)

Aus diesem Grund wird in diesem Artikel erläutert wie man über eine Optimierung der Asynchronen Prozesse, des OpenText™ Web Site Management (RedDot CMS) Servers, die Systemleistung verändern kann.
 

Asynchrone Prozesse

In der Online-Hilfe gibt es eine Anmerkung, welch wichtige Stellung Asynchrone Prozesse im System einnehmen:

Anmerkung – Asynchrone Prozesse
Der Management Server ist eine web-basierte Anwendung. Während andere Client-Anwendungen auf die Rückantwort von einem Server warten können, ist dies für einen browserbasierenden Client nur schwer möglich. Daher werden länger andauernde Programmfunktionen, beispielsweise die Publizierung von Seiten, gestartet, ohne dass der Client auf die Ausführung wartet. Der Client erhält lediglich eine Bestätigung, dass diese Funktion gestartet wurde. Diese speziellen, eigenständigen Programmfunktionen – die asynchronen Prozesse – können zudem parallel auf einem Server durchgeführt werden. Ist ein asynchroner Prozess beendet, wird dies in die allgemeine Datei wsms.log eingetragen. Wenn in den Voreinstellungen die Benachrichtigung über E-Mail aktiviert wurde, wird die Ausführung dem Benutzer in Form von E-Mails mitgeteilt.
(Quelle: OpenText™ WSM Mangement Server - Server Manager Online-Hilfe)
 

Asynchrone Prozesse verwalten

Damit man als System-Administrator diese Prozesse überwachen und bei diesen ggfs. auch eingreifen kann. Gibt es im Server Manager einen Dialog mit dem Namen Asynchrone Prozesse verwalten. Das ist eine Übersicht aller Prozesse, welche auf einem bestimmten Server aktuell abgearbeitet werden. Ebenso werden die restlichen Server innerhalb eines Management Server Clusters aufgelistet. Man ist somit in der Lage auch deren Warteschlagen und Prozesse einzusehen bzw. zu steuern.

---

Navigationspfad: ► Server Manager ► Start ► Anwendungsserver verwalten ► Anwendungsserver ► Asynchrone Prozesse verwalten

---

Im Server-Manager Handbuch der Online-Hilfe wird sehr gut beschrieben, wie ein asynchroner Prozesse Einfluß auf die Leistung des Management Servers hat und wie man in dem Dialog arbeitet:

Aufwändige Funktionen werden im Management Server asynchron ausgeführt, damit der Benutzer auch bei komplexen Prozessen performant weiterarbeiten kann. Diese Programmteile werden als asynchrone Prozesse bezeichnet. Hierbei kann es sich um komplexere Programmteile wie z. B. Publizierungen oder Projektimport/-export handeln, es können aber auch weniger komplexe Programmteile sein wie z. B. das Versenden einer E-Mail oder das Löschen von Seiten. Insgesamt treten im Management Server ca. 60 verschiedene Arten von asynchronen Prozessen auf. Da Benutzer diese asynchronen Prozesse in der Regel unbewusst auslösen, kann es zu Performance-Problemen kommen, wenn viele davon gleichzeitig angestoßen werden.

Die Komponente Process Manager übernimmt die Steuerung dieser asynchronen Prozesse. Der Process Manager sorgt dafür, dass nicht zu viele asynchrone Prozesse auf einmal gestartet werden. Die asynchronen Prozesse reihen sich zunächst in eine Warteschlange ein und werden dann abgearbeitet. Eine Überlastung des Systems wird dadurch vermieden.

Der Process Manager ist nach der Installation oder dem Update mit sinnvollen Vorgabewerten konfiguriert, so dass keine Anpassungen an der Konfiguration vorgenommen werden müssen. Konfigurationsanpassungen können in Ausnahmefällen sinnvoll sein, wenn der Server nicht voll ausgelastet ist und zu viele Prozesse warten oder aber, wenn der Server auf Grund zu vieler gestarteter Prozesse zu stark ausgelastet ist. Nur in diesen Fällen sollten Sie in Erwägung ziehen, Anpassungen an der Konfiguration vorzunehmen. Hierfür sollten Sie Hilfestellung vom Support oder Professional Service in Anspruch nehmen.

Im Dialogfeld Asynchrone Prozesse verwalten erhalten Sie einen Überblick über die Prozesse, die auf allen Anwendungsservern im Cluster laufen oder auf die Ausführung warten. Sie können die Prozesse stoppen, beenden oder ihre Priorität verändern.

Das Dialogfeld ist in zwei Bereiche aufgeteilt. Im linken Bereich werden die jeweiligen Anwendungsserver mit den jeweils dazugehörigen Warteschlangen dargestellt. Wenn Sie im linken Bereich einen Anwendungsserver oder eine Warteschlange auswählen, werden im rechten Bereich die Prozesse angezeigt, die entweder bereits laufen oder auf Ausführung warten.
(Quelle: OpenText™ WSM Mangement Server - Server Manager Online-Hilfe)

---

Tipp: Es gibt Tastaturkürzel, welche die nachfolgenden Aktionen im Dialog Asynchrone Prozesse verwalten ausführen:

• [R] Aktualisiert den ausgewählten Eintrag im linken Bereich im Dialog
• [F8] Aktualisiert den gesamten Dialog

---

Betriebssystem-Prozesse für asynchrone Prozesse

In den Unterlagen und vor allem in der neuen Online-Hilfe finden sich immer wieder nützliche Anmerkungen und Hinweise zu den asynchronen Prozessen. Hier eine Auszug davon:

Bisher wurden die asynchronen Prozesse im Management Server in Form von Betriebssystem-Prozessen mit dem Namen RDCMSDllHost.exe ausgeführt. Im Management Server 11 gibt es einen Windows Dienst (Windows Service) mit dem Namen OTWSMServerService. Im Task Manager heißt der Prozess OpenText.WS.MS.ServerService.exe. Alle asynchronen Prozesse werden in Threads innerhalb dieses Betriebssystem-Prozesses ausgeführt.

Hinweis: Beachten Sie, dass beispielsweise der Dienst OTWSMServerService bei einem notwendigen Neustart der Windows-Dienste des Management Server zum Beenden länger benötigt als andere Dienste. Der Grund dafür ist, dass in der Regel noch einige asynchrone Prozesse abgearbeitet werden müssen, bevor der Dienst beendet werden kann. Wir empfehlen daher, zunächst alle erforderlichen Dienste des Management Server zu stoppen. Warten Sie, bis alle Dienste gestoppt sind, und starten Sie sie dann wieder.
(Quelle: OpenText™ WSM Mangement Server - Server Manager Online-Hilfe)

Daher ist es immer von Vorteil sich die Dokumentation anzusehen und diese Hinweise entsprechend zu berücksichtigen.
 

Mit Warteschlangen im Process Manager arbeiten

In den Unterlagen zum Server-Manager gibt es auch eine sehr ausführliche Beschreibung zu den Prozessarten, deren Funktion und in welcher Warteschlage diese zu finden sind:

Eine Liste der Warteschlangen finden Sie im linken Bereich des Dialogfelds Asynchrone Prozesse verwalten, wenn Sie das Anwendungsserverelement erweitern. Standardmäßig gibt es sechs Warteschlangen im Prozessmanager mit bestimmten Prozessen. Sie haben auch die Option, getrennte Warteschlangen für einzelne Projekte zu konfigurieren.
(Quelle: OpenText™ WSM Mangement Server - Server Manager Online-Hilfe)

Standard-Warteschlangen im Process Manager:

• Default Manager:
  • Alle asynchronen Funktionen, die nicht in den anderen Warteschlangen verarbeitet werden.
• Instant Manager:
  • Seiten-Cache löschen
  • Seiten-Caches im Cluster aktualisieren
  • Image-Caches im Cluster aktualisieren
  • Versionsinformationen zu einer Seite speichern, wenn diese geändert wird
• Asynchrone Warteschlange:
  • Asset Manager aktualisieren
  • Assets in ein Verzeichnis exportieren
  • Dateien in den Asset Manager importieren
  • Assets verschieben
  • Assets löschen
  • Umfang der Versionierungsdaten reduzieren
  • E-Mail versenden
  • Publizierung
  • Workflow-Reaktion: Seite publizieren
  • Benachrichtigung, wenn Anwendungsserver im Cluster nicht erreichbar
  • Alle externen URLs in einem Projekt überprüfen
  • Alle Verweise auf andere Projekte überprüfen
  • Workflow-Reaktion: Automatischer Ablauf und Wiedervorlage von Seiten
  • Publizierungspaket an Unterstrukturen vererben
  • Publizierungspaket von Struktur-Element und Unterstrukturen abhängen
  • Projektreporte erstellen
  • Seitenweiterleitung
  • Benutzerdefinierte Aufträge
  • Seite(n) mithilfe des Web Compliance Managers auf Rechtschreibung prüfen
  • Suchen und Ersetzen
  • Start einer Anwendung vor/nach der Publizierung
  • Überprüfung von Datenbankservern
• Publishing Supporter:
  • FTP-Transfer, Transfer zum Delivery Server, Dateien vom Live-Server löschen
  • Dateien vom Live-Server löschen
• Live Server-Bereinigung:
  • Live-Server aufräumen
• WebCompliance:
  • Seite auf Web Compliance prüfen

(Quelle: OpenText™ WSM Mangement Server - Server Manager Online-Hilfe)

Hier das Beispiel der Konfigurationsdatei:

<?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="<%cmspath%>Assemblies\OpenText.WS.MS.Server.dll" />
          <Assembly typecontains="1" driver="<%cmspath%>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="<%cmspath%>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="10" 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="10" 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>
    </ProcessManagers>
  </ProcessServer>
</Configuration>

---

Tipp: Normalerweise ist es notwendig, bei jeder Änderung an einer Konfigurationsdatei, die Dienste neu zu starten. Jedoch gibt es eine Möglichkeit die Einstellungen ohne einen kompletten Neustart aller Dienste zu aktivieren. Als erstes verändert man die Datei %RDCMS%\processserver.main.config und speichert dieses ab. Anschließden klickt man links im Dialog Asynchrone Prozesse verwalten auf den Namen des Server mit der rechten Maustaste. Dann auf Process Manager herunterfahren und anschließend auf Prozesse beenden. Falls aktuell noch Prozesse aktiv sind, dann kann man auch alternativ den Befehl Warten bis Prozesse beendet nutzen:

Sobald der Process Manager heruntergefahren wurde, kann man diesen an der selben Stelle wieder neu starten. Mit dem Neustart des Process Managers werden auch die Änderungen an der %RDCMS%\processserver.main.config direkt übernommen:

Über diesen Weg ist man in der Lage, auch ohne alle Dienste neu zustarten, eine Änderung an der %RDCMS%\processserver.main.config also am Process Manager im Management (RedDot CMS) Server zu übernehmen.

---

Separate Warteschlangen für einzelne Projekte definieren

In der Online-Hilfe wurde man auch öfters erwähnt, dass man eigene Warteschlagen für einzelne Projekte definieren kann. Dazu auch wieder ein Auszug aus der Online-Hilfe:

Die verschiedenen Warteschlangen des Process Server können in der Konfigurationsdatei %RDCMS%\processserver.main.config konfiguriert werden. In dieser Datei wird eine Warteschlange durch das Process Manager-Element dargestellt und enthält die asynchronen Prozesse, die im Element Process genannt werden. Für bestimmte asynchrone Prozesse können Sie getrennte Warteschlangen für einzelne Projekte definieren, sodass beispielsweise dedizierte Publizierungs-Warteschlangen für spezielle Projekte definiert werden können. Um den Prozess einem besonderen Projekt zuzuweisen, müssen Sie den Attributwert Name des Elements Process um die GUID des Projekts erweitern. Lesen Sie hierzu auch das folgende Beispiel.

Für die folgenden Prozesse wurde der Namensraum um die GUID des Projekts erweitert:

• OpenText.WS.MS.Publishing für manuell oder automatisch gestartete Publizierungsaufgaben
• OpenText.WS.MS.Publishing.Queue für automatisch gestartete Publizierungsaufgaben nach Workflow-Reaktion
• OpenText.WS.MS.Publishing.Transfer für Übertragungen zu FTP-Publizierungszielen oder Delivery Server-Zielen
• OpenText.WS.MS.Cleaner.Ftp für Seitenlöschungen in allen Publizierungszielen
• OpenText.WS.MS.Cleaner für die Verwaltung der publizierten Seiten und Assets auf Publizierungszielen
• OpenText.WS.MS.Pages.Delete für fehlgeschlagene Seitenlöschungen beim ersten Versuch von RedDot.CMS.Cleaner.Ftp

Projektspezifische Warteschlangen für Publizierungsaufträge erstellen

Es wird eine projektspezifische Warteschlange für manuell oder automatisch gestartete Publizierungsaufträge für Projekt 1 und Projekt 2 mit dem Namen Important Asynchronous Queue erstellt. Die Projekt-GUIDs werden im Element Process an den Prozessattributwert Name angehängt.

<ProcessManager name="Important Asynchronous Queue" threads="3" priority="2" maxlogsize="1" >
  <Processes>
    <Process name="OpenText.WS.MS.Publishing.ProjectGuid1" />
    <Process name="OpenText.WS.MS.Publishing.Queue.ProjectGuid1" />
    <Process name="OpenText.WS.MS.Publishing.ProjectGuid2" />
    <Process name="OpenText.WS.MS.Publishing.Queue.ProjectGuid2" />
  </Processes>
</ProcessManager>

Die neu erstellte Warteschlange wird in der Warteschlangenliste des entsprechenden Anwendungsservers im Dialogfeld Asynchrone Prozesse verwalten angezeigt.
(Quelle: OpenText™ WSM Mangement Server - Server Manager Online-Hilfe)

Mit diesen Einstellungen ist man in der Lage, für die Projekte, die Arbeitsweisen und die entsprechende Infrastruktur die bestmögliche Leistung zu erzielen:

 

Systemleistung im Management Server 16 optimieren

Es gibt noch in den Unterlagen ein schönes Kapitel in dem kurz und bündig erläutert wird, wie man den Management Server optimieren kann. Hier ein paar Auszüge, welche zu diesem Thema gut passen:

Asynchrone Aufträge
Da Management Server 16 mehr RAM und mehrere CPU-Kerne verwendet, kann es gleichzeitig mehrere Aufträge bearbeiten. Wir empfehlen Ihnen dringend, die Einstellungen für die asynchrone Auftragswarteschlange und die anderen Warteschlangen anzupassen.

Gehen Sie wie folgt vor:

• Setzen Sie die asynchrone Aufgabenwarteschlange auf einen ähnlichen Wert wie die Anzahl der verfügbaren CPU-Kerne.
• Führen Sie entsprechend viele Aufträge aus, damit der Server alle Plätze in der Warteschlange belegt. Wenn der Server immer noch nicht stark ausgelastet ist, erhöhen Sie die Anzahl von asynchronen Aufträgen. Wenn die Last zu hoch ist, vermindern Sie die Anzahl. Erfahrungsgemäß sind zehn asynchrone Aufträge ein guter Wert für einen Server mit acht Prozessorkernen.

Publizierungsauftragsleistung
Management Server 16 kann viel besser als Management Server 10.1 mehrere Threads parallel ausführen. Dies führt zu einer wesentlich besseren CPU-Auslastung und -Skalierbarkeit, sodass ein Server mehr Aufträge parallel und vor allem mehr gleichzeitige Benutzersitzungen ausführen kann. Wir empfehlen Ihnen, die Größe der Warteschlange für bis zu zehn parallele Aufträge zu erhöhen, damit der Server eine maximale Auslastung von etwa 80 % erreicht.

Darüber hinaus nutzt Management Server 16 effektiv mehr RAM als Management Server 10.1. In R&D-Testprojekten wurde eine RAM-Auslastung von über 40 GB für sehr große Projekt bzw. für mehrere Projekte erfolgreich getestet. Diese höhere RAM-Nutzung führt zu kürzeren Reaktionszeiten und weniger Cache-Verwaltungs-Overhead.
(Quelle: OpenText™ WSM Mangement Server - Server Manager Online-Hilfe)

---

Hinweis: Die angepassten Konfigurationsdateien sollen immer an einem anderen Ort nochmals gesichert werden. Auch wenn bei einem Update die angepassten Dateien durch das Installationsprogramm gesichert werden. Schützt dies nicht bei einem kompletten Systemausfall z.B. Festplatten oder kompletten Hardwarecrash.;)

---

Fazit

Es gibt eine Menge an Möglichkeiten um aus dem Management (RedDot CMS) Server noch mehr Leistung rauszukitzeln. Obwohl die Leistung seit Release 11, durch die konsequente Umstellung auf die 64-Bit Technologie (seit Release 16 zu 100%), nicht mehr mit älternen Versionen vergleichbar ist. Gibt es immer noch Möglichkeiten den Management Server, welcher mit der Installation schon gut und für die breite Masse optimiert konfiguriert wird, weiter zu optimieren. Damit kann man die Systemleistung signifikant verbessern und vor allem auf die Bedürfnisse der Hardware, der Anwendungen und der eigenen Projekte anpassen.

Lohnt sich der Aufwand? Ja! Es lohnt sich auf jeden Fall das komplette System regelmäßig einem größeren Lasttest zu unterziehen. Um zu prüfen ob die aktuelle Konfiguration noch passt und wenn nicht diese wieder an die neuen Anforderungen anzupassen. Auch wenn man es nur mit viel Testaufwand möglich ist, hilft es auf jeden Fall den Anwendern bei der täglichen Arbeit.

Ebenso sollte man immer, bei einem Hardware-Austausch oder einer Erweiterung, diese Konfigurationen neu überdenken, prüfen und wieder anpassen. Denn nur ein gut eingestelltes System bringt die optimale Leistung und macht auch noch mehr Spaß bei der Arbeit. :)

---

Weitere ergänzende Informationen dazu findet man auch in der Online-Hilfe unter:

• Handbuch: Server-Manager / Kapitel: Anwendungsserver verwalten
• Handbuch: Server-Manager / Kapitel: Asynchrone Prozesse verwalten
• Handbuch: Server-Manager / Kapitel: Mit Warteschlangen im Process Manager arbeiten
• Handbuch: Server-Manager / Kapitel: Systemleistung im Management Server 16 optimieren

---

Über den Autor: