Konzeptionelle Unterstützung bei der Architektur von Systemlandschaften
Installation von SAP-Landschaften, Transportmanagementsystemen usw
Wenn zwei Benutzer in einem Zeitraum jeweils 100 Transaktionsschritte Last ausgeführt haben, sind beide gleich aktiv gewesen. Das bedeutet aber noch nicht, dass sie beide die gleiche Last auf dem System erzeugt haben. Wenn z. B. der erste Benutzer Finanzbelege eingegeben hat und 100 Transaktionsschritte mit einer mittleren Antwortzeit von 500ms ausgeführt hat, hat er das System 50 Sekunden lang belastet. Ein zweiter Benutzer hat z. B. Controlling-Berichte erstellt und für seine Arbeit 100 Transaktionsschritte mit einer mittleren Antwortzeit von 5 Sekunden benötigt, also das System 500 Sekunden lang in Anspruch genommen. Offensichtlich hat der zweite Benutzer bei gleicher Aktivität eine zehnfach größere Last erzeugt. Wie man an diesem Beispiel erkennt, ist also das Produkt aus der Anzahl der Transaktionsschritte und der mittleren Antwortzeit ein Maß für die erzeugte Last. (Will man exakt sein, muss man von der Antwortzeit die Dispatcher-Wartezeit und die Roll-Wartezeit abziehen, denn während der Auftrag in der Dispatcher-Queue bzw. auf die Ausführung eines RFCs wartet, verursacht er keine Last auf dem System.) Die Belastung, die die unterschiedlichen Task-Typen auf der Datenbank erzeugen, lässt sich analog anhand der gesamten Datenbankzeit (Transaktionsschritte mal mittlere Datenbankzeit) vergleichen. Ebenso erfolgt der Vergleich der CPU-Belastung auf dem Applikationsserver. Die Verteilung der Zeiten (Datenbankzeit, CPU-Zeit etc.) spiegelt also die Lastverteilung auf dem System besser wider als die bloße Anzahl der Transaktionsschritte.
Der Hauptspeicherbedarf und der Festplattenbedarf werden in MB angegeben und der Bedarf an I/O-Kapazität in Zugriffen pro Sekunde, also in allgemein üblichen Einheiten. Für die CPU-Kapazität gibt der Quick Sizer das Ergebnis in der Einheit SAPS an, um die unterschiedlichen CPU-Architekturen miteinander vergleichen zu können. Hardwarepartner können Ihnen Auskunft darüber geben, wie viel SAPS ein Rechner leistet.
EMPFEHLUNGEN
Sind für die Bearbeitung einer Benutzeranfrage Daten notwendig, die sich Datenbanktuning noch nicht im Hauptspeicher des Applikationsservers befinden, werden diese vom Datenbankserver gelesen. Beim Tuning der Datenbank unterscheidet man drei Bereiche. Zunächst einmal ist dies die richtige Einstellung der Datenbankpuffer und anderer Datenbankparameter. Der zweite Bereich ist die Optimierung des Festplattenlayouts der Datenbank, um die Last möglichst gleichmäßig auf die Festplatten zu verteilen und so Wartesituationen beim Schreiben auf die Festplatte bzw. beim Lesen von der Festplatte zu vermeiden. Der dritte Aspekt beim Datenbanktuning ist die Optimierung langlaufender, »teurer« SQL-Anweisungen.
Die Prüfungen decken Standardfehler und -probleme auf. Sie können natürlich keine Aussage darüber machen, wie gravierend die tatsächlichen Auswirkungen auf die Performance sein werden. Dazu sind die oben beschriebenen Laufzeitprüfungen notwendig. Die Verifikation dieser Prüfungen sollte dennoch Bestandteil der Qualitätskontrolle von ABAP-Programmen sein.
Tools wie "Shortcut for SAP Systems" ergänzen fehlende Funktionen im Bereich der SAP Basis.
Die Performance der Dialoganwendungen und der Hintergrundanwendungen sind in der Regel unabhängig voneinander zu bewerten.
Daher können auch kritische Berechtigungen, Profile und Rollen bestehen, die nicht in das von SAP definierte Namensschema passen.