¿Por qué debe utilizarse request metrics?

Request Metrics es una herramienta que permite realizar un seguimiento de transacciones individuales, registrando el tiempo de proceso en cada uno de los componentes principales de WebSphere Application Server.

Antes de empezar

La información rastreada por request metrics se puede guardar en archivos de anotaciones cronológicas para una recuperación y análisis posterior, ser enviar a los agentes ARM (Application Response Measurement), o ambas cosas.
A medida que la transacción fluye en el sistema, request metrics agrega información adicional, de modo que se puede establecer una correlación de los registros de anotaciones cronológicas de cada componente, creando una imagen completa de esa transacción. El resultado es similar al siguiente ejemplo:
HTTP request/trade/scenario ------------------------------> 172 ms
     Servlet/trade/scenario  -----------------------------> 130 ms
         EJB TradeEJB.getAccountData --------------------->  38 ms
              JDBC select -------------------------------->   7 ms 

Flujo de transacción

Este flujo de transacción con los tiempos de respuesta asociados puede ayudarle a centrarse en las áreas del problema de rendimiento y depurar problemas de restricción de recursos. Por ejemplo, el flujo puede ayudar a determinar si una transacción invierte la mayoría de su tiempo en el plug-in de servidor web, el contenedor web, el contenedor de EJB (Enterprise JavaBeans) o la base de datos del programa de fondo. El tiempo de respuesta recopilado para cada nivel incluye el tiempo invertido en ese nivel y en los niveles inferiores. Por ejemplo, el tiempo de respuesta del servlet, que son 130 milisegundos, también incluye 38 milisegundos de los enterprise beans y de JDBC (Java™ Database Connectivity). Por lo tanto, se pueden atribuir 92 ms al proceso del servlet.

Request metrics realiza un seguimiento del tiempo de respuesta para una transacción determinada. Puesto que request metrics realiza el seguimiento de transacciones individuales, el uso de esta herramienta conlleva algunas implicaciones de rendimiento en el sistema. No obstante, esta función puede mitigarse mediante el uso de las funciones de filtrado de solicitudes.

Por ejemplo, las utilidades pueden introducir transacciones sintéticas. Request Metrics puede realizar entonces un seguimiento del tiempo de respuesta dentro del entorno de WebSphere Application Server para dichas transacciones. Una transacción sintética es una transacción que los administradores introducen en el sistema para emplear un método proactivo para probar el rendimiento del sistema. Esta información ayuda a los administradores a ajustar el rendimiento del sitio web y a tomar acciones correctivas. Por consiguiente, la información proporcionada por request metrics puede utilizarse como mecanismo de alerta para detectar cuándo el rendimiento de un tipo de solicitud en particular sobrepasa los umbrales aceptables. El mecanismo de filtro dentro de request metrics se puede utilizar para centrarse en transacciones sintéticas específicas y puede ayudar a optimizar el rendimiento de este escenario.

Acerca de esta tarea

Una vez que se han aislado las área que presentan problemas, puede utilizar el mecanismo de filtrado de request metrics para centrarse específicamente en dichas áreas. Por ejemplo, si ha aislado un problema en un serlvet o en un método EJB determinado, utilice los algoritmos URI (Identificador de recursos uniforme) o el filtro EJB para habilitar solamente la instrumentación para el servlet o el método EJB. El mecanismo de filtrado da soporte a un análisis de rendimiento más concreto.

Se da soporte a cinco tipos de filtros:
  • Filtro de IP de origen
  • Filtro de URI
  • Filtro de nombres de método EJB
  • Filtro de parámetros JMS
  • Filtro de parámetros de servicios Web

Cuando el filtro está habilitado, sólo aquellas solicitudes que coincidan con el filtro generarán datos de request metrics, crearán registros de anotaciones cronológicas, llamarán a las interfaces ARM o realizarán todas estas actividades. Puede introducir trabajo en un sistema en ejecución (en concreto para generar información de rastreo) para evaluar el rendimiento de tipos específicos de solicitudes en el contexto de una carga normal, ignorando las solicitudes de otros orígenes que puedan estar llegando al sistema.

Nota: Los filtros sólo pueden aplicarse en el punto en que la solicitud entra primero en WebSphere Application Server.

Procedimiento

Ejemplo

Aprenda a utilizar Request metrics mediante el ejemplo siguiente.

En este ejemplo, el servlet HitCount y el enterprise bean Increment se despliegan en dos procesos de servidor de aplicaciones distintos. Como se muestra en el diagrama siguiente, el nivel de contenedor web y los niveles de contenedor de EJB (Enterprise JavaBeans) se ejecutan en dos servidores de aplicaciones distintos. Para realizar esta configuración, instale WebSphere Application Server, Network Deployment.

Ejemplo

Supongamos que el nivel de servidor web y de contenedor web se ejecutan ambos en la máquina 192.168.0.1 y el nivel de contenedor de EJB (Enterprise JavaBeans) se ejecuta en una segunda máquina 192.168.0.2. Las solicitudes del cliente se pueden enviar desde otra máquina: 192.168.0.3, por ejemplo u otras máquinas.

