Por que Utilizar Métricas de Pedidos?
A métrica de pedido é uma ferramenta que permite rastrear as transações individuais, registrando o tempo de processamento em cada um dos principais componentes do WebSphere Application Server.
Antes de Iniciar
HTTP request/trade/scenario ------------------------------> 172 ms
Servlet/trade/scenario -----------------------------> 130 ms
EJB TradeEJB.getAccountData ---------------------> 38 ms
JDBC select --------------------------------> 7 ms

Esse fluxo de transação com tempos de resposta associados pode ajudá-lo a definir áreas de problemas de desempenho e depurar problemas de restrição de recursos. Por exemplo, o fluxo pode ajudar a determinar se uma transação gasta a maioria de seu tempo no plug-in de servidor da Web, no contêiner de Web, no contêiner EJB (Enterprise JavaBeans) ou no banco de dados de back end. O tempo de resposta coletado para cada nível inclui o tempo gasto no nível e o tempo gasto nos níveis inferiores. Por exemplo, o tempo de resposta para o servlet, que é 130 milissegundos, também inclui 38 milissegundos dos enterprise beans e do Java™ Database Connectivity. Portanto, 92 ms podem ser atribuídos ao processamento do servlet.
As métricas de pedidos monitoram o tempo de resposta de uma transação específica. Como as métricas de pedidos monitoram transações individuais, sua utilização impõe algumas implicações de desempenho no sistema. No entanto, essa função pode ser amenizada pela utilização dos recursos de filtragem de pedidos.
Por exemplo, as ferramentas podem injetar transações sintéticas. As métricas de pedidos podem rastrear o tempo de resposta no ambiente do WebSphere Application Server para essas transações. Uma transação sintética é aquela que é injetada no sistema por administradores para obter uma abordagem pró-ativa para testar o desempenho do sistema. Essas informações ajudam os administradores a ajustar o desempenho do Web site e realizar ações corretivas. Assim, as informações fornecidas pelas métricas de pedidos podem ser utilizadas como um mecanismo de alerta para detectar quando o desempenho de um tipo de pedido específico ultrapassa os limites aceitáveis. O mecanismo de filtragem nas métricas de pedidos pode ser utilizado para focar transações sintéticas específicas e pode ajudar a otimizar o desempenho nesse cenário.
Sobre Esta Tarefa
Quando você tiver as áreas de problemas isoladas, utilize o mecanismo de filtragem das métricas de pedidos para focar especificamente essas áreas. Por exemplo, quando você tem um problema isolado em um servlet específico ou um método EJB, utilize os algoritmos de URI (Uniform Resource Identifier) ou o filtro de EJB para permitir a instrumentação somente para o servlet ou o método EJB. O mecanismo de filtragem suporta uma análise de desempenho mais focada.
- Filtro do IP de Origem
- Filtro de URI
- Filtro de Nome do Método do EJB
- Filtro de Parâmetros de JMS
- Filtro de Parâmetros de Serviços da Web
Quando a filtragem está ativada, somente pedidos que correspondem ao filtro geram dados de métricas de pedidos, criam registros de log, chamam interfaces ARM ou todos. Você pode injetar o trabalho em um sistema em execução (especificamente para gerar informações de rastreio) para avaliar o desempenho de tipos específicos de pedidos no contexto de uma carga normal, ignorando pedidos de outras origens que possam estar atingindo o sistema.
Procedimento
- Saiba mais sobre métricas de pedidos, revendo as explicações detalhadas nessa seção.
- Configurar e ativar métricas de pedidos.
- Recuperar dados de desempenho e monitorar o fluxo de aplicativos.
- Extender o monitoramento para rastrear aplicativos que podem requerer pontos de instrumentação adicionais.
Exemplo
Aprenda como usar as métricas de solicitação visualizando o seguinte exemplo.
Neste exemplo, o servlet HitCount e o bean corporativo Increment são implementados em dois processos diferentes do servidor de aplicativos. Conforme mostrado no diagrama a seguir, a camada de contêiner da Web e as camadas de contêineres EJB (Enterprise JavaBeans) estão sendo executadas em dois servidores de aplicativos diferentes. Para instalar essa configuração, instale o WebSphere Application Server, Network Deployment.

Suponha que as camadas do servidor e do contêiner da Web sejam executadas na máquina 192.168.0.1, e a camada do contêiner EJB (Enterprise JavaBeans) seja executada em uma segunda máquina 192.168.0.2. Os pedidos do cliente podem ser enviados a partir de uma máquina diferente; 192.168.0.3, por exemplo, ou de outras máquinas.
Para ilustrar a utilização da filtragem de IP de origem, um filtro de IP de origem (192.168.0.3) é definido e ativado. É possível rastrear pedidos originários da máquina 192.168.0.3 através de http://192.168.0.1/hitcount?selection=EJB&lookup=GBL&trans=CMT. No entanto, os pedidos que são originados de qualquer outra máquina não são rastreados porque o endereço IP de origem não está na lista de filtros.
Criando-se somente um filtro de IP de origem, quaisquer pedidos desse endereço IP de origem são rastreados efetivamente. Esta ferramenta é eficaz para localizar problemas de desempenho com sistemas sob carga. Se a carga normal se originar de outros endereços IP, seus pedidos não serão rastreados. Utilizando o endereço IP de origem definido para gerar pedidos, você pode ver gargalos de desempenho nos vários saltos, comparando os registros de rastreio do sistema carregado com os registros de rastreio de uma execução não carregada. Essa capacidade ajuda a focalizar os esforços de ajuste no nó e no processo corretos dentro de um ambiente de implementação complexo.
Certifique-se de que as métricas de pedidos estejam ativadas através do console administrativo. Certifique-se também de que o nível de rastreio esteja definido pelo menos como hops (gravando rastreios de pedidos nos limites do processo). Utilizando a configuração relacionada anteriormente, envie um pedido http://192.168.0.1/hitcount?selection=EJB&lookup=GBL&trans=CMT através do servlet HitCount a partir da máquina 192.168.0.3.
- É exibido um registro de rastreio para o plug-in do servidor da Web no arquivo de log do plug-in (o local padrão é (plugins_root/logs/web_server_name/http_plugin.log) na máquina 192.168.0.1.
Um registro de rastreio do servlet é exibido no arquivo de log do servidor de aplicativos (o local padrão é profile_root/logs/appserver/SystemOut.log) na máquina 192.168.0.1.
Um registro de rastreio do servlet é exibido no arquivo de log do servidor de aplicativos (o local padrão é profile_root/logs/appserver/SystemOut.log) na máquina 192.168.0.1.
Um registro de rastreio da chamada de método de bean de incremento é exibido no arquivo de log do servidor de aplicativos (o local padrão é profile_root/logs/appserver/SystemOut.log) na máquina 192.168.0.2.
Um registro de rastreio da chamada de método de bean de incremento é exibido no arquivo de log do servidor de aplicativos (o local padrão é profile_root/logs/appserver/SystemOut.log) na 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 aplicativos (camada do contêiner da 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