SAC Performance-Tuning
Stand 2026-09-03
SAC-Performanceprobleme sind selten SAC-Probleme — sie stecken im Modelldesign, in der Abfrageausführung an der Quelle oder im Story-Design. Diagnose über den eingebauten Performance Monitor (Anfragezeit vs. Renderzeit) und den Network-Tab des Browsers. Live vs. Import ist der fundamentale Trade-off: Live kennt keine Zeilenbegrenzung, ist aber durch die Abfragegeschwindigkeit der Quelle gedeckelt; Import ist schnell, aber auf 2 Mio./10 Mio. Zeilen und Refresh-Latenz gedeckelt. Die wirkungsvollsten Korrekturen: berechnete/eingeschränkte Kennzahlen ins Datasphere-Analytic-Model vorschieben, die Kosten der Exception-Aggregation abmildern, die Dimensionskardinalität deckeln, Widgets pro Seite begrenzen (8-10 bei Live), verknüpfte Analyse durch seitenweite Filter ersetzen und den Filter-Pushdown über HANA-Ausführungspläne verifizieren. Arbeitsweise: messen, ändern, messen — nie nach Anekdote tunen.
Was Sie lernen
- Die Performance von SAC-Stories mithilfe des Vier-Schichten-Stacks (Story-Design, Modelldesign, Quellabfrageausführung, Netzwerk/Browser) und des integrierten Performance Monitor diagnostizieren, um Request Time von Rendering Time zu trennen.
- Zwischen Live- und Import-Modell-Architektur entscheiden, basierend auf Datenvolumen, Aktualitätsanforderungen und Abfragekapazität des Quellsystems, und die jeweiligen Performance-Trade-offs erläutern.
- Tuning auf Modellebene anwenden: berechnete und eingeschränkte Kennzahlen zum Datasphere Analytic Model / zur HANA-Ebene vorschieben und die Kosten von Exception Aggregation und hochkardinalen Dimensionen abmildern.
- Das Story-Design optimieren (Widget-Anzahl pro Seite, verknüpfte Analyse vs. seitenweite Filter, Tabellenpaginierung) und den Filter-Pushdown zur Quelle mithilfe von HANA-Ausführungsplänen und Pflichtfiltern verifizieren.
SAP-Analytics-Cloud-Performance diagnostizieren und tunen
Die Performance von SAP-Analytics-Cloud-Stories und -Dashboards ist selten ein SAC-Problem — sie ist fast immer ein Modell- oder Quellproblem, das an der Client-Oberfläche zutage tritt. Erfahrene SAC-Architekten schauen bei einem langsamen Dashboard nicht zuerst auf die SAC-Einstellungen; sie arbeiten den Performance-Stack systematisch von oben nach unten durch, denn die Korrektur liegt fast immer entweder (a) im Modelldesign, (b) in der Quellabfrage oder (c) darin, wie das Story-Design die Daten vom Modell anfordert. Diesen Stack zu verstehen ist die Grundlage jedes wirksamen Tuning-Einsatzes.
Voraussetzungen
- Fortgeschrittene praktische Erfahrung auf SAP-Analytics-Projekten
- Zunächst die Kernkonzepte durcharbeiten: C008, C019, C020
Lernergebnisse
- Die Performance von SAC-Stories mithilfe des Vier-Schichten-Stacks und des integrierten Performance Monitor diagnostizieren, um Request Time von Rendering Time zu trennen.
- Zwischen Live- und Import-Modell-Architektur entscheiden, basierend auf Datenvolumen, Aktualitätsanforderungen und Abfragekapazität des Quellsystems.
- Die Kernentscheidung des Moduls anwenden: Live-Modell vs. Import-Modell — Import wählen, wenn die Volumina nach Voraggregation an der Quelle innerhalb der Zeilenbegrenzung liegen und Nahezu-Echtzeit nicht erforderlich ist — Sie erhalten eine vorhersagbare.
- Die Beherrschung mit dem KPI verfolgen: Widget request time (Ziel: ≥ 20 % Reduktion nach jeder Korrektur auf Quellebene; Warnsignal: weniger als 20 % Verbesserung — die Korrektur hat wahrscheinlich die falsche Schicht des Stacks adressiert).
Vollständiges Modul für Mitglieder. Das vollständige Modul ergänzt: den Entscheidungsrahmen · das durchgehende Szenario · die KPI-Scorecard · die Anti-Muster · die Codeblöcke · die Wissenskontrolle · die Schemata.