Performance-Audit für Anwendung und Datenbank

Eine langsame Anwendung hat nicht immer nur eine einfache Ursache

Dasselbe Symptom kann mehrere Quellen haben. Eine Ansicht kann auf die Datenbank, eine externe API oder eine Queue warten. Ebenso können zu viele Operationen, ein fehlender oder falsch eingesetzter Cache, die Datenverarbeitung, die Umgebungskonfiguration oder die Arbeit im Browser die Ursache sein.

Deshalb beginnen wir ein Audit weder mit zufälligen Indizes noch mit einem Serverwechsel. Zuerst bestimmen wir, welcher Ablauf für das Unternehmen wichtig ist, unter welchen Bedingungen das Problem auftritt und wie es reproduzierbar gemessen werden kann. Erst danach untersuchen wir die relevanten Teile des Systems.

Wann ein solches Audit sinnvoll ist

Ein wichtiger Vorgang dauert immer länger

Das kann das Öffnen eines Berichts, das Speichern einer Bestellung, eine Suche, ein Datenimport, die Dokumenterstellung oder eine Tätigkeit sein, die ein Mitarbeiter täglich mehrfach ausführt.

Das System wird mit dem Wachstum des Unternehmens langsamer

Mehr Daten, Nutzer oder Integrationen haben eine Grenze sichtbar gemacht, die vorher nicht auffiel. Sie möchten wissen, ob die Ursache in Abfragen, Code, Architektur oder Umgebung liegt.

Timeouts und ungleichmäßige Antwortzeiten treten auf

Derselbe Vorgang läuft einmal schnell und blockiert ein anderes Mal den Prozess. Das betrifft besonders Queues, geplante Aufgaben, Integrationen, Importe und gleichzeitig ausgeführte Operationen.

Es gibt mehrere Vermutungen, aber keine Belege

Eine Person empfiehlt einen stärkeren Server, eine andere einen Umbau der Datenbank und eine dritte einen Framework-Wechsel. Das Audit trennt Ursache und Symptom und bringt die Arbeiten in eine sinnvolle Reihenfolge.

Zuerst definieren wir, was in diesem System "langsam" bedeutet

Es gibt keinen einzelnen Wert, der die Leistung einer gesamten Anwendung beschreibt. Das Laden einer öffentlichen Seite, das Speichern eines großen Formulars, die Berechnung eines Berichts, die Arbeit einer Queue und der Import Tausender Datensätze müssen unterschiedlich gemessen werden.

Vor den Messungen vereinbaren wir:

• die konkrete Ansicht, Aktion oder den Prozess;
• Umgebung und Bedingungen, unter denen das Problem auftritt;
• Datenmenge, Zahl der Operationen oder Last, die für die Reproduktion nötig ist;
• vorhandene Messwerte, technische Logs und Zugriffsbeschränkungen;
• die Methode, mit der die Wirkung einer späteren Korrektur geprüft werden soll.

So vergleichen wir gleiche Bedingungen und ziehen keine Schlüsse aus einem einzelnen Zufallstest.

Beispiel: Ein langsamer Bericht bedeutet nicht automatisch, dass ein Index fehlt

Angenommen, ein Verkaufsbericht benötigt mehrere Sekunden zum Öffnen. Die Ursache kann eine kostspielige Abfrage sein, aber auch Hunderte kleine Abfragen in einer Schleife, das Warten auf einen externen Dienst, die Verarbeitung zu vieler Daten in der Anwendung oder eine Antwort, die der Nutzer nicht vollständig benötigt.

Ein Index ohne Prüfung des Ausführungsplans kann wirkungslos bleiben. Mehr Serverressourcen können das Problem lediglich verschieben. Deshalb reproduzieren wir zuerst die Situation, erfassen Messwerte und prüfen, wo die Zeit tatsächlich verbraucht wird.

Dies ist ein hypothetisches Beispiel für die Analysemethode, keine Beschreibung eines konkreten Projekts und kein Versprechen, dass jede Anwendung dasselbe Problem hat.

Was wir prüfen können

Den genauen Umfang vereinbaren wir vor Beginn. Nicht jede Anwendung benötigt alle folgenden Bereiche.

Wir führen nur Messungen durch, die für die vereinbarte Umgebung sicher sind. Maßnahmen, die Daten verändern, die Last erhöhen oder Nutzer beeinträchtigen können, erfordern eine separate Entscheidung und geeignete Testbedingungen.

So läuft das Audit ab

1. Wir qualifizieren das Problem kurz

Ein Gespräch von bis zu 20 Minuten hilft uns, das Symptom, seine geschäftliche Bedeutung und benötigte Zugriffe zu verstehen. Es ist kostenlos, ersetzt aber weder Diagnose noch Codeanalyse oder Bericht.

