1 / 35

M A P K I T

M A P K I T. myAMC.LNI und WLPSizer Werkzeugpräsentation Kay Wilhelm. Messwerkzeug myAMC.LNI und Prognosewerkzeug WLPSizer. Vorgehensmodell. Messkonzept. myAMC.LNI – R/3 Live Monitor. WLPSizer. Prognose-Beispiele. Aussagen zur Dienstgüte Antwortzeit Durchsatz Auslastung.

erica
Download Presentation

M A P K I T

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. M A P K I T myAMC.LNI und WLPSizer Werkzeugpräsentation Kay Wilhelm

  2. Messwerkzeug myAMC.LNI und Prognosewerkzeug WLPSizer Vorgehensmodell Messkonzept myAMC.LNI – R/3 Live Monitor WLPSizer Prognose-Beispiele

  3. Aussagen zur Dienstgüte • Antwortzeit • Durchsatz • Auslastung Vorgehensmodell für SAP R/3 • Lasttest und Monitoring • Benchmark • Referenzanwendung • Echtanwendung SAP-R/3 Statistik ATC- Profile WorkloadMaker • Modellkonfiguration • Client groups • Application Server • Database Server • Network Workload Profile Systemmodell Lastmodell Analyse und Prognose • Performanceprognosen • Lastprognose • Modellparametrisierung

  4. Messkonzept für SAP R/3 2 1 DB-Anfrage des Dialogschritts User-Interaktion = Dialogschritt 3 4 DB-Ergebnisse für Dialogschritt Ergebnis-Daten für Dialogschritt Datenbank-Server Netz Applikations-Server Netz R/3-User

  5. Klassifizierung der Dialogschritte R/3 Live Monitor GUI App DB Komplexität der Datenbankaktivität (DBSU) Service-Güte der Response-Time (ms) Dialog ... 5 1 1 good moderate bad Update ... 5 2 1 good moderate bad Batch 5 3 1 ... moderate good bad Other ... 5 1 1 good moderate bad

  6. Komplexitätsklassen beruhen auf DB-Service n u abhängig von der Applikation u unabhängig von HW-Plattform u unabhängig von OS und DB-Software repräsentieren die Komplexität des Dialogschritts n u sehr einfach bis 100 DB-Service-Units u einfach bis 1.000 DB-Service-Units u mittel bis 10.000 DB-Service-Units u komplex bis 100.000 DB-Service-Units u sehr komplex über 100.000 DB-Service-Units werden berechnet für die Tasktypen Dialog, Update, Batch, Other n

  7. Dienstgüteklassen Schranken pro Komplexitätsklasse n u sehr einfach 250 msec u 1000 msec einfach u mittel 1 msec pro DB-Service-Unit u komplex 1 msec pro DB-Service-Unit u sehr komplex 1 msec pro DB-Service-Unit komplexitätsabhängige Antwortzeit-Bewertung n u gut: Meßwert <= Schwellwert u mäßig: Meßwert <= 4 * Schwellwert u schlecht: Meßwert > 4 * Schwellwert

  8. myAMC.LNI (R/3 Live Monitor) R/3 Live Monitor Basismanagement • Anzeige der aufgetretenen Einträge in das R/3-Systemlog • Überwachung von vordefinierten Schwellwerten für DB, I/O, ... • Präsentation von Zeitreihen für Auslastungs- und Performancewerte R/3 Live Monitor Expert Management • Auslesen der R/3-Statistiksätze und Speicherung der Meßdaten • Dialogschritte werden beschrieben durch Antwortzeit, CPU-Verbrauch, DB-Zeit, Wartezeiten etc. • Gruppierung der Daten nach Tasktyp, Komplexität und Dienstgüte und Zusammenfassung aller Dialogschritte für z.B. eine Stunde • Meßdaten dienen als Basis zur Erstellung der Workloads

  9. On-Line Monitoring eines R/3-Systems

  10. myAMC.LNI-Ausgaben R/3-Stat R/3 Live Monitor Expert Service Quality-, Capacity and Accounting Management User Activity Service Quality ATC V2-Records Filter Gruppierung der Ressourcenver-bräuche (CPU, DB, R/3-Workload) nach Account, Mandant und Tasktyp Gruppierung nach Tasktyp der pro-zentualen Anteile der guten, mäßigenundschlechten Dialogschritte Dialogschrit-te gruppiert nach Tasktyp, Komplexitäts-klasse und Güteklasse Tabelle aller Dialogschrit-te mit allen gemessenen Verbräuchen Ergebnista-bellen von Rule-Sets für zum Beispiel: Selektion performance-relevanter Dialogschritte

  11. WLPSizer – Werkzeug zur analytischenModellierung von SAP R/3-Systemen • Ziel: Erstellung von Prognosen für • Konfigurations- und Architekturalternativen • Release-Wechsel, Neue R/3-Module • Lastverteilung, Lastanstieg Eingabedaten für die Modellierung und Analyse • die SAP R/3 Systemkonfiguration (v.a. aus Bibliotheksbausteinen) • SAP R/3 Last beschrieben durch gemessene Workloads

  12. Beschreibung von Konfigurationen Backbone LANs DB-Server Clients Application Server • Datenbank-Server (CPUs, Disks, ….) • Application-Server (CPUs) • Netze (LANs und Backbone) • Clientgruppen (# User, Netzanbindung) • Workloads (sog. normierte Lastprofile)

  13. Beschreibung von Konfigurationen im WLPSizer Netze und Server:Bausteine und Parameter aus Bibliotheken Lastspezifikation: generiert durch Monitoring und Lastprognose mit Hilfe des R/3-Live Monitors und WLPMaker

  14. Bibliotheken im WLPSizer - CPU-Bibliothek Prognosemodelle werden mit dem R/3 Performance Index SAPS und Skalierungsfaktoren parametrisiert • Die Bibliothek enthält SD-Benchmark-Ergebnisse (hier für R/3 Rel 4.6). • Die Modellparametrisierung geschieht nach Auswahl des CPU-Typs automatisch.

  15. Bibliotheken im WLPSizer - Disk-Bibliothek Prognosemodelle werden mit den Plattenspezifikationen parametrisiert • Die Bibliothek enthält frei erhältliche Plattenspezifikationen der Hersteller. • Default-Parameter können nachträglich verändert werden. • Die Modellparametrisierung geschieht nach Auswahl der Platte automatisch.

  16. Bibliotheken im WLPSizer - Netz-Bibliothek Prognosemodelle werden mit den Protokollspezifikationen parametrisiert • Die Modellparametrisierung geschieht nach Auswahl des Protokolls automatisch. • Default-Parameter können nachträglich verändert werden.

  17. Parametrisierung des DB-Server-Modells Wahl der Platten-Bibliothek und des Platten-Typs Wahl der CPU-Bibliothek und des CPU-Typs Plattenspezifikationen DB-Parameter Berechnung der Skalierungsfaktoren

  18. Workload-Parameter • Name der Workload (Bezeichnung der R/3-Instanz oder Applikation, die sie erzeugt) • Normiertes Workload-Profil (bzgl. eines Referenzrechners) • Anzahl an Dialogschritten dieser Applikation pro Stunde, die das Zielsystem zu verarbeiten hat. • Quelle: Eine Clientgruppe, die diese Last erzeugt • Ziel: Application-Server, der diese Last verarbeitet

  19. Normiertes Workload-Profil bzgl. eines Referenzrechners Dialog Update Batch Other Mittelwerte

  20. Erstellung von Workloads auf Basis der myAMC.LNI-Daten Typen von Workloadprofilen: • Single Workloadprofile: einzelne Workloadprofile • Sequence Workloadprofile: Profil-Sequenzen (Workloads beschreiben festes Zeitintervall und besitzen definierbaren Abstand zueinander) • TCQ-Profile: Gruppierung der Dialogschritte nach Tasktyp, Komplexität und Dienstgüte; erweiterte statistische Auswertungen Darstellung der Workloadprofile mit Hife der Visualize-Funktion (Excel)

  21. Workload-Erstellung mittels Daten-Aggregierung LNI-Datenbank der Messung Vermessene R/3-Instanz Vermessene CPU Zeitraum der LNI-Messung Zeitraum für Workload Nach Tasktypen D,U,B,O getrennt

  22. Eingabe von Workloads Durchsatz Einlesen eines Workloadprofils Darstellung des Workloadprofils Workload-Typ Erstellen eines Workloadprofils Server als Ziel der Workload Clientgroup als Quelle der Workload Workload-Typen: • Standard-Workload: Ausgehend von einer Clientgroup werden zugehörige Netze und Server belastet. • Background-Workload: Hintergrundlast kann auf Server oder IO-System gelegt werden. • Custom: Lastverteilung auf Ressourcen ist frei definierbar.

  23. Modell-Ergebnisse Ergebnisse der Modellrechnungen: • Durchsätze, Auslastungen, Antwortzeiten • ... Jeweils klassenbezogene Mittelwerte (D1,..,D5,...,O1,..,O5) Sichten auf die Ergebnisse: • Server-View: Ergebnisse aus Sicht eines Servers • Workload-View: Ergebnisse aus Sicht einer Workload • Utilization-View: Auslastungen der Komponenten verursacht durch eine Workload • IO-View: Auslastungen der Platten Export der Ergebnisse: • Ergebnisse zusammen mit der Modellbeschreibung können in eine Textdatei exportiert werden (Reports). • Die Ergebnisse können in Excel importiert werden. • Reports können zielgerichtet zusammengestellt werden.

  24. Modell-Ergebnisse: Server-View Auslastung des Servers Export der Ergebnisse Filter für die Ergebnis-Ansicht Workloads, die vom Server verarbeitet werden

  25. Modell-Ergebnisse: Reports Export der Ergebnisse nach Excel Export der Ergebnisse in eine Text-Datei Definition des Reports Vordefinierte Reports Mögliche Abschnitte für einen Report

  26. Modell-Ergebnisse: Export Inhaltsverzeichnis

  27. Beispiele für Modell-Prognosen Szenario 1: R/3-Release-Wechsel Szenario 1: R/3-Release-Wechsel Ein Release-Wechsel kann auf zwei Arten modelliert werden: • Anpassung der SAPS-Werte, Grundlage: Benchmark-Messungen Variante 1 SAPS-Tabelle für verschiedene R/3-Releases • Erhöhung der CPU-Mehrbedarfe für die Dialogschritte Variante 2 Korrekturfaktoren für CPU-Zeiten der App.- und DB-Server(Rel. 4.5B nach 4.6B)

  28. Beispiele für Modell-Prognosen Szenario 1: R/3-Release-Wechsel CPU-Skalierung vs. R/3-Release Sinkende SAPS-Leistungen bei Release-Wechsel

  29. Beispiele für Modell-Prognosen Szenario 1: R/3-Release-Wechsel R/3-Release-Wechsel (Variante 1) - Verringerung der SAPS-Leistungen Wahl der CPU-Lib des entsprechenden R/3-Release Die durch Benchmarks ermittelten SAPS-Werte werden aus der Bibliothek automatisch in das Modell übernommen

  30. Beispiele für Modell-Prognosen Szenario 1: R/3-Release-Wechsel R/3-Release-Wechsel (Variante 2) - Erhöhung der CPU-Mehrbedarfe für die Dialogschritte der R/3-Module Multiplikation der CPUTi mit entsprechendem Faktor.

  31. Beispiele für Modell-Prognosen Szenario 2: Hardware-Upgrade Szenario 2: Hardware-Upgrade • Vertikaler Upgrade: Modellkomponenten werden durch leistungsstärkere Bausteine ersetzt. • Horizontaler Upgrade: Das Modell wird durch weitere Komponenten ergänzt, z.B. durch Appl.-Server. Editieren oder Hinzufügen von Modellkomponenten

  32. Beispiele für Modell-Prognosen Szenario 2: Hardware-Upgrade Vertikaler Upgrade am Beispiel des DB-Servers Wahl eines leistungsstärkeren IO-Systems Erhöhung der CPU-Anzahl oder Wahl eines neuen CPU-Typs

  33. Beispiele für Modell-PrognosenSzenario 3: Zukünftige Laststeigerungen Szenario 3: Zukünftige Laststeigerungen • Lastprognose, z.B. 100% Durchsatzsteigerung (DS/h) • Erstellung des Lastmodells durch Modifikation von Workloadprofilen, z.B. Durchsatzverdoppelung • Modellexperimente zur Untersuchung von • einzuhaltenden Dienstgüten, z.B. RespTime < 2 Sekunden für D3 • notwendigen Upgradevarianten, z.B. mehr CPUs Durchsätze aller Workloads werden mit eingegebenem Faktor multipliziert

  34. Prognose-Ergebnisse für 2 Upgrade-Variantenjeweils für Dialogschritte der Komplexität D2, D3 Aktuell Upgrade_1 Upgrade_2

  35. Schluß

More Related