Datenbank-Performance testen
Visual Planning bringt einen eingebauten Performance-Test mit, der die Verbindung zwischen Client, Server und Datenbank misst. Diese Anleitung beschreibt, wie der Test ausgeführt wird und wie die Ergebnisse zu lesen sind.
Was der Test macht
Der Test läuft in vier Abschnitten ab. Für den Datenbankteil legt Visual Planning im Hintergrund eine eigene Testtabelle an, schreibt dort 50.000 Datensätze hinein, aktualisiert sie, liest sie und löscht sie anschließend wieder. Der produktive Datenbestand wird dabei nicht verändert.
- Ping – Antwortzeit zwischen Client und Server (20 Messungen)
- Download / Upload – Übertragungsrate zwischen Client und Server
- Datenbank – Insert, Update, Read und Delete über 50.000 Datensätze
Gemessen wird ausschließlich die reine Datenbank- und Verbindungsleistung, nicht die Verarbeitung innerhalb der Anwendung.
Voraussetzungen
- Anmeldung als Super-Administrator (oder ein Benutzer mit Administrationsrechten)
- Der Test sollte möglichst während des normalen Betriebs laufen, damit die Werte der tatsächlichen Nutzungssituation entsprechen. Für einen Vergleichswert ohne Last kann er zusätzlich außerhalb der Arbeitszeit wiederholt werden.
- Der Test erzeugt kurzzeitig Last auf der Datenbank. Auf produktiven Systemen mit vielen aktiven Benutzern das entsprechend einplanen.
Schritt für Schritt
Visual Planning öffnen
Melden Sie sich am Visual Planning Client bzw. am Admin Center an.
Menü „?“ öffnen und „Über Visual Planning…“ wählen
Klicken Sie oben rechts in der Titelleiste auf das Fragezeichen-Symbol und anschließend auf
Über Visual Planning….
Das Hilfe-Menü in der oberen rechten Ecke des Fensters. Test starten
Im Info-Dialog stehen unterhalb des Logos drei Schaltflächen. Klicken Sie auf die rechte Schaltfläche
Netzwerk Performance testen(Symbol mit der Tachoanzeige).
Testlauf abwarten
Der Test läuft ohne weitere Eingaben durch. Die einzelnen Abschnitte erscheinen nacheinander im Log-Fenster. Je nach Systemleistung dauert der Durchlauf einige Sekunden bis wenige Minuten – während dieser Zeit den Dialog nicht schließen.
Ergebnis sichern
Nach Abschluss zeigt das Log-Fenster alle Messwerte. Erstellen Sie einen Screenshot oder kopieren Sie den Text heraus, bevor Sie das Fenster schließen.
Beispielergebnis eines Durchlaufs gegen eine PostgreSQL-Datenbank. 
Wiederholen und vergleichen
Ein einzelner Durchlauf ist nur eine Momentaufnahme. Führen Sie den Test zwei- bis dreimal aus und vergleichen Sie die Werte. Aussagekräftig wird das Ergebnis vor allem im Vergleich: gegen einen früheren Messwert desselben Systems.
Ergebnisse lesen
Die Werte aus dem obigen Beispiel und ihre Bedeutung:
| Messwert | Beispiel | Bedeutung |
|---|---|---|
| Ping (Average / Min / Max) | 26 / 25 / 28 ms | Latenz zwischen Client und Server. Entscheidend ist weniger der Absolutwert als die Streuung: Liegen Min und Max weit auseinander, ist die Verbindung instabil. |
| Download | 23.883 KB/s | Datenrate vom Server zum Client. Wirkt sich vor allem auf das Laden großer Ansichten und Berichte aus. |
| Upload | 8.159 KB/s | Datenrate vom Client zum Server. Relevant beim Speichern und beim Import von Daten. |
| Insert (50.000 Zeilen) | 6.978 ms | Schreibleistung der Datenbank. Meist der langsamste Teil, da hier auch Indizes und Transaktionslog geschrieben werden. |
| Update | 1.240 ms | Änderungsleistung über den gesamten Testdatenbestand. |
| Read | 490 ms | Leseleistung. Für den Alltagseindruck in Visual Planning der wichtigste Wert, da die Anwendung überwiegend liest. |
| Delete | 301 ms | Löschleistung; räumt die Testtabelle wieder auf. |
Einordnung
Es gibt keine allgemeingültigen Grenzwerte – sie hängen von Serverhardware, Storage, Netzanbindung und Datenbanksystem ab. Als grobe Orientierung: Ping-Zeiten im einstelligen Millisekundenbereich sprechen für ein lokales Netz, Werte um 25–30 ms für eine Anbindung über VPN oder Internet. Beim Datenbankteil ist ein Insert im Sekundenbereich bei 50.000 Zeilen normal, während sich Read und Delete üblicherweise im Bereich weniger hundert Millisekunden bewegen. Auffällig wird es, wenn einzelne Werte um ein Vielfaches über einem früheren Vergleichswert desselben Systems liegen.
Wenn die Werte gut sind, Visual Planning aber langsam ist
Der Test bewertet ausschließlich Verbindung und Datenbank. Fällt er unauffällig aus, die Anwendung fühlt sich aber trotzdem träge an, liegt die Ursache an anderer Stelle. Typische Kandidaten:
- Tomcat und Speicherzuweisung – zu klein dimensionierter Heap, dadurch häufige Garbage Collection; ungeeignete Connector- oder Thread-Einstellungen.
- Serverleistung insgesamt – CPU-Auslastung, verfügbarer RAM, Storage-Latenz, gemeinsam genutzte virtuelle Hosts.
- Konfiguration in Visual Planning – sehr große Ansichten, weit gefasste Zeiträume, viele gleichzeitig geladene Dimensionen, aufwendige Filter oder Regeln.
- Datenmenge und Indizierung – stark gewachsene Tabellen, fehlende kombinierte Indizes, nicht gepflegte Statistiken.
- Client und Arbeitsplatz – Ressourcen des Endgeräts, Virenscanner, Terminalserver-Sitzungen mit vielen parallelen Benutzern.
Hinweis zur Datenbank
Im gezeigten Beispiel wird eine PostgreSQL-Datenbank verwendet. Der Test läuft mit anderen unterstützten Datenbanksystemen identisch ab, die absoluten Zeiten sind zwischen verschiedenen Systemen jedoch nicht direkt vergleichbar.
War dieser Artikel hilfreich?
Das ist großartig!
Vielen Dank für das Feedback
Leider konnten wir nicht helfen
Vielen Dank für das Feedback
Feedback gesendet
Wir wissen Ihre Bemühungen zu schätzen und werden versuchen, den Artikel zu korrigieren