System Guides
Vergrößerung der Last unter Beibehaltung des Applikationsprofils
Als Skalierbarkeit eines Programms bezeichnet man die Abhängigkeit der Laufzeit eines Programms von der Datenmenge. Viele Operationen sind linear von der Datenmenge abhängig (t = O(n)), d. h., die Laufzeit steigt linear mit der Datenmenge an. Beispiele dafür sind Datenbankselektionen in großen Tabellen ohne oder mit ungeeigneter Indexunterstützung und Schleifen über interne Tabellen im Programm. Lineare Skalierbarkeit ist für die Bearbeitung mittlerer Datenmengen akzeptabel. Wenn sie bei Programmen, die große Datenmengen bearbeiten sollen, nicht vermieden werden kann, muss über Parallelisierung nachgedacht werden. Besser als eine lineare Skalierbarkeit sind für die Performance natürlich konstante Laufzeiten (t = O(1)) oder eine logarithmische Abhängigkeit (t = O(log n)). Logarithmische Abhängigkeiten treten z. B. bei Datenbankselektionen in großen Tabellen mit optimaler Indexunterstützung oder bei Leseoperationen in internen Tabellen mit binärer Suche auf. Da die Logarithmusfunktion nur sehr langsam ansteigt, ist in der Praxis zwischen konstanten und logarithmisch ansteigenden Laufzeiten nicht zu unterscheiden. Inakzeptabel für die Bearbeitung mittlerer und großer Datenmengen sind quadratische Abhängigkeiten (t = O(n × n)) und alles, was darüber hinausgeht. Allerdings können Probleme mit quadratischer Abhängigkeit durch intelligente Programmierung in der Regel auf Abhängigkeiten der Art t = O(n × log n) zurückgeführt werden. Ein Beispiel ist das Vergleichen zweier Tabellen, die beide mit der Ordnung n wachsen. Ein Vergleich der unsortierten Tabellen würde zu einer quadratischen Abhängigkeit führen, ein Vergleich mit sortierten Tabellen zur Abhängigkeit t = O(n × log n). Da die Logarithmusfunktion nur sehr langsam ansteigt, ist in der Praxis zwischen einem Ansteigen t = O(n × log n) und einem linearen Ansteigen nicht zu unterscheiden.
Hardwarepartner können Benchmark-Läufe von SAP zertifizieren lassen. Dazu senden sie von SAP genau definierte Daten über den Ablauf des Benchmarks an SAP. Zertifizierte Benchmarks werden von SAP im Internet veröffentlicht. Dabei unterscheidet man zwischen Benchmark-Läufen, die auf einem Rechner durchgeführt werden (2-Tier), und solchen, die auf einer verteilten Rechnerlandschaft durchgeführt werden (3-Tier). 3-Tier- Benchmarks demonstrieren in zum Teil eindrucksvoller Weise die Skalierbarkeit von Hardware, Datenbank, SAP-Basis und getesteten SAP-Anwendungen. Jedes Jahr werden insbesondere für den 2-Tier-SD-Benchmark einige Dutzend Benchmark-Läufe zertifiziert, die in erster Linie dazu dienen, die Leistungsfähigkeit des eingesetzten Rechners darzustellen. Zu allen anderen Benchmarks finden sich Zertifizierungen im Wesentlichen für den Zeitpunkt der Markteinführung des entsprechenden Szenarios. Darüber hinaus werden viele interne Benchmark-Läufe von SAP und deren Hardwarepartnern durchgeführt, um Daten für den Sizing-Prozess zu gewinnen. Benchmark-Läufe können dazu genutzt werden, die Leistungsfähigkeit von Rechnern zu bestimmen.
Hilfe zur Fehlerbehebung
Beim Ausführen des ABAP-Trace stehen Ihnen Varianten zur Verfügung, mit denen Sie die Aufzeichnung des Trace einstellen können. Wir empfehlen Ihnen dringend, Varianten zu verwenden: Bei der Untersuchung eines etwas komplexeren Programms erreicht die Datenmenge beim Erstellen des Trace schnell Größen von mehreren Megabyte, die aber oft für die Analyse völlig belanglos sind. Daher gibt man in einer Variante vor, was man wirklich analysieren möchte. Die derzeit aktive Variante finden Sie im Eingangsbildschirm der Laufzeitanalyse im Bildschirmabschnitt Messung. Die Variante DEFAULT ist bereits im System angelegt. Sie können Ihre individuellen Einstellungen als eigene Variante speichern. Über die Schaltflächen Variante anzeigen oder Variante ändern gelangen Einstellungen Sie auf den Bildschirm, in dem Sie die Einstellungen für eine Variante vornehmen.
Die genannten Puffer bilden eine Pufferhierarchie, d. h., es werden zunächst die Puffer abgefragt, die nahe an der Anwendung liegen, bevor die Zugriffe auf den Datenpuffer der Datenbankinstanz, den Betriebssystempuffer und den Puffer des Speichersubsystems durchschlagen. Grundsätzlich gilt: Je weiter unten in der Hierarchie ein Puffer liegt, desto generischer ist sein Einsatzbereich; je höher in der Hierarchie ein Puffer liegt, desto höher muss sein Performancegewinn für die Anwendung sein. Ist das nicht der Fall, kann auf diesen Puffer verzichtet werden.
Einige fehlende SAP Basis Funktionen im Standard werden durch die PC-Anwendung "Shortcut for SAP Systems" nachgeliefert.
Wenn Sie mit der Menüoption System Erzeugen Modus einen neuen Modus öffnen, wird damit ebenfalls ein Speicherkontext angelegt.
Anschließend sind die Sicherheitskontrollen in Standard-APAB-Code-Checking-Tools wie ABAP Test Cockpit (ATC) oder Code Inspector (SCI) verfügbar.