Performance-Messung in der Enterprise SOA

Feature | 16. Januar 2008 von Susanne Janssen 0

Zur Umsetzung des Konzepts der Enterprise serviceorientierten Architektur veröffentlicht SAP fast wöchentlich im SAP Developer Network neue Enterprise Services (ES). Doch es gilt zu unterscheiden.

Produkte wie SAP Business ByDesign beispielsweise setzen komplett auf der Enterprise SOA auf. Enterprise Services von Drittanbietern oder auch SAP selbst, die auf SAP NetWeaver basieren, können etwa in Java programmiert sein. Die in Enterprise Services verkapselte Funktionalität von SAP ERP basiert auf ABAP. Da diesen Enterprise Sevices unterschiedliche Technologien zu Grunde liegen, dienen auch verschiedene Werkzeuge zur Performance-Messung in der entsprechenden Enterprise SOA.

Eines ist den standardisierten Web-Services gemeinsam: Sie enthalten betriebswirtschaftliche Anwendungssoftware und lassen sich, da auf standardisierten Protokollen beruhend, fast beliebig zu völlig neuen Anwendungen zusammensetzen. Das umfasst einerseits Business-to-Business-Applikationen, aber noch weitaus häufiger applikationsübergreifende Endanwender-Szenarios, bei SAP xApps genannt.

Performance wird entweder in Antwortzeit oder in Durchsatz pro Zeiteinheit beziffert. Aus Sicht der Performance ist interessant, dass Endanwender-Szenarios sowohl innerhalb einer Lösung wie SAP ERP liegen, sich jedoch auch übergreifend verschiedener Lösungen bedienen können, etwa in einem Zusammenspiel von SAP ERP und SAP Supply Chain Management oder mit Software eines Dritt-Anbieters.

In manchen Fällen kommunizieren die Services sogar über die Grenzen von Rechenzentren hinweg, etwa wenn ein Unternehmen über ein zentrales System zur Auftragsbearbeitung verfügt, diese Aufträge jedoch dezentral erfasst werden.

Am komplexesten im Hinblick auf die Performance ist aber, wenn via Enterprise Services verschiedene Unternehmen an verschiedenen Standorten zusammenwirken. Das ist beispielsweise der Fall, wenn ein Bankautomat eines Instituts in irgendeiner Filiale weltweit die Gültigkeit einer eingeschobenen Karte prüft, die von einem anderen Bankhaus ausgegeben wurde.

Wissen, wer beteiligt ist

Software-Komponenten zur Verarbeitung von Enterprise Services


Im Falle von Enterprise Services aus dem SAP-eigenen ABAP-Stack geht ein Service Call in Form eines HTTP-Requests im SOAP-Format an den SAP NetWeaver Application Server. Der Request wird von der so genannten HTTP Communication Layer lediglich weitergeleitet. Die Communication Layer besteht im Wesentlichen aus zwei Teilen, dem Internet Communication Manager (ICM) und dem Internet Communication Framework (ICF). Ihre Aufgabe besteht darin, den Request dem richtigen Service Provider zuzuordnen.

Eine komplexere Aufgabe fällt der darauf folgenden Web-Service-Enabling-Schicht zu. Auch sie setzt sich aus verschiedenen Bestandteilen zusammen, etwa der Web-Service-Laufzeit, die den SOAP-Header liest und XML-Web-Service-Daten extrahiert. Diese Daten werden dann vom Proxy Framework auf bestehende ABAP-Daten-Strukturen abgebildet.

Außerdem ruft die Web-Service-Enabling-Schicht den Web Service Proxy auf, der sich wiederum an die eigentliche SAP-Applikation wendet. Die SAP-Applikation besteht aus den bekannten BAPIs und Funktionsbausteinen, die über Remote Function Calls (RFC), einem SAP-eigenen Protokoll, bei Fernabfragen effizient aufzurufen sind. Innerhalb dieser Elemente entscheidet sich, wie es um die Performance der Enterprise SOA bestellt ist.

Antwortzeit analysieren

Würde in Umfragen erhoben, welche Kennzahl die Anwender im Hinblick auf die Performance als die wichtigste ansehen, würden vermutlich 99 Prozent spontan die “Antwortzeit” nennen. Bei Anwendungen oder Enterprise Services auf Basis einer Enterprise SOA ist diese Antwort wegen der Endanwender-Szenarios auch sinnvoll.

Leider ist die Antwortzeit eine schwer zu fassende Größe. Sie ist nicht linear von Durchsatz oder Systemauslastung abhängig. Darüber hinaus setzt sie sich aus einer Summe einzelner Verweildauern in den diversen Kommunikations-Schichten zusammen.

Zunächst ist der Browser von Bedeutung, in den viele Softwareanbieter der Benutzerfreundlichkeit wegen immer mehr Funktionalität verlagern. Die Browser-Rendering-Zeit hängt somit stark von der Performance des Frontend-PC ab. Auf dem Frontend laufen beispielsweise personalisierte Seiten oder Visualisierung – die Thin Clients von früher wandeln sich zu Rich Clients.

