test

Sun Identity Manager 8.1 Versionshinweise

Übersicht

Dieser Abschnitt enthält eine Übersicht der Leistungsmerkmale und Funktionalität des Identity Manager-Profilers. Die Informationen sind wie folgt unterteilt:

Hauptfunktionen

Mit dem Profiler können Sie folgende Funktionen ausführen:

Wie findet und verwaltet der Profiler Quellcode

In diesem Abschnitt wird beschrieben, wie der Profiler Quellcode für die folgenden Identity Manager-Objekte findet und verwaltet:

Tipp –

In der Aufrufhierarchie- bzw. Hotspot-Ansicht können Sie auf einen Knoten, der einer Java-Methode, einem Arbeitsablauf, einem Formular, einer Regel oder einem XPRESS-Objekt entspricht, doppelklicken.

Für Formulare, Arbeitsabläufe, Regeln und XPRESS-Objekte

Wenn Sie mit dem Profiler einen Snapshot erstellen, evaluiert der Server alle Profilingdaten und findet heraus, von welchem Quellcode die betreffenden Daten abhängen. Der Server ruft dann diesen Quellcode aus dem Repository ab und fügt ihn in den Snapshot ein. Deswegen können Sie sicher sein, dass die in einem Snapshot angezeigten Identity Manager-Objekte auch wirklich den Zustand besitzen, den sie während der Erstellung des Snapshot einnahmen.

Dieser Prozess erhöht zwar die Snapshotgröße, die Quellcodegröße beträgt aber nur einen Bruchteil der Gesamtobjektgröße. So können Sie Snapshots an den Technischen Support von Sun senden, ohne einzelne Dateien schicken zu müssen.

Für Java-Quellen

Wenn Sie einen Snapshot von Java-Quellcode erstellen, lädt der Client den Snapshot herunter und sucht dann in diesem Snapshot alle referenzierten Java-Quellen aus dem Projekt heraus. Beim Speichern des Snapshots komprimiert und archiviert der Client den Quellcode und hängt ihn an das Ende des Snapshots an.

Wenn Sie dann den Snapshot anzeigen und zum Java-Quellcode gehen, überprüft der Client zunächst den Inhalt des Snapshots. Wenn der Client den Inhalt dort nicht finden kann, überprüft er den Projektinhalt. Dieser Vorgang ermöglicht das Senden eines Snapshots mit Profiling-Daten aus benutzerspezifischem Java-Code und Identity Manager-Code.

Hinweis –

Bei Snapshots aus Java-Quellcode kann nicht vorausgesetzt werden, dass die der Code mit dem Server auf dem aktuellsten Stand bzw. stets verfügbar ist.

Interpretationshinweise zu den Statistiken

Die folgenden Abschnitte enthalten Informationen, die bei der Auswertung der vom Profiler ermittelten Ergebnisse zu berücksichtigen sind.

Berechnung der Eigenausführungszeit

Zur Berechnungen der Eigenausführungszeit eines Root-Knotens subtrahiert der Profiler die Ausführungszeiten aller vom Root-Knoten aufgerufenen Routinen von der Gesamtausführungszeit des Knotens ab.

Deswegen fließt die Ausführungszeit eines uninstrumentierten, vom Root-Knoten aufgerufenen Knotens in die Eigenausführungszeit des Root-Knotens ein Wenn die Eigenausführungszeit eines Root-Knotens relativ groß ist, sollten sie der Ursache unbedingt nachgehen. Es könnte beispielsweise sein, dass Sie nicht die passenden Methoden analysieren und deswegen an der falschen Stelle suchen.

Nehmen wir z. B. an, dass Methode-A Methode-B aufruft.

Die Ausführungszeit von Methode-A beträgt insgesamt 10-s (dies schließt den Aufruf von B ein) und der Aufruf von B dauert insgesamt 10-s.

Wenn sowohl Methode-A als auch Methode-B instrumentiert sind, wird dies im Aufrufstack festgehalten. Sie sehen, dass Methode-A eine Eigenausführungszeit von 0-s und B von 10-s besitzt. Das heißt, die gesamten 10-Sekunden wurden in Methode-B verbracht). Wenn B jedoch nicht instrumentiert ist, sehen Sie nur, dass der Aufruf von Methode-A 10-s dauert und die Eigenausführungszeit von Methode-A 10-s beträgt. So kann es sein, dass Sie annehmen, dass das Problem statt in Methode-B in Methode-A liegt.

Ihnen fällt vielleicht auf, dass die Eigenausführungszeiten von JSPs während der Erstcompilierung sehr hoch sind. Wenn Sie die erfassten Ergebnisse löschen und die Seite dann erneut anzeigen, ist der Wert für die Eigenausführungszeit bedeutend niedriger.

Konstruktoraufrufe

Wegen vorhandener Einschränkungen bei der Java-Instrumentierungsstrategie erscheinen Erstaufrufe to this() oder super() auf der gleichen Aufrufebene wie der Konstruktor statt darunter. Hierzu ein Beispiel:


class A
{
   public A()
   {
      this(0);
   }
   public A(int i)
   {
   }
}

and:

class B
{
   public static void test()
   {
      new A();
   }
}
The call tree will look like this:
B.test()
   -A.<init>(int)
   -A.<init>()
Rather than this:
B.test()
   -A.<init>()
      -A.<init>(int)

Dämon-Threads

Lassen Sie sich nicht von einer scheinbar langen Zeit verwirren, die in Dämon-Threads von Identity Manager (z.-B. ReconTask.WorkerThread.run() oder TaskThread.WorkerThread.run()) verbracht wurde. Die meiste Zeit hier wird im Leerlauf, d.-h. mit dem Warten auf Ereignisse verbracht. Sie müssen diese Aufrufe näher untersuchen, um zu sehen, wieviel Zeit in solchen Threads beim eigentlichen Auftreten eines Ereignisses verbracht wird.