1                     Kurzbeschreibung

In diesem Dokument wird sowohl die Benutzung des Profilings als auch die Anwendung „Profiling-Protokolle abfragen“ beschrieben, mit der Profiling-Protokolle ausgewertet werden können. Darüber hinaus ist das andockbare Fenster „Profiling“ beschrieben, welches ein Aktivieren und Deaktivieren des Profilings über die Bedienungsoberfläche erlaubt. Dieses andockbare Fenster ist eine Alternative zur Ausführung des Tools „Mit Profiling arbeiten“.

Das Profiling ermöglicht Ihnen insbesondere die Datenbankzugriffe einer einzelnen Aktion oder einer beschränkten Folge von Aktionen in einem Protokoll aufzuzeichnen. Mithilfe dieser Aufzeichnung können Sie Schwachstellen in der Implementierung der aufgezeichneten Aktionen identifizieren.

Die Profiling-Protokolle sollten zur Qualitätssicherung und Optimierung der Leistungsfähigkeit im Entwicklungssystem bzw. im Entwicklungstestsystem eingesetzt werden. Sofern ein akutes Problem mit der Leistungsfähigkeit im Produktivsystem vorliegt und dies auf eine Aktion reduziert werden kann, dann können die Profiling-Protokolle auch dort genutzt werden.

2                     Zielgruppe

• Anwendungsentwickler
• Technische Berater

3                     Beschreibung

Für eine Analyse der Leistungsfähigkeit einer Anwendung sind primär die Art und Anzahl der Zugriffe auf den Persistenzdienst interessant, da davon ausgegangen wird, dass dies einen Großteil der Leistung kostet. Gerade diese Zugriffe sind sehr kontextabhängig und im Allgemeinen auf beliebig viele und ständig wechselnde Threads verteilt. Ein allgemeines Profiling-Tool würde entweder diese nicht auseinander halten können oder einen relativ hohen Einstellungsaufwand im Profiler benötigen. Aus diesem Grund wurde ein spezieller Profiler für den Persistenzdienst entwickelt.

3.1        Der Comarch-ERP-Enterprise-Profiler

Der entwickelte Profiler protokolliert für einen Application-Server die Aktionen des Persistenzdienstes und arbeitet in folgenden Schritten:

1. Erstellen einer Datei mit den Profiling-Daten.
2. Auswerten dieser Datei.

Der Profiler kann demnach nicht umgehend Profiling-Daten auswerten. Zunächst muss durch den Profiler eine Datei mit den Profiling-Daten erstellt und die Aufzeichnung abgeschlossen werden, bevor die Daten in der Datei analysiert werden können. In der Datei werden alle oder ausgewählte Aktionen protokolliert.

Folgende Aktionen des Persistenzdienstes werden protokolliert:

• Aufruf von CisObjectManager.getObject
• Aufruf von CisObjectManager.getObjectIterator
• Aufruf von CisObjectManager.getResultSet
• Aufruf von CisObjectManager.getObjectArray
• Datenbankzugriff (DatabaseAccess)
• Öffnen einer Transaktion (TransactionBegin)
• Sperranfragen (AcquireLock)

Jede Aktion hat einen Kontext, in dem sie ausgeführt wird. Dieser Kontext hat wieder einen übergeordneten Kontext, sodass eine Aktion in eine Kontexthierarchie eingebettet ist. Die nachstehenden Kontexte sind größtenteils durch die Architektur des ERP-Systems vorgegeben:

• Application-Server

Das Profiling-Protokoll gehört zu genau dem ERP-System-Application-Server, auf dem das Profiling gestartet wurde.

• Session

Eine Session kann nur im ERP-System-Application-Server-Kontext geöffnet werden, d. h. eine Session gehört zu einem ERP-System-Application-Server.

• Anwendungsinstanz

Eine Anwendungsinstanz kann nur im Session-Kontext geöffnet werden, d. h. eine Anwendung gehört zu einer Session. Dieser Kontext wird als Anwendungskontext bezeichnet.

• Transaktion

Eine Transaktion kann nur im Session- oder Anwendungskontext geöffnet werden, d. h. eine Transaktion gehört entweder zu einer Anwendung oder Session.

• Anwendungsfunktion

Eine Anwendungsfunktion kann nur im Anwendungskontext geöffnet werden, d. h. eine Anwendungsfunktion gehört zu einer Anwendung. Dieser Kontext wird Funktionskontext bezeichnet.

Alle Aktionen des Persistenzdienstes werden immer in einem Transaktionskontext protokolliert. Durch die Auswertungskomponente, die Anwendung „Profiling-Protokolle abfragen, können alle Aktionen auf beliebiger Granularitätsebene aggregiert werden.

Das Profiling misst primär Operationen gemäß ihrer Komplexität und nicht die Ausführungszeiten. Das Messen von Zeiten ist deshalb wenig sinnvoll, weil dabei auch die Eigenheiten der Messumgebung mitgemessen werden und auf unterschiedlichen Testumgebungen ermittelte Messergebnisse wenig vergleichbar sind. Da aber bekannt ist, wie aufwendig die unterschiedlichen Operationen sind, gibt die Anzahl der Operationen eine mindestens genauso gute Aussage wie die benötigte Zeit.

Hinweis:

Wenn Sie Profiling-Protokolle auf dem Produktivsystem aufzeichnen, dann sollten Sie das nur auf einem speziell dafür ausgewiesenen ERP-System-Application-Server starten. Dieser ERP-System-Application-Server sollte keine andere Funktion als das Aufzeichnen des Profiling-Protokolls haben. Die Leistungsfähigkeit des ERP-System-Application-Servers wird durch das Aufzeichnen des Profiling-Protokolls deutlich reduziert. Auf Nicht-Entwicklungssystemen benötigen Sie zudem eine spezielle, administrative Fähigkeit um Profiling-Protokolle aufzeichnen zu können. Siehe dazu dieses Kapitel: Spezielle Fähigkeiten

3.1.1          Anwendungsfunktionen

In der Regel sind innerhalb einer Anwendung nur bestimmte Bereiche für das Profiling interessant. Die Kennzeichnung eines Bereichs ermöglicht pro Profiling-Aufzeichnung die besondere Ausweisung im Profiling-Protokoll, sodass gezielt ermittelt werden kann, welche und wie viele Aktionen jeweils innerhalb des Bereichs ausgeführt wurden.