Roundtrips und Bandbreite

Die Antwortzeit wird auch im Netzwerk auf dem Weg zum Applikationsserver bestimmt. Je mehr Kommunikationsschritte und Roundtrips es im Wide Area Network zwischen Browser und Server gibt, und je mehr Daten übertragen werden, desto mehr Bandbreite muss bereitstehen. Im Zweifelsfall dauert es somit also länger, bis eine neue Seite aufgerufen ist. Außerdem sind die Netzwerke nicht gleich bleibend stabil. Eine asynchrone Datenübertragung, bei der nur Teile der neuen Seite aufgebaut werden, bietet hier bedingt Hilfe.

Schließlich beeinflusst auch der Applikationsserver mit seiner Anwendungslogik die Gesamt-Antwortzeit. Services sind oft verschachtelt und müssen andere Services oder Anwendungen aufrufen. Dies ist etwa dann der Fall, wenn ein Kundenauftrag in der ERP-Lösung synchron über einen RFC den Available-to-Promise-Check in der Supply-Chain-Management-Lösung aufruft und auf Antwort wartet, ob die gewünschte Ware zur Verfügung steht.

Neben der reinen Verarbeitungszeit spielen hier erneut Netzwerk- und Kommunikationszeiten eine Rolle. Der letzte Schritt vom Netzwerk in die Datenbank und die Prozesse innerhalb der Datenbank sind im Allgemeinen für die Performance weniger problematisch.

Wer Services aus dem Internet aufruft, sollte wegen der Performance darauf achten:

  • wie viele Daten zum Frontend geschickt werden,
  • wie viele Roundtrips es pro Benutzerinteraktion zwischen Browser und Applikationsserver gibt,
  • ob versteckte Kommunikation zwischen Applikationsservern stattfindet und
  • wie viele synchrone Nachrichten mit welchem Umfang verschickt werden.

SAP-Software verwendet in der Regel zwei Kommunikationsprotokolle, den Web-Standard HTTP (SOAP) und die proprietären RFCs, die für synchrone und asynchrone Kommunikation in unterschiedlichen Ausprägungen vorliegen.

Die Übertragungs- und Verarbeitungszeit einer Nachricht hat unabhängig von ihrer Größe einen festen Bestandteil. Dieser hängt von den Metadaten einer Nachricht, deren Verarbeitungszeit in der CPU, der rein physischen Distanz, die beispielsweise via Satellit übertragen wird, den zu durchlaufenden Hardware-Komponenten wie Routern, der Bandbreite und der Qualität des Netzwerks ab.

Der variable Anteil der Übertragungszeit einer Nachricht ergibt sich im Wesentlichen aus ihrer Größe. Dieser Teil umfasst die reine Laufzeit im Netzwerk, mit Kopieren, Verschlüsselung, Verdichtung. Je nach Komplexität kommen Serialisierung und Deserialisierung hinzu.

Je geringer also die reine Laufzeit der Nachricht ist, desto größer ist der prozentuale Anteil der festen “Verwaltungszeit” an der gesamten Laufzeit. Für “Consumer” einer Enterprise SOA folgt daher: Die Enterprise Services bieten zwar auf der einen Seite eine schier unendliche Fülle an Gestaltungsmöglichkeiten – doch je mehr über das Internet kommuniziert wird, desto größer sind die Antwortzeiten und letztendlich auch die Kommunikationskosten. Man sollte sich daher also gut überlegen, inwieweit man sich auf Internet-Kommunikation verlassen kann.

Die neuen Werkzeuge sind die alten

Wer die wichtigsten Performance-Kennzahlen für eine Enterprise SOA selbst ermitteln möchte, kann eine Reihe von Messungen vornehmen. Dabei sind vor allem Browser-Kennzahlen, Einzelsatzstatistik und Laufzeitanalyse von Bedeutung.

Im Hinblick auf den Browser und das Netzwerk zum Applikationsserver sind für die Performance-Messung keine komplizierten Werkzeuge erforderlich. Um die Kennzahlen Rendering-Zeit sowie Anzahl und Größe der Roundtrips zu ermitteln, lässt sich im Prinzip jedes kommerzielle HTTP-Monitoring-Tool verwenden. Unabhängig davon, welches Werkzeug genutzt wird, sollten Performance-Messungen im Browser allerdings gut vorbereitet werden.

Der Browser Cache muss geleert und die Daten in HTTP 1.1 komprimiert werden. Außerdem ist sicherzustellen, dass der Cache immer nach dem Verlassen der Anwendung geleert wird – je nach Browser ist das über Einstellungen in den Internet-Optionen möglich. Das zu testende Szenario sollte mindestens dreimal durchgespielt werden ohne zu messen, damit die Caches wieder gefüllt und die Messergebnisse somit reproduzierbar sind.

Danach kann das Messwerkzeug eingeschaltet werden, das die Laufzeiten der Roundtrips, die Anzahl der synchronen Roundtrips und den Umfang der übertragenen Daten festhält. Als Faustregel gilt: In der Regel haben Enterprise Services einen Roundtrip. Die übertragene Datenmenge hängt von der Komplexität des User Interface ab, in der Regel sollte sie zwischen 5 und 15 KB liegen.