Para ilustrar el uso del filtro de IP de origen, se define y habilita un filtro de IP de origen (192.168.0.3). Puede rastrear solicitudes que se originan en la máquina 192.168.0.3 a través de http://192.168.0.1/hitcount?selection=EJB&lookup=GBL&trans=CMT. No obstante, las solicitudes procedentes de cualquier otra máquina no se rastrearán ya que la dirección IP de origen no estará en la lista de filtros.

Simplemente creando un filtro de IP de origen, cualquier solicitud que proceda de esta dirección IP de origen se rastreará. Esta herramienta resulta eficaz para localizar los problemas de rendimiento en sistemas bajo carga. Si la carga normal procede de otras direcciones IP, las solicitudes no se rastrearán. Mediante la dirección IP de origen definida para generar solicitudes, puede ver los atascos de rendimiento en los diferentes saltos, comparando los registros de rastreo del sistema cargado con los registros de rastreo de una ejecución no cargada. Esto permite dedicar los esfuerzos de ajuste al nodo correcto y realizar el proceso dentro de un entorno de despliegue complejo.

Asegúrese de que Request Metrics esté activado utilizando la consola administrativa. Asimismo, asegúrese de que el nivel de rastreo se establezca como mínimo en hops (escribiendo rastreos de solicitudes en los límites del proceso). Con la configuración indicada anteriormente envíe una solicitud http://192.168.0.1/hitcount?selection=EJB&lookup=GBL&trans=CMT a través del servlet HitCount desde la máquina 192.168.0.3.

En este ejemplo, se generan como mínimo tres registros de rastreo:
  • Aparece un registro de rastreo del plug-in de servidor web en el archivo de anotaciones cronológicas del plug-in (la ubicación predeterminada es raíz_plugin/logs/servidor_web/http_plugin.log) en la máquina 192.168.0.1.
  • [AIX Solaris HP-UX Linux Windows][z/OS]Aparece un registro de rastreo para el servlet en el archivo de anotaciones cronológicas del servidor de aplicaciones (la ubicación por omisión es raíz_perfil/logs/appserver/SystemOut.log) en la máquina 192.168.0.1.
  • [IBM i]Aparece un registro de rastreo para el servlet en el archivo de anotaciones cronológicas del servidor de aplicaciones (la ubicación por omisión es raíz_perfil/logs/appserver/SystemOut.log) en la máquina 192.168.0.1.
  • [AIX Solaris HP-UX Linux Windows][z/OS]Aparece un registro de rastreo para la invocación del método del bean de incremento en el archivo de anotaciones cronológicas del servidor de aplicaciones (la ubicación por omisión es raíz_perfil/logs/appserver/SystemOut.log) en la máquina 192.168.0.2.
  • [IBM i]Aparece un registro de rastreo para la invocación del método del bean de incremento en el archivo de anotaciones cronológicas del servidor de aplicaciones (la ubicación por omisión es raíz_perfil/logs/appserver/SystemOut.log) en la máquina 192.168.0.2.
Nota: En este tema se hace referencia a uno o más de los archivos de registro del servidor de aplicaciones. Como alternativa recomendada, puede configurar el servidor para utilizar la infraestructura de registro y rastreo HPEL en lugar de utilizar los archivos SystemOut.log , SystemErr.log, trace.log y activity.log en sistemas distribuidos y de IBM® i. Puede también utilizar HPEL junto con sus recursos de registro nativos de z/OS. Si utiliza HPEL, puede acceder a toda la información de registro y rastreo utilizando la herramienta de línea de mandatos LogViewer desde el directorio bin de perfil de servidor. Consulte la información sobre la utilización de HPEL para resolver problemas de aplicaciones para obtener más información sobre la utilización de HPEL.
Los dos registros de rastreo que aparecen en 192.168.0.1 son parecidos al ejemplo siguiente:
PLUGIN:
parent:ver=1,ip=192.168.0.1,time=1016556185102,pid=796,reqid=40,event=0
- current:ver=1,ip=192.168.0.1,time=1016556185102,pid=796,reqid=40,event=1 
type=HTTP detail=/hitcount elapsed=90 bytesIn=0 bytesOut=2252

Servidor de aplicaciones (nivel de contenedor Web)
PMRM0003I: parent:ver=1,ip=192.168.0.1,time=1016556185102,pid=796,reqid=40,event=0
- current:ver=1,ip=192.168.0.1,time=1016556186102,pid=884,reqid=40,event=1 
type=URI detail=/hitcount elapsed=60 
El registro de rastreo que se muestra en la máquina 192.168.0.2 es similar al ejemplo siguiente:
PMRM0003I: 
parent:ver=1,ip=192.168.0.1,time=1016556186102,pid=884,reqid=40,event=1 
- 
current:ver=1,ip=192.168.0.2,time=1016556190505,pid=9321,reqid=40,event=1              
type=EJB 
detail=com.ibm.defaultapplication.Increment.increment elapsed=40

Icon that indicates the type of topic Task topic



Timestamp icon Last updated: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=tprf_requestmetrics
File name: tprf_requestmetrics.html