Um die im Protokoll besonders auszuweisenden Bereiche für den Profiler sichtbar zu machen, stehen die Methoden „profilingBegin“ und „profilingEnd“ am „CisApplicationManager“ zur Verfügung. Mit diesen Methoden werden der Beginn und das Ende eines Bereiches gekennzeichnet sowie ein Bereichsname vergeben.

Beispiel:

CisApplicationManager am;
byte[] prfValidate;
am = CisEnvironment.getInstance().getApplicationManager();
prfValidate = am.profilingBegin(this.getClass().getName()+”:validate”);
try {
…
} finally {
am.profilingEnd(prfValidate);
}

Anwendungsfunktionen sind einer Anwendung untergeordnet. Jede Aktion wird bei der Auswertung sowohl im Anwendungskontext als auch im jeweiligen Funktionskontext gezählt. Bei abgeschaltetem Profiling kostet der Methodenaufruf so wenig Zeit, dass dieser auch im produktiven Code bestehen bleiben kann.

Die Einführung von Anwendungsfunktionen ist die einzige Möglichkeit, um die Zählungen nach Anwendungsfunktionalität zu gruppieren.

3.1.2          Profiling starten

Sie können das Profiling auf verschiedene Weise starten, um ein Profiling-Protokoll aufzuzeichnen. Durch die Aufzeichnung entsteht eine Datei, die in der Anwendung „Profiling-Protokolle abfragen“ ausgewertet werden kann.

3.1.2.1      Tool „Mit Profiling arbeiten“ (wrkprf)

Mit dem Toolshell-Befehl „wrkprf“ wird der Profiler gesteuert. Weitere Informationen finden Sie in der Dokumentation „Mit Profiling arbeiten“.

Die wichtigsten Parameter:

• wrkprf -start:<Dateiname>

Startet das Profiling auf dem ERP-System-Application-Server und speichert die Daten in die angegebene Datei
(z. B. wrkprf –start:c:\temp\profiling.dat).

• wrkprf –stop

Beendet das Profiling auf dem ERP-System-Application-Server und gibt die Profiling-Datei frei.

Nach dem Start des Profilers werden die Daten zu jeder neuen Session aufgezeichnet, d. h. Sie sollten sich danach über ein neues Browserfenster am ERP-System-Application-Server anmelden.

Hinweis:

Die Profiling-Protokolldatei wird auf dem lokalen Datenträger des ERP-System-Application-Servers abgelegt. Beachten Sie deshalb bei der Wahl des Datei­namens, dass nicht unnötig wichtige lokale Dateien überschrieben werden.

Hinweis:

Die Anwendung „Profiling-Protokolle abfragen“ sollte auf dem ERP-System-Application-Server geöffnet werden, der das Profiling-Protokoll erstellt hat. Aktivieren Sie nicht das Profiling auf einem ERP-System-Application-Server, auf dem Benutzer produktiv arbeiten.

Wenn nur eine bestimmte Funktionalität eines Programms gemessen werden soll, ohne Anwendungsfunktionen festzulegen, dann kann das Profiling ausgesetzt und wieder aufgenommen werden. Dazu dienen die folgenden Befehle:

• wrkprf –pause

Das Protokollieren der Aktionen wird ausgesetzt.

• wrkprf –resume

Das Protokollieren der Aktionen wird wieder aufgenommen.

Diese Befehle können beliebig oft wiederholt werden. Damit ist möglich, die Anwendung über ihre Oberfläche bis zum messenden Bereich auszuführen und dann gezielt das Profiling nur für den ausgezeichneten Bereich zu aktivieren.

Die Auswertung des Profiling-Protokolls erfolgt über die Anwendung „Profiling-Protokolle abfragen“.

Hinweis:

Wenn Sie z. B. einen neu entwickelten Code testen möchten, ohne ihn gleich in eine Anwendung einzubauen, dann hilft Ihnen der Parameter „-attachToolshell“ dieses Tools. Dann können Sie über eine Hilfsklasse, die eine „main“-Methode enthält, beliebigen Code ausführen und aufzeichnen.

3.1.2.2      Andockbares Fenster „Profiling“

Das andockbare Fenster „Profiling“ ermöglicht Ihnen das Profiling über die Bedienungsoberfläche zu starten und damit ein Profiling-Protokoll erzeugen zu lassen. Dieses andockbare Fenster ist unabhängig von der Anwendung „Profiling-Protokolle abfragen“ und steht Ihnen generell zur Verfügung, wenn Ihnen die entsprechende Fähigkeit zur Ausführung erlaubt wurde. Beachten Sie dieses Kapitel: Spezielle Fähigkeiten

Dieses andockbare Fenster enthält Elemente, die in folgenden Kapiteln beschrieben sind:

• Felder
• Liste
• Buttons

Felder

Die Felder des andockbaren Fensters im Einzelnen:

Feld	Erläuterung
Profiling-Protokoll	Im Feld „Profiling-Protokoll“ erfassen Sie einen Dateinamen inklusive Dateipfad für das aufzuzeichnende Protokoll oder wählen eine bereits bestehende Datei mithilfe der Wertehilfe aus. Beachten Sie, dass die Datei im Knowledge Store abgelegt wird und der Dateipfad folgendes Muster hat: kstore://{Datenbank}/{Ordner}/{Dateiname} Hinweis: Wir empfehlen das Dateiformat „.dat“. Grundsätzlich können Sie jedes Format wählen.
Aktionen	In diesem Feld wählen Sie aus, welche der Aktionen aufgezeichnet werden sollen. Wählen Sie aus folgenden Einträgen: ·         Sperranfrage ·         Datenbankzugriff ·         ObjectManager.getObject ·         ObjectManager.getObjectArray ·         ObjectManager.getResultSet ·         ObjectManager.getObjectIterator

Liste

In der Liste im andockbaren Fenster können Sie die vollqualifizierten Namen der Business Objects hinzufügen, die speziell aufgezeichnet werden sollen, wenn die jeweilige Aktion aufgezeichnet wird. Falls bei einer der aufgezeichneten Aktionen dieser String auftritt, z. B. als Name des verwendeten Business Objects oder auch als ein verwendeter OQL- bzw. SQL-String, dann wird zusätzlich noch die Stackframe-Information aufgezeichnet. Somit lässt sich die Stelle im Source-Code bestimmen, von welcher der Aufruf erfolgte.