Einzelstatistik und Laufzeitanalyse

Auf der Ebene des Applikationsservers sind der Hauptspeicherverbrauch pro Anwender, die CPU-Zeit der Enterprise Services und gegebenenfalls die Kommunikationskosten zwischen Servern die wichtigsten Kennzahlen. Um sie zu messen sind vor allem zwei bekannte Werkzeuge nützlich: die Einzelsatzstatistik (STAD) und die Laufzeitanalyse (SE30 oder ihr Nachfolger SAT).

Wird die Einzelsatzstatistik STAD verwendet, sollte zunächst das zu testende Szenario mehrfach durchgespielt werden – mindestens dreimal, besser jedoch sechsmal, ohne zu messen. Dann sind die Puffer gefüllt und es lassen sich reproduzierbare Messergebnisse erzielen.

Wenn die STAD aufgerufen wurde, müssen die Felder Response Time, Time in Workprocess, Wait Time, CPU Time, DB Request Time und Maximum Extended Memory in Step ausgewählt werden. Die zu untersuchenden Enterprise Services sind in der Spalte T (für Task Type) mit einem H (bei HTTP) oder T (bei HTTPS) gekennzeichnet.

Eine typische Anwendung ist das “Customer Fact Sheet”, in dem acht verschiedene Enterprise Services auf einer Seite angezeigt werden. Aus der STAD-Aufstellung ist unmittelbar ersichtlich, wie viel CPU-Zeit die in Anspruch genommenen Services gekostet haben und wie viel davon auf den Applikationsserver und auf den Datenbank-Server entfiel. So lässt sich ermitteln, wie viel Zeit ein ES im Schnitt auf Applikations- und auf Datenbankseite verbraucht hat.

Verbrauch wird angezeigt

Die Laufzeitanalyse SE30 zeigt, wie sich die Einzel-CPU-Zeiten zusammensetzen. Damit die Analyse HTTP-Messergebnisse liefern kann, sind bestimmte Voreinstellungen zu setzen. Als Anzahl der Messungen wird die Anzahl der Enterprise Services angegeben – ist diese nicht genau bekannt, sollte eine große Zahl eingefüllt werden. Die “Expiration Time” muss in der Zukunft liegen.

Wird die Call Hierarchie der SE30 aufgerufen, zeigt die Analyse, wie viel Zeit in den einzelnen Software-Komponenten verbraucht wurde – etwa für die Verkapselung in XML und SOAP-Strukturen.

Eine Reihe von Messungen zu einfachen und komplexeren Services könnte beispielsweise ergeben, dass die Zeiten für HTTP zu vernachlässigen waren und für SOAP bei 10 bis 15 msec lagen, während sie im Proxy Framework 5 bis 20 msec und auf der Applikationsebene 60-90 msec betrugen. In diesem Beispiel läge das Verhältnis Anwendungslaufzeit zu “Web Service Verpackung” bei 25 bis 40 Prozent.

Für die Bewertung dieser Messergebnisse gilt: Je kürzer die eigentliche Laufzeit, desto höher der prozentuale Anteil an Web Service Enablement.

Einfache Tipps für gute Performance

Durch ihre große technische Flexibilität bieten Enterprise-SOA-Applikationen einen großen Freiraum für das Design kontext- und industriespezifischer Anwendungen. Gerade deshalb sollte man Performance-Aspekte nicht aus den Augen verlieren. Dabei ist es nicht unbedingt nötig, selbst zu programmieren, um gute Ergebnisse zu erzielen.

Bereits in der Evaluierungsphase sollten mögliche Auswirkungen der Kommunikationskosten einer Enterprise-SOA-Anwendung berücksichtigt werden. Das gilt insbesondere für Anwendungen im Wide Area Network. Die Vorgehensweise ist dabei recht einfach: Zunächst gilt es, die Antwortzeitanforderungen aus der neuen Anwendung heraus zu bestimmen. Wenn diese beispielsweise bei zwei Sekunden liegen, ist dieser Wert der Ausgangspunkt für die nachfolgenden Überlegungen.

Pro Benutzerinteraktionsschritt sollte es nicht mehr als zwei Roundtrips geben. Die Latenzzeiten im WAN liegen pro Roundtrip zwischen 0,3 und 0,5 Sekunden. Das heißt, dass für die reine Verarbeitungszeit auf allen Komponenten 1 bis 1,4 Sekunden zur Verfügung stünden. Diese verteilen sich prozentual über die verschiedenen Softwareschichten: 30 Prozent für die Browser-Renderingzeit, 10 Prozent für den Web Server, 50 Prozent für die Applikation und 10 Prozent für die Datenbank.

Somit lässt sich eine einfache Performance Baseline für die neuen Services ermitteln, die in der Testphase durch Messungen bestätigt werden können. Schließlich sollte während der Implementierung darauf geachtet werden, die übertragene Datenmenge einzuschränken.

Leave a Reply