2. Wir vereinbaren Umfang und sichere Bedingungen

Wir legen Szenarien, Umgebung, Materialien, Einschränkungen und Ergebnisformat fest. Falls ein Lasttest nötig ist, vereinbaren wir auch dessen Umfang und den Schutz des laufenden Systems.

3. Wir reproduzieren das Problem und erfassen den Ausgangszustand

Für die vereinbarten Vorgänge sammeln wir Messwerte. Lässt sich das Problem nicht reproduzieren, dokumentieren wir diese Einschränkung, statt die Fakten an eine bequeme Vermutung anzupassen.

4. Wir grenzen die Engpässe ein

Wir untersuchen nur die vereinbarten Schichten. Messwerte, Ausführungspläne und Anwendungsverhalten werden verglichen, um belegte Ursachen zu bestimmen.

5. Wir setzen Prioritäten und definieren die Prüfung

Wir trennen schnelle Korrekturen von Änderungen, die eine größere Modernisierung erfordern. Bei jeder wichtigen Empfehlung beschreiben wir, wie ihre Wirkung nach der Umsetzung geprüft werden kann.

Was Sie erhalten

Der Ergebnisumfang wird im Angebot festgelegt. Üblicherweise umfasst er:

• den untersuchten Bereich und die Messbedingungen;
• einen auf Messungen beruhenden Ausgangszustand;
• bestätigte Engpässe mit Belegen und Priorität;
• kurzfristige Empfehlungen und Änderungen, die weitere Entwicklung erfordern;
• eine Methode zur erneuten Prüfung nach der Umsetzung;
• eine empfohlene Reihenfolge der Arbeiten;
• eine separate Umsetzungsschätzung, sofern sich der Umfang zuverlässig bestimmen lässt.

Die Zusammenfassung stellen wir im vorab vereinbarten Format bereit. Sie können sie für weitere Arbeiten mit Domin Software nutzen oder unter Wahrung der Vertraulichkeit an einen anderen Dienstleister übergeben. Eine öffentliche Weitergabe der Materialien ist nicht vorgesehen.

Warum ein Lighthouse-Wert allein nicht genügt

Lighthouse ist hilfreich, um das Laden einer konkreten Seite unter Laborbedingungen zu untersuchen. Das Werkzeug beschreibt allein jedoch weder Datenbank, Queues, Importe und geschützte Bereiche noch das reale Verhalten aller Nutzer.

Google unterscheidet Labordaten von Felddaten realer Nutzer. Ergebnisse können sich durch Gerät, Netzwerk, Standort und Testbedingungen unterscheiden. Gehört eine öffentliche Seite zum Audit, behandeln wir Lighthouse deshalb als eine Informationsquelle, nicht als vollständige Diagnose oder Garantie für eine bestimmte Bewertung.

Bei Datenbanken zählt der Ausführungsplan, nicht nur die Liste der Indizes

Datenbankwerkzeuge zeigen, welcher Plan für eine Abfrage gewählt wurde und was bei der Ausführung geschah. PostgreSQL und MySQL stellen dafür Befehle aus der EXPLAIN-Familie bereit. Die genauen Möglichkeiten hängen von Engine und Version ab.

Solche Messungen helfen unter anderem dabei, die Zahl verarbeiteter Zeilen, die Verknüpfung von Daten und unerwartet aufwendige Stellen einer Abfrage zu bewerten. Ein zusätzlicher Index ist keine Universallösung: Er muss zur tatsächlichen Abfrage passen und kann auch Schreibvorgänge beeinflussen.

Wir wählen die Diagnosemethoden passend zur Datenbank und Umgebung. Auf dem Produktivsystem führen wir keine kostspieligen oder datenverändernden Operationen ohne vereinbarte Sicherheitsbedingungen aus.

Was das Basisaudit nicht umfasst

Sofern das Angebot nichts anderes vorsieht, umfasst der Grundumfang nicht:

• die Umsetzung der empfohlenen Korrekturen;
• laufendes Monitoring und dauerhafte Anwendungswartung;
• zusätzliche Infrastruktur für große Lasttests;
• ein vollständiges Sicherheits-Audit oder ein komplettes Audit einer mit KI erstellten Anwendung;
• die Garantie eines bestimmten Lighthouse-Werts, einer Antwortzeit oder Nutzerzahl;
• die Reparatur von Komponenten, die in der vereinbarten Umgebung nicht sicher untersucht werden können.

