En esta sección se describen las características y la funcionalidad del analizador de Identity Manager. La información se ha dividido como sigue:
Puede utilizar el analizador para:
Crear “instantáneas” de los datos analizados.
Una instantánea es el resultado acumulativo de los análisis desde la última vez que se restablecieron todos los resultados de análisis recogidos.
Los resultados de la instantánea pueden verse en cuatro vistas de datos distintas:
Vista de llamadas en árbol proporciona una tabla de árbol con el control del tiempo de llamada y el recuento de invocaciones en todo el sistema.
Vista de zonas activas ofrece una lista lineal de nodos con los controles acumulados de tiempo de llamadas, independientemente del elemento principal.
Vista de retroseguimientos proporciona una pila de llamadas invertida con todas las cadenas de llamada desde las que se ha llamado el nodo (denominado nodo raíz).
Vista de receptores de llamadas muestra un árbol de llamadas agregadas del nodo raíz, cualquiera que sea la cadena principal.
Especificar qué tipo de información se incluye en la instantánea:
Puede incluir cada elemento del formulario, flujo de trabajo y XPRESS o restringir el contenido a un conjunto determinado de elementos.
Puede elegir métodos específicos y constructores de Java para incluir o excluir de la instrumentación. Es posible instrumentar clases de Identity Manager y clases personalizadas.
Gestionar las instantáneas del proyecto así.
Guardar la instantánea en el directorio nbproject/private/idm-profiler del proyecto o en una ubicación arbitraria externa al proyecto.
Puede ver una lista de todas las instantáneas guardadas en la sección Saved Snapshots de la vista del analizador de IDM.
Abrir instantáneas desde el proyecto o cargarlas desde una ubicación arbitraria externa.
Borrar instantáneas.
Buscar nodos específicos por nombre.
En esta sección se explica cómo el analizador busca y gestiona el origen de los siguientes objetos de Identity Manager:
En las vistas de llamadas en árbol o de zonas activas, puede hacer doble clic sobre cualquier nodo que corresponda a un método Java, flujo de trabajo, formulario, regla o XPRESS para ver el origen de ese nodo.
Cuando se toma una instantánea con el analizador, el servidor evalúa todos los datos del análisis y averigua de qué orígenes dependen. A continuación, el servidor recupera todos esos orígenes del repositorio y los incluye en la instantánea. Por tanto, puede tener la certeza de que los objetos de Identity Manager mostrados en la instantánea reflejan con exactitud el punto en que se ha capturado ésta.
Este proceso aumenta el tamaño de la instantánea, pero el tamaño del origen es una fracción relativamente pequeña del tamaño total. En consecuencia, puede enviar una instantánea al servicio de asistencia al cliente de Sun sin necesidad de remitir los archivos de origen por separado.
Cuando se toma una instantánea de origen Java, el cliente la descarga y luego la examina para capturar todos los orígenes Java referenciados del proyecto. Al guardar la instantánea, el cliente aplica zip a los orígenes y los anexa al final de la instantánea.
Después, cuando se visualiza la instantánea y se accede al origen Java, el cliente comprueba primero el contenido de la instantánea. Si no lo encuentra, comprueba el contenido del proyecto. Este proceso permite enviar una instantánea que contenga todos los datos del análisis, tanto del código Java personalizado como del código de Identity Manager.
En una instantánea con origen Java no se debe asumir que el origen está actualizado con el servidor ni que siempre está disponible.
En las secciones siguientes se incluye información que conviene tener en cuenta al evaluar los resultados del analizador:
Para calcular la estadística del tiempo propio de un nodo raíz, el analizador resta los tiempos de todos los nodos secundarios al tiempo total del nodo raíz.
Por tanto, el tiempo de un nodo secundario no instrumentado se refleja en el tiempo propio del nodo raíz. Si un nodo raíz tiene un tiempo propio considerable, conviene indagar la razón. Quizá no haya instrumentado los métodos adecuados y, por tanto, no esté usando el lugar correcto.
Por ejemplo, supongamos que el método A llama al método B.
El método A tarda un total de 10 segundos (tiempo que incluye la llamada a B) y la llamada a B tarda un total de 10 segundos.
Si están instrumentados A y B, la pila de llamadas refleja dicha información. Observará que A tiene un tiempo propio de 0 segundos y que B tiene un tiempo propio de 10 segundos (10 segundos invertidos realmente en B). Sin embargo, si B no está instrumentado, sólo observará que la llamada a A dura 10 segundos y que el tiempo propio de A es 10 segundos. En consecuencia, tal vez asuma que el problema reside directamente en A, no en B.
En concreto, se podrían apreciar largos tiempos propios durante la compilación inicial de JSP. Si restablece los resultados recogidos y vuelve a presentar la página, el tiempo propio será muy inferior.
Dadas las limitaciones de la estrategia de instrumentación de Java, las llamadas iniciales a this() o super() aparecen como llamadas del mismo nivel para la llamada de constructor y no como llamadas secundarias. Consulte el ejemplo siguiente:
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) |
No se confunda con la aparente gran cantidad de tiempo invertida en diversos threads de daemon de Identity Manager, como ReconTask.WorkerThread.run() o TaskThread.WorkerThread.run(). La mayor parte de este tiempo es inactivo, en espera de eventos. Hay que explorar estos rastros para constatar cuánto tiempo se tarda realmente al procesar un evento.