Für die Liste stehen Ihnen folgende Buttons in der Listen-Symbolleiste zur Verfügung:

• Neu

Mit der Neu-Aktion fügen Sie ein neues Business Object der Liste hinzu. Wenn Sie auf den Button drücken, dann wird eine neue Zeile der Liste hinzugefügt. Nutzen Sie bei Bedarf die Wertehilfe, um das Business Object herauszusuchen und in die Liste zu übernehmen können.

• Löschen

Mithilfe des Löschen-Buttons können Sie aus der Liste eine zuvor markierte Zeile löschen und damit das betroffene Business Object von der Aufzeichnung ausschließen.

Die Liste des andockbaren Fensters enthält folgende Spalte:

Spalte	Erläuterung
Typ	In dieser Spalte können Sie die vollqualifizierten Namen der Business Objects hinzufügen, die speziell aufgezeichnet werden sollen. Falls bei einer der aufgezeichneten Aktionen dieser String auftritt, z. B. als Name des verwendeten Business Objects oder auch als ein verwendeter OQL- bzw. SQL-String, dann wird zusätzlich noch die Stackframe-Information aufgezeichnet.

Buttons

• Button „Aufzeichnung starten“

Mit diesem Button starten Sie die Aufzeichnung. Dies entspricht diesem Tool-Aufruf: wrkprf –start:<Dateiname>

• Button „Aufzeichnung beenden“

Mit diesem Button stoppen Sie die Aufzeichnung. Dies entspricht diesem Tool-Aufruf: wrkprf –stop

• Button „Anwendung zur Auswertung öffnen“

Mithilfe dieses Buttons wechseln Sie in die Anwendung „Profiling-Protokolle abfragen“. Dabei wird die Datei geöffnet, die im Feld „Profiling-Protokoll“ angegeben ist. Ist eine Datei angegeben, die nicht mithilfe des Profilings aufgezeichnet wurde, dann wird die Anwendung ohne das angegebene Protokoll geöffnet.

3.2        Anwendungsbeschreibung

Die Anwendung „Profiling-Protokolle abfragen“ dient dem Auswerten der Profiling-Daten. Sie ist im Wesentlichen wie folgt aufgeteilt:

• Im Abfragebereich erfolgt die Konfiguration für die Auswertung des Profiling-Protokolls. Siehe Kapitel: Abfragebereich
• Im Arbeitsbereich werden die Ergebnisse der im Abfragebereich konfigurierten Auswertungsanfrage angezeigt. Siehe Kapitel: Arbeitsbereich
• Das andockbare Fenster „Sessions“ zeigt die Sessions, Anwendungen und Anwendungsfunktionen des geöffneten Profiling-Protokolls in einer Baumstruktur an. Siehe Kapitel: Andockbares Fenster „Sessions“

3.2.1          Abfragebereich

Der Abfragebereich umfasst die Angabe der auszuwertenden Protokolldatei und weitere Einstellungen für die im Arbeitsbereich anzuzeigenden Daten.

Die Felder im Einzelnen:

Feld	Erläuterung
Profiling-Protokoll	Im Feld „Profiling-Protokoll“ erfassen Sie den Dateinamen inklusive Dateipfad der Protokolldatei, die Sie auswerten möchten. Alternativ wählen Sie eine Datei mithilfe der Wertehilfe aus. Beachten Sie, dass die Datei im Knowledge Store abgelegt wird und der Dateipfad folgendes Muster hat: kstore://{Datenbank}/{Ordner}/{Dateiname} Hinweis: Beachten Sie, dass Sie nur solche Dateien auswerten können, die mithilfe der von Comarch ERP Enterprise zur Verfügung gestellten Aufzeichnungshilfen aufgezeichnet wurden. Siehe bei Bedarf dieses Kapitel: Profiling starten
Session	Im Feld „Session“ wird die Session angezeigt, auf welche sich eine Auswertung bezieht. Beim Öffnen des Profiling-Protokolls wird die erste Session angezeigt, die in der Datei vorhanden ist. Sie können im Feld die Session nicht direkt ändern. Sie wechseln die Session, in dem Sie im andockbaren Fenster „Sessions“ eine andere Session auswählen.
Anwendung	Im Feld „Anwendung“ können Sie einen oder mehrere Anwendungsnamen erfassen, um die Auswertung und damit die Ergebnisliste auf diese Anwendungen zu beziehen. Alternativ können Sie einen Anwendungsnamen im andockbaren Fenster „Sessions“ auswählen, in dem er als Unterordner eines Session-Ordners angezeigt wird. Bleibt dies Feld leer, dann beziehen sich die angezeigten Daten auf alle Anwendungen. Das Feld hat keine Werthilfe.
Funktion	Im Feld „Funktion“ können Sie eine oder mehrere Funktionsnamen erfassen, um die Auswertung auf diese Funktionen zu beziehen. Alternativ können Sie eine Funktion im andockbaren Fenster „Sessions“ auswählen. Im andockbaren Fenster wird eine Funktion unterhalb des Ordners „Anwendung“ angezeigt. Bleibt dies Feld leer, dann beziehen sich die angezeigten Daten auf alle Funktionen. Das Feld hat keine Werthilfe.

3.2.1.1      Aufklappbereich „Einstellung Actions“

Die Felder im Einzelnen:

Feld	Erläuterung
Rubrik „Filter“
Actions	Im Feld „Actions“ legen Sie fest, welche Actions ausgewertet und in der Ergebnisliste angezeigt werden sollen. Wählen Sie aus diesen Einträgen: ·         getObject ·         getObjectIterator ·         getResultSet ·         getObjectArray ·         Datenbankzugriff ·         Transaction Begin ·         Sperranforderung
Aggregation	In diesem Feld legen Sie die Aggregation der Daten für Actions fest, um die Ergebnisliste der Auswertungsdaten zu optimieren. Wählen Sie zwischen folgenden Einträgen: ·         Datenbank ·         Schlüssel ·         Einstellungen ·         Operation ·         Zugriffsinformation Beispiel: Bei der Aufzeichnung wird unterschieden, welcher Schlüssel für den Zugriff auf ein Objekt („getObject“) verwendet wurde. Möchten Sie diese separierte Information in der Ergebnisliste für Ihre Auswertung anzeigen lassen, dann wählen Sie diesen Eintrag aus. Möchten Sie die Summe der Zugriffe in der Ergebnisliste auswerten, dann wählen Sie den Eintrag „Schlüssel“ in diesem Feld nicht aus. Daraufhin wird nicht mehr nach dem verwendeten Schlüssel in der Ergebnisliste unterschieden. Hinweis: Bezieht sich eine Aktion nicht auf einen Schlüssel, dann ergibt sich kein Unterschied. Bei einem Zugriff über ein „ResultSet“ wird keine Information über den verwendeten Schlüssel aufgezeichnet. Daher liefert z. B. die Aggregationseinstellung „Schlüssel“ keinen Unterschied.
Filtern nach	Im Feld „Filtern nach“ können Sie die Aggregation festlegen, wonach die Ergebnisliste gefiltert werden soll. Fehlt für eine Aktion die gewählte Festlegung, bezieht sich z. B. eine Aktion nicht auf einen Schlüssel, dann wird diese für die Aktion ignoriert. Wählen Sie einen dieser Einträge: ·         Datenbank ·         Schlüssel ·         Einstellungen ·         Operation ·         Zugriffsinformation
Filterwert	Erfassen Sie im Feld „Filterwert“ einen Wert bezogen auf die im Feld „Filtern nach“ gewählte Spalte der Ergebnisliste, um daraufhin die Ergebnisliste weiter zu optimieren. Beachten Sie bezüglich der Werte die Erläuterungen zu den Spalten der Ergebnisliste.

3.2.1.2      Aufklappbereich „Einstellung Stackframe“

Sind Stackframes im Profiling-Protokoll enthalten, dann können Sie in diesem Abfragebereich diesbezüglich Einstellungen vornehmen.

Die Felder im Einzelnen:

Feld	Erläuterung
Rubrik „Filter“
Stackframe-Information vorhanden (Checkbox)	Mithilfe dieser Funktion legen Sie fest, dass in der Ergebnisliste die Daten gemäß unterschiedlicher Stackframe-Informationen angezeigt werden.
Einschluss Filter	Legen Sie in diesem Feld fest, welche Business Objects, für die ein Stackframe im Profiling-Protokoll aufgezeichnet wurde, in die Abfrage eingeschlossen werden sollen, um die Ergebnisliste zu optimieren und die Auswertung zu spezialisieren. Mehrere Business Objects können Sie mithilfe des Rauten-Buttons vor diesem Feld erfassen. Alternativ können Sie mithilfe des Buttons „Einschluss Stackframe-Filter“ in der Symbolleiste der Ergebnisliste auch eine markierte Zeile aus der Ergebnisliste in dieses Feld übernehmen. Bei der Auswertung werden nur Stackframes berücksichtigt, bei denen mindestens ein Stacktrace-Element mindestens einer der Einschlussbedingungen genügt.
Ausschluss Filter	Legen Sie in diesem Feld fest, welche Business Objects, für die ein Stackframe im Profiling-Protokoll aufgezeichnet wurde, von der Abfrage ausgeschlossen werden sollen, um die Ergebnisliste zu optimieren und die Auswertung zu spezialisieren. Mehrere Business Objects können Sie mithilfe des Rauten-Buttons vor diesem Feld erfassen. Alternativ können Sie mithilfe des Buttons „Ausschluss Stackframe-Filter“ in der Symbolleiste der Ergebnisliste auch eine markierte Zeile aus der Ergebnisliste in dieses Feld übernehmen. Bei der Auswertung werden nur Stackframes ausgeschlossen, bei denen mindestens ein Stacktrace-Element mindestens einer der Ausschlussbedingungen genügt.
Rubrik „Aggregationseinstellungen“
Stackframe-Information verwenden (Checkbox)	Mithilfe dieser Funktion legen Sie fest, dass in der Ergebnisliste nur solche Daten angezeigt werden, für die Stackframe-Informationen aufgezeichnet wurden.
Stackframe-Information vorhanden	Mithilfe dieser Funktion legen Sie fest, dass in der Ergebnisliste die Daten gemäß unterschiedlicher Stackframe-Informationen angezeigt werden.
Stacktrace Element Einstellungen	Ein Stacktrace-Element entspricht einer Stelle im zugrunde liegenden Java-Code. In diesem Feld können Sie festlegen, wie genau bei der Auswertung unterschieden werden soll. Wählen Sie einen der folgenden Einträge: ·         Komplett Mit diesem Eintrag legen Sie fest, dass in der Ergebnisliste pro unterschiedliche Zeilennummer die Daten aufgeführt werden. ·         Javaklasse und Methode ·         Javaklasse
Anwendungscode	Legen Sie fest, wie genau im Bereich des Anwendungscodes unterschieden werden soll, um die Ergebnisliste zu optimieren. Wählen Sie einen der folgenden Einträge: ·         Keiner Der Anwendungscode wird ignoriert. ·         Übergänge Nur die Stellen werden berücksichtigt, an denen ein Übergang stattfindet, also beispielsweise vom Anwendungscode zum PGM-Code. ·         Alle Der Anwendungscode wird insgesamt berücksichtigt, inklusiver aller Übergänge.
PGM-Code	Legen Sie fest, wie genau im Bereich des PGM-Codes unterschieden werden soll, um die Ergebnisliste zu optimieren. Wählen Sie einen der folgenden Einträge: ·         Keiner Der PGM-Code wird ignoriert. ·         Übergänge Nur die Stellen werden berücksichtigt, an denen ein Übergang stattfindet, also beispielsweise vom Anwendungscode zum PGM-Code. ·         Alle Der PGM-Code wird insgesamt berücksichtigt, inklusiver aller Übergänge.
Projektspezischer Code	Legen Sie fest, wie genau im Bereich des projektspezifischen Codes unterschieden werden soll, um die Ergebnisliste zu optimieren. Wählen Sie einen der folgenden Einträge: ·         Keiner Der projektspezifische Code wird ignoriert. ·         Übergänge Nur die Stellen werden berücksichtigt, an denen ein Übergang stattfindet, also beispielsweise vom projektspezifischen Code zum Anwendungscode. ·         Alle Der projektspezifische Code wird insgesamt berücksichtigt, inklusiver aller Übergänge.
Systemcode	Legen Sie fest, wie genau im Bereich des Systemcodes unterschieden werden soll, um die Ergebnisliste zu optimieren. Wählen Sie einen der folgenden Einträge: ·         Keiner Der Systemcode wird ignoriert. ·         Übergänge Nur die Stellen werden berücksichtigt, an denen ein Übergang stattfindet, also beispielsweise vom Systemcode zum Anwendungscode. ·         Alle Der Systemcode wird insgesamt berücksichtigt, inklusiver aller Übergänge.
Maximale Tiefe	Legen Sie in diesem Feld die Anzahl an Stacktrace-Elementen eines Stackframes fest, die für die Ergebnisliste berücksichtigt werden soll.