Zeigt die Analyse, dass ein größerer Umbau nötig ist, kann eine Anwendungsmodernisierung der nächste Schritt sein. Für laufende Betreuung, Monitoring und Änderungen eignet sich die Wartung von Anwendungen und Onlineshops. Einzelne Empfehlungen können wir als gesonderte PHP- und Laravel-Entwicklungsarbeiten anbieten.

Dauer, Angebot und Abrechnung

Jedes Audit wird individuell kalkuliert, da der Umfang von der Zahl der Prozesse, den Technologien, den verfügbaren Daten und den Testbedingungen abhängt.

Als Richtwert planen wir 5 bis 10 Arbeitstage ab Eingang aller vereinbarten Zugänge und Materialien. Den verbindlichen Termin halten wir im Angebot fest.

Die Abrechnung erfolgt normalerweise nach Abschluss der vereinbarten Etappe. Bei größerem Umfang können wir eine Anzahlung vereinbaren. Beauftragen Sie uns anschließend mit dem weiteren Projekt, wird der Auditpreis auf die Gesamtkosten dieser Arbeiten angerechnet.

Häufige Fragen

Reicht ein Bericht aus PageSpeed Insights oder Lighthouse aus?

Er kann das Gespräch über eine öffentliche Seite erleichtern, ersetzt aber keine Messung des betroffenen Prozesses. Die Ursache eines langsamen Berichts, Imports, Speichervorgangs, einer Queue oder eines Vorgangs nach der Anmeldung zeigt er allein nicht.

Benötigen Sie Zugriff auf das Produktivsystem?

Nicht immer. Zuerst klären wir, wo sich das Problem sicher reproduzieren lässt. Wir bevorzugen eine Testumgebung oder kontrollierte Messungen. Produktivzugriff vereinbaren wir nur, wenn er nötig ist und angemessen eingeschränkt werden kann.

Umfasst das Audit die Umsetzung der Korrekturen?

Im Grundumfang nicht. Zuerst erhalten Sie Diagnose und Prioritäten. Die Umsetzung können wir separat anbieten. Die Unterlagen dürfen Sie auch einem anderen Dienstleister übergeben.

Löst ein zusätzlicher Index das Datenbankproblem?

Manchmal hilft der richtige Index, aber nicht bei jeder Abfrage und in jeder Situation. Zuerst prüfen wir Ausführungsplan, Datenmenge und die tatsächliche Verwendung der Abfrage durch die Anwendung.

Welche Technologien können Sie untersuchen?

Wir arbeiten am häufigsten mit PHP- und Laravel-Anwendungen, Onlineshops und den zugehörigen Datenbanken. Andere Technologie-Stacks qualifizieren wir vor der Kalkulation, damit wir keine Analyse versprechen, die wir nicht zuverlässig leisten können.

Ist ein Audit ohne vorhandenes Monitoring möglich?

Ja, wenn sich das Problem reproduzieren lässt und genügend Material für Messungen vorhanden ist. Reichen die Daten nicht aus, können wir zunächst eine sichere Erfassung empfehlen. Diese Einschränkung wird im Ergebnis klar benannt.

Was Sie uns zunächst senden sollten

Beschreiben Sie im Formular:

• welche Aktion oder welcher Teil des Systems langsam ist;
• wann das Problem auftritt und ob es reproduzierbar ist;
• wie es Mitarbeiter, Kunden oder Verkäufe beeinflusst;
• die ungefähre Zahl der Nutzer, Datensätze oder Operationen, sofern bekannt;
• die eingesetzten Technologien, sofern bekannt;
• größere Änderungen an Anwendung oder Umgebung in letzter Zeit;
• vorhandene Berichte und Messwerte, ohne vertrauliche Daten einzufügen.

Senden Sie im Formular keine Passwörter, API-Schlüssel, Datenbankkopien oder Kundendaten. Einen sicheren Weg für die Übermittlung erforderlicher Materialien vereinbaren wir separat.

Wenn Sie die verfügbaren Informationen zuerst ordnen möchten, nutzen Sie die Checkliste zur Vorbereitung des Performance-Audits. Das Werkzeug diagnostiziert das Problem nicht und verlangt keine vertraulichen Daten.

CTA: Performance-Problem beschreiben

Technische Quellen

• Google: Web Vitals - Unterscheidung zwischen Felddaten und Labordiagnostik sowie Grenzen der INP-Messung in typischen Labortests.
• Google: Einstieg in die Messung von Web Vitals - Gründe für Unterschiede zwischen Laborwerten und realen Nutzerdaten.
• PostgreSQL: Using EXPLAIN - Ausführungspläne und reale Laufzeitinformationen bei der Abfrageanalyse.
• MySQL 8.0: Obtaining Execution Plan Information - Ausführungspläne und Messungen mit EXPLAIN ANALYZE.