¿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
HTTP request/trade/scenario ------------------------------> 172 ms
Servlet/trade/scenario -----------------------------> 130 ms
EJB TradeEJB.getAccountData ---------------------> 38 ms
JDBC select --------------------------------> 7 ms

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.
- 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.
Procedimiento
- Para obtener más información sobre request metrics, revise las descripciones que se incluyen en este apartado:
- Configurar y habilitar Request Metrics.
- Recuperar datos de rendimiento y supervisar flujo de aplicaciones.
- Ampliar la supervisión para hacer un seguimiento de aplicaciones que puedan requerir puntos de instrumentación adicionales.
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.

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.
- 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.
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.
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.
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.
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.
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
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