3.2.2          Arbeitsbereich

Der Arbeitsbereich besteht aus der Ergebnisliste mit den Daten des Profiling-Protokolls. Die angezeigten Daten beziehen sich auf die im Abfragebereich festgelegten Abfragemerkmale.

Die Daten der Ergebnisliste werden unter Karteireitern angezeigt, die in folgenden Kapiteln beschrieben sind:

• Karteireiter „Resultat“
• Karteireiter „Häufigkeit“

3.2.2.1      Karteireiter „Resultat“

Wenn Sie den Karteireiter „Resultat“ am unteren Rand der Ergebnisliste auswählen, dann werden Ihnen die Resultate der aufgezeichneten Aktionen mit weiteren Auswertungsinformationen angezeigt.

Die Spalten im Einzelnen:

Spalte	Erläuterung
1.    Überschriftenzeile
Kontext	Der Ausführungskontext wird am Ende der Ergebnisliste in folgender Form angezeigt: Session-Start {Benutzer}
2.    Überschriftenzeile
Anzahl	Die Spalte enthält die Anzahl gleichartiger Ereignisse mit denselben weiteren Parametern, die in derselben Zeile angezeigt werden.
Aktionsbezeichnung	Die Spalte enthält die Bezeichnung der aufgezeichneten Aktion.
Stack vorhanden	Die Spalte liefert Ihnen die Auskunft über Stackframe-Informationen. Ist die in der Spalte enthaltene Checkbox aktiviert, dann ist für die Aktion eine Stackframe-Information vorhanden.
Datenbank	Die Spalte enthält den Namen der Datenbank, auf der die Aktion ausgeführt wurde.
Schlüssel	Die Spalte enthält den Namen eines Business-Object-Schlüssels, wenn sich die Aktion auf einen bezieht. Folgende Schlüssel können angezeigt werden: ·         PK Primary Key, der Primärschlüssel ·         SK[n] Secondary Key, der n-te Sekundärschlüssel ·         TDK Zeitabhängiger Schlüssel (time-dependent key) ·         INV Falls der verwendete Schlüssel ungültig (invalid) ist. ·         DEP Wenn ein Business Object nur deshalb gesperrt wird, weil ein zugehöriges Dependent-Objekt gesperrt wurde. Die Schlüsselinformation ist bei folgenden Aktionen vorhanden: ·         getObject ·         getObjectArray ·         Sperranforderungen Bei Sperranforderungen nur, wenn sich die Sperre auf bestimmte Instanzen bezieht.
Einstellungen	Die Spalte enthält die Abkürzungen für die Einstellungen, die für Aktionen festgelegt und aufgezeichnet wurden. Das betrifft die Aktionen des Object-Managers und die Sperranforderungen. Für andere Aktionen sind keine Einstellungen aufzuzeichnen. Weitere Informationen finden Sie in diesem Kapitel: Erläuterungen zu „Einstellungen“
Operation	Die Spalte enthält die Abkürzungen der ausgeführten Operation als Resultat der jeweiligen Aktion, die aufgezeichnet wurde. Das betrifft die Aktionen des Object-Managers und die Sperranforderungen. Weitere Informationen finden Sie in diesem Kapitel: Erläuterungen zu „Operation“
Zugriff	Die Spalte enthält Zugriffsinformationen in Abhängigkeit der aufgezeichneten Aktion. Bezieht sich eine Aktion auf ein Business Object und wurde der Zugriff darauf aufgezeichnet, dann enthält die Spalte den vollqualifizierten Namen des betroffenen Business Objects. Wurde eine Sperranfrage ausgeführt, dann ist diese in den meisten Fällen auch auf ein Business Object bezogen, sodass dafür ebenfalls der vollqualifizierte Name des betroffenen Business Objects angezeigt wird. Wurde alternativ eine programmierte, logische Sperre aufgezeichnet, dann wird diese Information angezeigt. Die Spalte enthält bei einem ResultSet oder einem direkten Datenbankzugriff den entsprechenden OQL- bzw. SQL-String.
3.    Überschriftenzeile
Position	Ist eine Stackframe-Information vorhanden, dann enthält diese Spalte die Position des Stacktrace-Elements im zugrunde liegenden Java-Code. Die Anzeige ist abhängig von der gewählten Abfrage-Einstellung für die Auswertung des Stackframes. Folgendes kann angezeigt werden: ·         Java-Klasse, Methode und Zeilennummer ·         Java-Klasse und Methode ·         Java-Klasse

Buttons der Listen-Symbolleiste

Die Ergebnisliste hat eine Symbolleiste, die u. a. Buttons für die Übernahme ausgewählter Daten in die Abfragemerkmale oder zum Kopieren von Daten enthält.

• Aktualisieren

Die Daten der Profiling-Protokolldatei werden entsprechend der Abfragemerkmale angezeigt.

• Einschluss Stackframe-Filter

Mit diesem Button können Sie vereinfacht ein Stacktrace-Element als abzufragendes Stackframe-Element der Abfrage hinzufügen. Dazu markieren Sie ein Stacktrace-Element in der Ergebnisliste und drücken danach diesen Button. Das gewählte Element wird daraufhin im Aufklappbereich „Einstellung Stackframe“ dem Abfragefeld „Einschluss Filter“ als Abfragemerkmal hinzugefügt. Drücken Sie im Anschluss bei Bedarf den Aktualisieren-Button in der Listen-Symbolleiste, um die Daten in der Ergebnisliste danach zu aktualisieren. Berücksichtigt werden entsprechend der Abfrageänderung nur Stackframes, innerhalb derer das hinzugefügte Stacktrace-Element auftritt.

• Ausschluss Stackframe-Filter

