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

As informações monitoradas por métricas de pedido podem ser salvas nos arquivos de registro para recuperação e análise posterior ou enviadas a agentes ARM (Application Response Measurement), ou ambos.
À medida que uma transação flui pelo sistema, as métricas de pedidos incluem informações adicionais para que os registros de log de cada componente possam ser correlacionados, formando uma imagem completa da transação. Os resultados são semelhantes ao exemplo a seguir:
HTTP request/trade/scenario ------------------------------> 172 ms
     Servlet/trade/scenario  -----------------------------> 130 ms
         EJB TradeEJB.getAccountData --------------------->  38 ms
              JDBC select -------------------------------->   7 ms 

Fluxo de transação

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.

Cinco tipos de filtros são suportados:
  • 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.

Nota: Os filtros são aplicáveis apenas onde o pedido entra primeiro no WebSphere Application Server.

Procedimento

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.

Exemplo

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.

Neste exemplo, pelo menos três registros de rastreio são gerados:
  • É 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.
  • [AIX Solaris HP-UX Linux Windows][z/OS]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.
  • [IBM i]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.
  • [AIX Solaris HP-UX Linux Windows][z/OS]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.
  • [IBM i]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.
Nota: Esse tópico faz referência a um ou mais arquivos de log do servidor de aplicativos. Como uma recomendação alternativa, é possível configurar o servidor para usar a infraestrutura de log e rastreio do High Performance Extensible Logging (HPEL) em vez de usar os arquivos SystemOut.log , SystemErr.log, trace.log e activity.log em sistemas distribuídos e IBM® i. Também é possível usar HPEL em conjunção com os recursos de criação de log z/OS nativos. Se você estiver usando HPEL, será possível acessar todas as informações de log e rastreio usando a ferramenta de linha de comandos LogViewer a partir do diretório bin do perfil do servidor. Consulte as informações sobre a utilização do HPEL para resolução de problemas dos aplicativos para obter mais informações sobre o uso do HPEL.
Os dois registros de rastreio que são exibidos na máquina 192.168.0.1 são semelhantes ao seguinte exemplo:
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 
O registro de rastreio que é exibido na máquina 192.168.0.2 é semelhante ao seguinte:
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

Ícone que indica o tipo de tópico Tópico de Tarefa



Ícone de registro de data e hora Última atualização: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=tprf_requestmetrics
Nome do arquivo: tprf_requestmetrics.html