Performance Messung
Beschreibung
Mit der Performance Messungs-App können standardisierte Programmprozeduren aufgerufen werden, um die Performance eines installierten Systems zu messen. Die resultierenden Messergebnisse können dann zu Vergleichszwecke herangezogen werden. Folgende Vergleiche wären denkbar:
- Vergleiche mit anderen Systemen (Benchmarking)
- Vergleiche mit älteren Werten auf dem gleichen System
- Tagesverläufe der Performance
Auch kann man diese App einsetzen, um Datenbank Parameter zu ändern (z.B. die der fetch policy (s.u.)) oder sich im Tab "Statistik" die Kennzahlen der Datenbank ausgeben zu lassen. Hierzu öffnet man diese App, stellt die entsprechenden Wert ein und startet eine beliebige andere App. Nach Ende der aufgerufenen Funktionalität untersucht man die Ergebnisse in dieser App.
Funktionalität
Performance Messung Fenster
Über das Fenster Performance Messung können diverse Tests aufgerufen werden.
Feld | Beschreibung |
---|---|
Aufruf von Objekten | Die aufgerufenen Objekte werden mittels Zufallszahl aus der Menge aller Objekte eines Typs (REP collection) ausgesucht. Dadurch soll erreicht werden, dass auch bei einem mehrfachen, hintereinander Aufruf nicht immer die gleichen Objekte - und somit dann aus dem Cache und nicht vom Server - gelesen werden |
: Objekte | - |
: : Teile, Verkaufsartikel, ..., Aufträge, Bestellungen und Andere | Hier kann die Objektart ausgewählt werden, über welche der Test laufen soll. Über die Auswahl "Andere" können beliebige, sogenannte REP collections ausgewählt werden, die Listen, in denen die Objekte der meisten Klassen registriert sind. |
: DB Modus | |
: : MVCC | Die Performance Messungen werden ausschließlich im MVCC Modus durchgeführt, d.h. in die Datenbank (kann) wird nicht geschrieben (werden). Ist dieser Modus ausgewählt und ist diese App geöffnet, dann können auch andere Module nicht in die Datenbank schreiben. Erst durch Schließen dieser App wird der voreingestellte Schreib-/Lesemodus der Datenbank wieder hergestellt. |
: : WRITE | Die Datenbank wird im Schreib-/Lesemodus gefahren. Sollte sich im auszuführenden Programmcode eine "BeginTXN(READ)" Anweisung befinden, wird die Datenbank geschlossen und im MVCC Modus wieder geöffnet. Um dieses zu verhindern, kann man den Modus KEEP_UPDATE auswählen. (s.u.) |
: : KEEP_UPDATE | In diesem Modus ist die Datenbank für Schreib.- und Lesetransaktionen geöffnet, allerdings werden die im Programmcode eventuell durchlaufenen "BeginTXN(READ)" Anweisungen ignoriert. Die Zeit für Schließen und Öffnen der Datenbank entfällt somit. |
: Lesemodus | |
:: sequentiell | Die gewählte Liste an Objekten (REP collection) wird sequentiell bis zur Anzahl zu zählender Objekte gelesen. |
: : zufällig | Aus der gewählten List an Objekten (REP collection) wird die Anzahl auszuwählender Objekte zufällig ausgewählt. |
: Optionen | - |
: : Anzahl begrenzen | Begrenzung der Anzahl der Objekte, auf welche zugegriffen werden soll. Wird eine Begrenzung ausgewählt, werden die aufgerufenen Objekte mittels Zufallszahl aus der Menge aller Objekte eines Typs (REP collection) ausgesucht. Dadurch soll erreicht werden, dass auch bei einem mehrfachen, hintereinander Aufruf nicht immer die gleichen Objekte - und somit dann aus dem Cache und nicht vom Server - gelesen werden.
Wird keine Begrenzung ausgewählt, wird die Menge aller Objekte eines Typs (REP collection) sequentiell aufgerufen. |
: : Objekt "anfassen" | Für jedes gelesene Objekt wird das unter diesem Feld angegebene Kommando ausgeführt, im Standardfall wird mittels der Prozedur G_ObjectDescription seine Beschreibung gelesen. Nach dem Ausführen des in diesem Feld angegebenen Kommandos wird automatisch ein "DropAll" hinzugefügt. |
: : Codeoptimierung |
Für diese Gruppe gibt es 3 mögliche Einstellungen, um Test-Overhead pro Objekt zu reduzieren. Keine Optimierung: Der Objekt-Code wird pro Objekt per Execute geparsed und ausgeführt. (langsamste Option) Code vorkompillieren: Der Objekt-Code wird einmalig in eine anonyme Prozedur umgewandelt (geparsed) und anschließend pro Objekt nur noch per Execute ausgeführt. Dadurch fällt der Parse-Overhead pro Objekt weg. Code einfügen: Der Objekt-Code wird so, wie er steht in den generierten Test-Code eingefügt. Hiermit gibt es keinen Overhead mehr für die Ausführung des Objekt-Codes. (schnellste Option) |
: : Client Cache leeren |
Vor jeder Ausführung einer Messung wird der Cache des Clients geleert, d.h. die Messungen sind untereinander besser vergleichbar. Andererseits kann beobachtet werden, wie - durch Wachsen des Caches - die Geschwindigkeit eines Lesezyklus zunimmt, da einige pages bereits im Cache vorhanden sein sollten. Bei jedem leeren des Client Caches werden auch die ObjectStore Statistik counter zurückgesetzt. |
: : jetzt leeren |
Wird dieser Knopf betätigt, wird der Client Cache geleert. Hiermit lassen sich Ladezeiten von der Datenbank unabhängig vom Cache des Client vergleichen. Die ObjectStore Statistik counter werden ebenfalls zurückgesetzt. |
: : Pro Objekt eine Transaktion | Pro Objekt wird eine neue Transaktion geöffnet und geschlossen, hiermit kann also die Transaktions-Overheadzeit ermittelt werden. |
: : OS Zähler zurücksetzen | Die in der Lasche "Statistik" ausgegebenen OS (ObjectStore) Zähler werden vor Ausführung einer neuen Messung jeweils auf Null zurückgestellt. |
: : Min/Max Dauer messen | Die in der Gruppe Test starten (s.u.) angezeigten Werte für "Minimum/Maximum Dauer pro Objekt" werden bei der Messung ermittelt. |
: : Editierfenster aufrufen | Bei dieser Option werden die Objekte nicht nur "angefasst", sondern auch in ihrem Bearbeitungsfenster angezeigt. |
: : Listenfenster aufrufen | Einlesen der Objekte in das Listenfenster. |
: : : Hinzufügen - Einzeln | Die Objekte werden einzeln in die Liste eingefügt. |
: : : Hinzufügen - Komplett | Alle gewählten Objekte werden als vollständig gefüllte Collection in die Liste eingefügt. |
: : : Sortierung - Vorher | Die Sortierung wird vor dem Einlesen der Liste gesetzt. Dadurch wird bei jedem Einfügen eines Objekts in die Liste die Sortierung angestossen, was zu hohen zeitlichen Kosten führt. |
: : : Sortierung - Nachher | Die Sortierung wird nach dem Einlesen der Liste gesetzt. |
: Test starten | - |
: : Einfach | Auf Grundlage der gesetzten Einstellungen wird der Test einmalig gestartet. Als Ergebnis liefert er die Dauer und die durchschnittliche Dauer je Objekt zurück. |
: : Verlauf | Beim Verlauf wird der Test in einem Intervall von einer Minute gestartet. Als Ergebnis liegt dann ein Diagramm vor und der Durchschnittswert aus allen Durchläufen. |
:: Gesamtanzahl Objekte | Die Gesamtanzahl an Objekten in der ausgewählten Liste. |
: : Gesamtdauer | Dauer eines gesamten Durchlaufs aller gewählten Objekte. |
: : Durchschnittl. Dauer pro Objekt | Durchschnittliche Dauer zum Lesen/Anzeigen eines Objekts. |
: : Minimum Dauer pro Objekt | Kürzeste Durchlaufzeit für ein Objekt. |
: : Maximum Dauer pro Objekt | Längste Durchlaufzeit für ein Objekt. |
Statistik | |
: ObjectStore counter | |
: : ObjectStore Zähler aktivieren | Die in der Liste angezeigten ObjectStore Zähler werden nach jeder Messung automatisch ausgegeben. Es ist zu beachten, dass die Zähler fortlaufend hochgezählt werden, will man den Zählerstand für nur eine Messung haben, müsen die Zähler vorher zurückgesetzt werden. (siehe unter Optionen "OS Zähler zurücksetzen" oder unten Knopf "Zurücksetzen".) Wird manuell der Client Cache geleert (s.o.) oder soll bei jedem neuen Zyklus der Client Cache automatisch geleert werden, dann werden die Zähler ebenfalls zurückgesetzt. |
: : Liste der Zähler | Erklärung zu einigen Zählern |
: : : n_fetch_page | Anzahl der vom Datenbank Server angeforderten (Speicher-) Seiten. Ist diese Anzahl kleiner als die Anzahl des Zählers n_pages_read (s.u.), wurden (zumindest einige) Daten direkt aus dem Cache gelesen. Der hier angezeigte Wert ist von der fetch policy abhängig (s.u.), d.h. ist die fetch policy im Page Modus > 1 eingestellt, dann wird hier die Anzahl der fetches ausgegeben. |
: : : n_pages_read | Anzahl der mit einem read lock versehenen (Speicher-) Seiten. |
: : : n_pages_written | Anzahl der mit einem write lock versehenen (Speicher-) Seiten. |
: : Zurücksetzen | Alle Zähler werden auf Null zurückgesetzt. |
: : Auslesen | Der aktuelle Stand der Zähler wird ausgegeben. Hiermit kann man sich aus jeder anderen App heraus den Zählerstand vor und nach der entsprechend in der App ausgelösten Datenbank Transaktion(en) ausgeben lassen und entsprechende Rückschlüsse schließen. |
Parameter | Anzeige der gesetzten Parameter des ClassiX Systems, des Objectstore Clients und Servers. |
: ClassiX Parameter | |
: : CX_CLUSTERING | Anzeige des CX_CLUSTERING Wertes. |
: : CX_FIXED_CACHE_SIZE | Anzeige des CX_FIXED_CACHE_SIZE Wertes. |
: : CX_TS_CACHE_SIZE | Anzeige des CX_TS_CACHE_SIZE Wertes. |
: : CX_CACHE_SIZE_FACTOR | Anzeige des CX_CACHE_SIZE_FACTOR Wertes. |
: ObjectStore Client Parameter | |
: : OS_AS_SIZE | Anzeige des OS_AS_SIZE Wertes. |
: : OS_CACHE_SIZE | Anzeige des OS_CACHE_SIZE Wertes. Ist diese Umgebungsvariable explizit nicht gesetzt, dann wird der Wert über die Funktion GetCacheSize() des Objektmanagers ausgegeben. |
: : OS_SNDBUF_SIZE | Anzeige des OS_SNDBUF_SIZE Wertes. |
: : OS_RCVBUF_SIZE | Anzeige des OS_RCVBUF_SIZE Wertes. |
: : Fetch policy | |
: : : Cluster | Für die Datenbank wird "Cluster" als globale Fetch Policy eingestellt, d.h. die angeforderten Pages werden nach Clustern von der Datenbank ausgeliefert. Dieses führt zu einer größeren Ausnutzung der Bandbreite des Netzwerks. |
: : : Stream | Für die Datenbank wird "Stream" als globale Fetch Policy eingestellt. |
: : : Pages | Für die Datenbank wird "Pages" als globale Fetch Policy eingestellt, d.h. die angeforderten Pages werden gemäß dieser Zahl von der Datenbank ausgeliefert. Die Ladezeit der Pages wird dabei von der Latenz des Netzwerks bestimmt. 1 Page entspricht 4kB, man kann 1, 2, 4, 6, 8, 16 und 32 Pages einstellen. |
: Datenbanken | Ausgabe der im Zugriff befindlichen Datenbanken. |
: ObjectStore Server Parameter | |
: : Server | Liste der Datenbank Server. Wird ein Server ausgewählt, werden die Parameter dieses Servers ausgegeben. Die Liste entspricht dem Kommandozeilen Aufruf "ossvrstat -parameters". Zusätzlich werden in der dritten Spalte eventuell von ClassiX empfohlene Werte ausgegeben. Sollte sich solch ein empfohlener Wert vom eingestellten Wert unterscheiden, wird ein Ausrufungszeichen als Warnhinweis ausgegeben |
Knopf | Beschreibung |
---|---|
Start | Starten eines Testlaufs |
Stopp | Dieser Knopf wird in der Wartezeit zwischen zwei Testläufen aktiviert. Er beendet den aktuellen Verlauf |
Verwandte Themen
Technische Dokumentation
"Modul" Basismodul
Modulname
"Modul".mod
Klassen
Security
Neben der Beschränkung der Zugriffsrechte über die Klasse und deren Datenfelder kann das Modul über einige der empfangenen Messages in seiner Nutzung beschränkt werden.
Message | Parameter | Funktion | Security |
---|---|---|---|
PERFORMANCE_RATING | Aufruf der App | ||
Message | Parameter | Funktion | Empfangs-Modul |
---|---|---|---|
"Modul" Editiermodul
Modulname
"Modul".mod
Klassen
Security
Neben der Beschränkung der Zugriffsrechte über die Klasse und deren Datenfelder kann das Modul über einige der empfangenen Messages in seiner Nutzung beschränkt werden.
Message | Parameter | Funktion | Security |
---|---|---|---|
Message | Parameter | Funktion | Empfangs-Modul |
---|---|---|---|
"Modul" Selektionsmodul
Modulname
"Modul".mod
Klassen
Security
Neben der Beschränkung der Zugriffsrechte über die Klasse und deren Datenfelder kann das Modul über einige der empfangenen Messages in seiner Nutzung beschränkt werden.
Message | Parameter | Funktion | Security |
---|---|---|---|
Message | Parameter | Funktion | Empfangs-Modul |
---|---|---|---|