Mit diesem Button können Sie vereinfacht ein Stacktrace-Element als abzufragendes Stackframe-Element der Abfrage hinzufügen. Dazu markieren Sie ein Stacktrace-Element in der Ergebnisliste und drücken danach diesen Button. Das gewählte Element wird daraufhin im Aufklappbereich „Einstellung Stackframe“ dem Abfragefeld „Ausschluss Filter“ als Abfragemerkmal hinzugefügt. Drücken Sie im Anschluss bei Bedarf den Aktualisieren-Button in der Listen-Symbolleiste, um die Daten in der Ergebnisliste danach zu aktualisieren. Berücksichtigt werden entsprechend der Abfrageänderung nur Stackframes, innerhalb derer das hinzugefügte Stacktrace-Element nicht auftritt.

• Stackframe

Sind Stackframes in der Ergebnisliste vorhanden, dann können Sie mithilfe dieses Buttons die Stackframes ein- bzw. ausblenden.

• Kopieren

Sind Stackframes in der Ergebnisliste vorhanden, dann können Sie mithilfe dieses Buttons eine zuvor markierte Stackframe-Information in die Zwischenablage kopieren.

3.2.2.2      Karteireiter „Häufigkeit“

Wenn Sie den Karteireiter „Häufigkeit“ am unteren Rand der Ergebnisliste auswählen, dann werden Ihnen die Aufzeichnungen zu Stackframes bzw. die darin verwendeten Stacktrace-Elemente angezeigt. Dies ist insbesondere dann interessant, wenn Sie z. B. besonders häufig verwendete Code-Stellen identifizieren möchten.

Die Spalten im Einzelnen:

Spalte	Erläuterung
Häufigkeit	Die Spalte enthält die Anzahl der Code-Stellen, an denen das Stacktrace-Element in den jeweiligen Stackframes auftritt.
Eingehende Pfade	Die Spalte enthält die Anzahl an eingehenden Pfaden des Stacktrace-Elements.
Ausgehende Pfade	Die Spalte enthält die Anzahl an ausgehenden Pfaden des Stacktrace-Elements.
Position	Ist eine Stackframe-Information vorhanden, dann enthält diese Spalte die Position des Stacktrace-Elements im zugrunde liegenden Java-Code. Die Anzeige ist abhängig von der gewählten Abfrage-Einstellung für die Auswertung des Stackframes. Folgendes kann angezeigt werden: ·         Java-Klasse, Methode und Zeilennummer ·         Java-Klasse und Methode ·         Java-Klasse

Buttons der Listen-Symbolleiste

Die Ergebnisliste hat eine Symbolleiste, die u. a. Buttons für die Übernahme ausgewählter Daten in die Abfragemerkmale enthält.

• Aktualisieren

Die Daten der Profiling-Protokolldatei werden entsprechend der Abfragemerkmale angezeigt.

• Einschluss Stackframe-Filter

Mit diesem Button können Sie vereinfacht ein Stacktrace-Element als abzufragendes Stackframe-Element der Abfrage hinzufügen. Dazu markieren Sie ein Stacktrace-Element in der Ergebnisliste und drücken danach diesen Button. Das gewählte Element wird daraufhin im Aufklappbereich „Einstellung Stackframe“ dem Abfragefeld „Einschluss Filter“ als Abfragemerkmal hinzugefügt. Drücken Sie im Anschluss bei Bedarf den Aktualisieren-Button in der Listen-Symbolleiste, um die Daten in der Ergebnisliste danach zu aktualisieren. Berücksichtigt werden entsprechend der Abfrageänderung nur Stackframes, innerhalb derer das hinzugefügte Stacktrace-Element auftritt.

• Ausschluss Stackframe-Filter

Mit diesem Button können Sie vereinfacht ein Stacktrace-Element als abzufragendes Stackframe-Element der Abfrage hinzufügen. Dazu markieren Sie ein Stacktrace-Element in der Ergebnisliste und drücken danach diesen Button. Das gewählte Element wird daraufhin im Aufklappbereich „Einstellung Stackframe“ dem Abfragefeld „Ausschluss Filter“ als Abfragemerkmal hinzugefügt. Drücken Sie im Anschluss bei Bedarf den Aktualisieren-Button in der Listen-Symbolleiste, um die Daten in der Ergebnisliste danach zu aktualisieren. Berücksichtigt werden entsprechend der Abfrageänderung nur Stackframes, innerhalb derer das hinzugefügte Stacktrace-Element nicht auftritt.

3.2.2.3      Erläuterungen zu „Einstellungen“

Dieses Kapitel enthält Erläuterungen zu den Einträgen der Spalte „Einstellungen“, die von der jeweiligen Aktion abhängen. Beachten Sie folgende Kapitel:

• ObjectManager
• Sperranforderung

ObjectManager

Die Einstellung bei Zugriffen über den ObjectManager beziehen sich auf die beim jeweiligen Aufruf gesetzten Zugriffsmodi („flags“). Weitere Informationen zu den Zugriffsmodi finden Sie in folgender Dokumentation: Persistenzdienst, Kapitel „Zugriffsmodi“

Folgende Kürzel für Flags bestehen:

• R

Aktion wurde mit dem Flag READ aufgerufen.

• RU

Aktion wurde mit dem Flag READ_UPDATE aufgerufen.

• RW

Aktion wurde mit dem Flag READ_WRITE aufgerufen.

• INS

Aktion wurde mit dem Flag INSERT aufgerufen.

• RP

Aktion wurde mit dem Flag READ_PARALLEL aufgerufen.

• RR

Aktion wurde mit dem Flag READ_REPEATABLE aufgerufen.

• BC

Aktion wurde mit dem Flag BYPASS_CACHE aufgerufen.

• CO

Aktion wurde mit dem Flag CACHE_ONLY aufgerufen.

• DL

Aktion wurde mit dem Flag DISABLE_LOCKING aufgerufen.

Sperranforderung

Die Einstellung bei Sperranforderungen bezieht sich auf verschiedene Sperr-Typen. Weitere Informationen zu Sperr-Typen finden Sie in folgender Dokumentation: Sperrverwaltung

Folgende Kürzel für Sperranforderungen bestehen:

• I

Die Sperranfrage bezieht sich für eine bestimmte Instanz.

• T

Die Sperranfrage bezieht sich auf die gesamte Tabelle.

• S

Die Sperranfrage bezieht sich auf das System, d. h. auf alle Datenbanken des Systems, auf denen die Tabelle besteht.

