time2PERFORM
Performance und Application Tuning von instabilen und/oder inperformanten Anwendungen
Wird Ihre Anwendung mit der Zeit instabil, deutlich langsamer oder steht das System sogar komplett, werden oft ad-hoc und isoliert Maßnahmen durchgeführt:
Untersuchung durch:
| Datenbankhersteller | deren Interesse ist der Verkauf von zusätzlichen Datenbanklizenzen, ob der Kunde die nun benötigt, oder nicht. |
| Hardwarehersteller | deren Interesse ist der Verkauf von zusätzlicher Hardware, sei es nun I/O Subsysteme, Speicher, zusätzliche CPU Kernel etc.; ob der Kunde diese tatsächlich benötigt, steht auf einem anderen Blatt. |
| Softwarehersteller | deren Interesse... Sie wissen schon. |
Unsere Lösung für Sie:
Die Methodik
An dieser Stelle kommen die erfahrenen (und schon etwas älteren) time2BI Tuning-Experten mit der in über 600 erfolgreichen Einsätzen erprobten Performance-Methodik time2PERFORM zum Einsatz.
Unsere Methodik wendet das Prinzip der "limitierenden Ressource" an, verständlicher ausgedrückt: Wenn einer Pflanze Kalium zum weiteren Wachstum fehlt, dann werde ich mit zusätzlicher Gabe von UV-Licht keinen Erfolg haben - die limitierende Ressource wurde nicht identifiziert. Wenn Ihr System am I/O Subsystem Engpässe aufweist, dann nutzt mehr Speicher, Upgrade auf modernere Versionen der Applikation oder Datenbank etc. nur dem Hersteller dieser Produkte, oft jedoch nicht Ihrer Systemperformance.
time2BI ist auch in dieser Situation professioneller Partner an Ihrer Seite und analysiert unabhängig von Herstellerinteressen das Notwendige zur Verbesserung der Performance. In nur 4-7 Personentagen liefern wir 2-3 Interventionsvorschläge zur Optimierung der Anwendungsperformance und stellen Ihnen im Rahmen einer Präsentation den detaillierten Abschlussbericht vor. Die Umsetzung erledigen Sie dann in eigener Regie und/oder mit unserer Unterstützung. Alle Maßnahmen werden vor Ihrer Umsetzung gemeinsam auf Wirksamkeit und Nebenwirkungen überprüft.
Die Kennzahlen
Was ist eigentlich Performance? "Man bemerkt sie erst, wenn man sie nicht mehr hat"
Es gibt keine allgemein anerkannte Definition, jeder Anwender versteht etwas anderes darunter.
Unser erfahrenes Team hat auf Basis von über 600 erfolgreich durchgeführten Tuningeinsätzen Performance-Kennzahlen in die time2PERFORM Methodik überführt. Beispiele für typische Kennzahlen und Fragestellungen aus der Praxis, wie sie unseren Experten immer wieder begegnen, sind:
| Kennzahl | Beispiel |
| Antwortzeit | mittlere Antwortzeit unter 2 Sekunden Zeit für die Ausführung eines Berichtes im Frontend oder Aktualisierungslaufes im DWH. maximal 3 Sekunden für die Erstellung der Umsatzverteilung über alle Produkte und Regionen. |
| Durchsatz | mindestens 4000 Einlagerungen pro Stunde, 8 Mio. Buchungen pro Tag. Anzahl der Geschäftstransaktionen oder Business Objekte pro Zeiteinheit. Erstellung von 2000 Provisionslisten für alle Regionen in 4 Stunden. |
| Ressourcenverbrauch | höchstens 4000 I/Os pro Sekunde Verbrauch an Ressourcen für die Berichte oder Prozesse. Erstellung von 2000 Provisionslisten für alle Regionen in 4 Stunden. |
| Verfügbarkeit | 99% Verfügbarkeit, 24 * 7, 2 min Failoverzeit Zu welchem Prozentsatz steht das System für die produktive Nutzung zur Verfügung? Die Anwendung muss 95% Verfügbarkeit haben. Stillstandzeit kleiner 24 Stunden. |
| Stabilität | lineare Skalierung bei steigender Last und DB-Größe Stabilität des Gesamtsystems in Extremsituationen oder bei Veränderung der Randbedingungen Eine Verdoppelung des Datenvolumens muss das System ohne Einbußen verkraften. |
| Skalierung | Verhalten des Systems bei zunehmender Last, Anforderungen oder Benutzer. Bei linearer Aufrüstung mit Hardware muss der Durchsatz linear anwachsen. |
| Parallelität | 1000 Benutzer können parallel zugreifen. wie viele Benutzer können parallel unbeeinträchtigt Funktionen ausführen? Es müssen 3000 Benutzer parallel Berichte erstellen können. |
4 Phasen bis zum Stillstand
- Systemressourcen sind noch nicht ausgeschöpft, der Durchsatz steigt linear, d.h. kein Anwender merkt, dass weitere Anwender auf die Applikation zugeschaltet werden
- System (noch) stabil, Grenzwert. Mindestens eine Systemressource ist erschöpft. Der Durchsatz stagniert auf Kosten längerer Antwortzeiten. Ab diesem Zeitpunkt erhöht sich der Durchsatz bei mehr Usern nicht mehr
- System geht in instabile Zustände über. Das System kann die Ressourcenengpässe nicht mehr stabil ausbalancieren. Weder Durchsatz noch Antwortzeiten sind vorhersagbar, schwankend.
- System kollabiert. Antwortzeiten gehen gegen unendlich, Durchsatz gegen 0, extremes pagen & swappen.