FREMDBEZUG VON IT-LEISTUNGEN
Trace auf entfernten Systemen
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.
Leider findet man in SAP-Projekten immer wieder die folgende Situation: In der Implementierungsphase werden Programme von unerfahrenen Entwicklern oder unter Zeitdruck geschrieben und mit einem völlig unrepräsentativen Datenbestand getestet. Später stellt sich dann heraus, dass diese Programme im produktiven System mit wachsendem Datenbestand kontinuierlich an Performance verlieren und schließlich zum Problem für das gesamte System werden. Zu diesem Zeitpunkt ist der ursprüngliche Entwickler oft schon nicht mehr verfügbar, und eine nachträgliche Performanceoptimierung ist nur noch mit hohem Aufwand möglich. Eine solche Situation sollten Sie durch kluges Projektmanagement unbedingt vermeiden!
Last
Die Applikationsschicht ist die zentrale Komponente des SAP R/3-Systems. Diese Schicht wird von SAP daher auch als eigentliches Basis-System bezeichnet. Innerhalb der Schicht befinden sich Applikationsserver und ein Message Server.
SAP-Basis Berater bzw. SAP-Consultants sind die Experten für die Beratung. Der Job eines SAP-Basis Beraters hat viele Aufgabenbereiche wie: Konzipierung von Applikationen, Installation, Betreuung SAP-Module, Prozessanalyse und -optimierung, Erstellung von Reports, Datenmodellierung und -extraktion.
Mit "Shortcut for SAP Systems" werden Aufgaben im Bereich der SAP Basis vereinfacht und fehlende Funktionen des Standards ergänzt.
Beim traditionellen Sizing geht man von der Anzahl der Benutzer oder Transaktionen aus, multipliziert diese mit einem Gewichtungsfaktor und errechnet daraus (über den CPU-Bedarf) den Hauptspeicherbedarf.
Weichen die Werte stark voneinander ab, müssen Sie analysieren, ob es Prozesse gibt, die nicht direkt zum SAP-System gehören.