• L

Die Sperranfrage ist eine sogenannte „logische“ Sperre. Sie wurde programmatisch erzeugt.

• R

Eine Lesesperre wurde angefragt.

• W

Eine Schreibsperre wurde angefordert.

• U

Eine Verwendungssperre („use“) wurde angefordert.

• E

Eine exklusive Sperre wurde angefordert.

3.2.2.4      Erläuterungen zu „Operation“

Dieses Kapitel enthält Erläuterungen zu den Einträgen der Spalte „Operation“, die von der jeweiligen Aktion abhängen. Beachten Sie folgende Kapitel:

• ObjectManger
• TransactionManager

ObjectManger

Die Operationen bei Zugriffen über den ObjectManager beziehen sich auf die beim jeweiligen Aufruf gesetzten Zugriffsmodi („flags“). Weitere Informationen zu den Zugriffsmodi finden Sie in folgender Dokumentation: Persistenzdienst, Kapitel „Zugriffsmodi“

Folgende Zugriffsmodi können angezeigt werden:

• LA (lock acquired)

Beim Zugriff wurde auch eine Sperre angefordert.

• TC (transaction cache hit)

Das Objekt konnte aus dem Transaction-Cache gelesen werden.

• SC (shared cache hit)

Das Objekt konnte aus dem Shared-Cache gelesen werden.

• DB (database access)

Das Objekt wurde aus der Datenbank gelesen.

• MS (miss, object not found)

Das Objekt wurde nicht gefunden.

• DB[n,m]

Tritt nur bei ObjectArray-Anfragen auf. Insgesamt wurden „m“ Objekte angefragt, davon wurden „n“ Objekte von der Datenbank gelesen.

TransactionManager

• DMJ

„Disable Modification Journal“: Ins Modifikationsjournal wurden keine Einträge geschrieben.

• DTL

„Disable Transfer List“: Für die Transferlisten wurden keine Einträge geschrieben.

• DUI

„Disable Update Info“: Die Update-Information wird nicht aktualisiert, wenn ein Objekt geschrieben wird.

• OC

„Ordered Commit“: Die Objekte wurden in genau der Reihenfolge geschrieben, mit der sie per „putObject“ für die Änderung registriert wurden.

3.2.2.5      Erläuterungen zu „Sperranforderung“

Dieses Kapitel enthält Erläuterungen zu den Einträgen der Spalte „Sperranforderung“, die von der jeweiligen Aktion abhängen.

Die Einträge im Einzelnen:

• G

Die angefordert Sperre wurde gewährt.

• N

Die angeforderte Sperre bestand schon.

• T

Die Sperranforderung führte zu einer Zeitüberschreitung (Timeout).

• EX

Die Sperranforderung führte zu einer Exception. Eine Exception deutet auf einen Programmierfehler hin.

3.2.3          Ansichten in der Standard-Symbolleiste: Aggregationsebenen

In der Standard-Symbolleiste der Anwendung finden Sie folgende Ansichten:

• Session
• Anwendung
• Transaktion

Die Ansichten sind Aggregationsebenen, nach denen die Auswertung erfolgen kann. Die Aggregationsebene bestimmt den obersten Kontext, für den die Aktionen gezählt werden.

Die Aggregationsebenen im Einzelnen:

• Session

Die Aktionen werden pro gewählte Session aggregiert, d. h. sie werden kontextübergreifend gezählt, also über Anwendungen, Transaktionen und Anwendungsfunktionen hinweg.

Wurde im Abfragebereich im Feld „Anwendung“ ein Anwendungsname angegeben, dann werden nur Aktionen aus den Anwendungen berücksichtigt, deren Namen zum angegebenen Namen passen. Dasselbe gilt für Anwendungsfunktionen, wird allerdings eine Anwendung nicht beachtet, dann werden die untergeordneten Funktionen ebenfalls ignoriert.

Diese Aggregationsebene ermöglicht, die innerhalb einer Anwendungsfunktion ausgeführten Aktionen über mehrere Aufrufe dieser Funktion hinweg zu zählen. Damit lassen sich sehr einfach die Gesamtkosten einer Funktion in einer Anwendung bestimmen.

• Anwendung

Die Aktionen werden pro Anwendung in der gewählten Session aggregiert, d. h. sie werden kontextübergreifend nur über untergeordnete Anwendungsfunktionen aggregiert, aber nicht über Anwendungen hinweg. Nach dem Ergebnis der Aggregation für die gesamte Anwendung werden die jeweiligen Aggregationsergebnisse für die untergeordneten Funktionen aufgeführt.

Diese Aggregationsebene ermöglicht, sich sehr einfach einen Überblick über die Gesamtanzahl von Aktionsaufrufen in einer Anwendung zu verschaffen. Die Aktionsaufrufe werden außerdem nochmals nach Auftreten in den Anwendungsfunktionen aufgeschlüsselt.

• Transaktion

Die Aktionen werden pro Transaktion in der gewählten Session aggregiert, d. h. sie werden pro Transaktion gezählt, andere Kontexte werden nicht beachtet.

3.2.4          Andockbares Fenster „Sessions“

Das andockbare Fenster „Sessions“ dient dazu, sich einen Überblick über die Daten eines Profiling-Protokolls zu verschaffen. Es stellt die Sessions, Anwendungen und Funktionen hierarchisch als Baum dar. Eine Session kann ein oder mehrere Anwendungen enthalten, denen Anwendungsfunktionen zugeordnet sein können.

Besteht mehr als eine Session in einem Profiling-Protokoll, kann man über dieses Fenster die auszuwertende Session auswählen, deren Name wird dann in das Feld „Session“ im Abfragebereich übernommen. Genauso kann mit Anwendungen und Anwendungsfunktionen verfahren werden.

3.3               Vorgehensweise: Profiling-Protokolle für anwendungsbezogene Aktionen

Wie im Dokument „Leistungsoptimierung“ beschrieben, sollte eine Aktion, d. h. ein Roundtrip, in einer interaktiven Anwendung im Normalfall maximal 0,5 Sekunden dauern. Wenn eine Aktion länger dauert, dann fällt dem Benutzer die Wartezeit negativ auf. Bei Aktionen, die der Benutzer besonders häufig ausführt, wie beispielsweise das Erfassen einer neuen Vertriebsauftragsposition, ist besonders wichtig, dass diese Aktionen möglichst kurz laufen. Die Erfassung von Vertriebsauftragspositionen ist für fast alle Kunden besonders wichtig.

Mithilfe der Profiling-Protokolle können Sie Ursachen finden, weshalb einige Aktionen lange oder zu lange dauern.

Hinweis:

Aktivieren Sie keinesfalls das Profiling auf einem Application-Server, auf dem Benutzer produktiv arbeiten. Verwenden Sie auf Produktivsystemen immer einen speziellen Application-Server, auf dem nur das Profiling aktiviert ist. Außer auf Entwicklungssystemen benötigen Sie eine spezielle administrative Fähigkeit. Siehe dazu dieses Kapitel: Spezielle Fähigkeiten

Anleitung

Die Vorgehensweise, um beispielsweise das Übernehmen einer Vertriebsauftragsposition aufzuzeichnen, ist wie folgt:

1. Aktivieren Sie das Profiling und setzen Sie die Aufzeichnung von Aktionen sofort aus:

wrkprf -start:C:\orderdetail.dat -pause

2. Melden Sie sich am entsprechenden ERP-System-Application-Server an.
3. Öffnen Sie die Anwendung „Vertriebsaufträge“.
4. Erfassen Sie einen neuen Vertriebsauftrag.
5. Erfassen Sie eine neue Position.
6. Aktivieren Sie die Aufzeichnung von Aktionen im Profiling-Protokoll:

wrkprf -resume

7. Übernehmen Sie die Position.
8. Beenden Sie die Aufzeichnung des Profiling-Protokolls:

wrkprf -stop

9. Werten Sie das Profiling-Protokoll mit der Anwendung „Profiling-Protokolle abfragen“ aus.

Ursachen

Datenbankzugriffe sind erfahrungsgemäß langwierige Operationen. Die Anzahl und die Komplexität der Datenbankzugriffe sind entscheidend für die Dauer eines Roundtrips.

Ursachen für Datenbankanfragen, die zu vermeiden sind, können unter anderem die folgenden Aktionen sein:

Operation	Erläuterung
getObject	Wenn für die Aktion „getObject“ die Operation „DB“ aufgezeichnet wurde, dann hat ein Datenbankzugriff stattgefunden. Wird für die Operation nicht „DB“ angezeigt, dann war für diesen Zugriff keine Datenbankanfrage erforderlich. Die Zeit für diesen Zugriff kann daher vernachlässigt werden. Hat jedoch die Datenbankanfrage kein Objekt gefunden, dann wird die Operation „MS“ angezeigt. Wenn bei vielen Zugriffen die Operation „MS“ aufgezeichnet wurde, dann ist dies ein Hinweis auf eine ungünstige Programmierung. Eine hohe Anzahl an Einzelzugriffen auf das gleiche Business Object mit „getObject“ zeugt von fehlender Blockorientierung in der verwendeten Operation. Bei Lesezugriffen auf Stammdaten beachten Sie, dass diese bei einem gefüllten Cache voraussichtlich keinen Datenbankzugriff benötigen.
getObjectArray	Wird für die Aktion „getObjectArray“ die Operation „#db=n“ aufgezeichnet, dann wird die Anzahl der Objekte aufgezeichnet, die von der Datenbank geöffnet wurden. Wenn n gleich 0 ist, dann hat kein Datenbankzugriff stattgefunden.
getObjectIterator	Jede Verwendung eines Object-Iterators hat einen oder mehrere Datenbankzugriffe zur Folge. Wenn das Business Object, das im Object-Iterator gelesen wird, mit der Cache-Strategie „least recently used“ (LRU) geführt wird, dann werden in einer Datenbankanfrage die Primärschlüssel des Objekts gelesen. Die Business-Object-Instanzen werden in Blöcken mit 16 Objekten mit „getObjectArray“ gelesen.
getResultSet	Jede Verwendung eines „ResultSets“ hat genau einen Datenbankzugriff zur Folge.

Bei Problemen mit der Leistungsfähigkeit ist sinnvoll, in einer ersten Aufzeichnung erst einmal besonders häufige Aktionen zu identifizieren. Dies erlaubt Ihnen für eine zweite Aufzeichnung die Stackframe-Informationen zu bestimmen. Beispielsweise stellen Sie bei der Auswertung der ersten Aufzeichnung fest, dass ein Business Object häufiger geöffnet wird als Sie angenommen hätten. Dann geben Sie dieses Business Object für die zweite Aufzeichnung als Stackframe-Bedingung an. Entsprechend wird z. B. für jedes Öffnen bezogen auf dieses Business Object die entsprechende Stackframe-Information aufgezeichnet. So können Sie problematische Code-Stellen identifizieren und ggf. optimieren. Die Ausführungszeiten der Datenbankanfragen können über die Leistungsmonitore bestimmt werden.

Weitere Informationen finden Sie im Dokument „Leistungsmonitore“.

Im Dokument „Leistungsoptimierung“ ist im Kapitel „Interaktive Anwendungen“ beschrieben, wie viele Datenbankzugriffe in einem Roundtrip erlaubt sind.

4                     Berechtigungen

Berechtigungen können sowohl mithilfe der Berechtigungsrollen als auch durch die Zuordnung einer Organisation vergeben werden. Das Berechtigungskonzept können Sie in der Technischen Dokumentation „Berechtigungen“ nachlesen.

4.1               Spezielle Fähigkeiten

Für die Anwendung „Profiling-Protokolle abfragen“ besteht folgende spezielle Fähigkeit, die sich auf Aktionen bezieht. Für diese Fähigkeit können Sie in der Anwendung „Berechtigungsrollen“ Berechtigungen vergeben.

Profiling Untersuchungen ausführen

com.cisag.sys.kernel.Profiling

Außer auf Entwicklungssystemen benötigen Sie diese administrative Fähigkeit, um das Profiling ausführen zu können.

4.2               Organisations-Zuordnungen

Für die Anwendung „Profiling-Protokolle abfragen“ ist eine Organisations-Zuordnung nicht erforderlich.

4.3               Besonderheiten

Für die Anwendung „Profiling-Protokolle abfragen“ bestehen keine Besonderheiten.

4.4               Berechtigungen für Geschäftspartner

Die Anwendung „Profiling-Protokolle abfragen“ ist für Geschäftspartner nicht freigegeben.