Como monitorar a performance das aplica��es Telescope/Eligo?

RT.FAQ-8233

Este procedimento que deve ser executado para tentar identificar a causa de problemas de performance.

Mem�ria, queries e locks

Acesse os dados de monitoramento atrav�s de URL

http://..../ELIGO/ctr/Notification/info

Veja como os itens:

DATABASE_LOCKS - A exist�ncia de locks demorados causa muitos problemas de performance. Isso explica determinadas requisi��es "trancarem".
DATABASE_QUERIES - A exist�ncia de queries demorados causa muitos problemas de performance.
MEMORY_HEAP - A HEAP � muito dinamica (sobe e desce). Pode ter picos perto de 100% sem problemas, mas deve-se acompanha-la por algum tempo. Se ela nunca baixar de 70%, pode identificar um problema relacionado ao uso excessivo de mem�ria.
MEMORY_CMS_OLD_GEN - Tende a ser o patamar "baixo" da heap. Se o valor da OLD estiver pr�ximo do valor m�ximo da heap, significa um problema relacionado ao uso excessivo de mem�ria.
MEMORY_CMS_PERM_GEN - Est� relacionado � carga de classes do sistema. Pode ficar alto ap�s atualiza��es do sistema. N�o causa problemas de performance mas se ficar muito alto pode causar a parada do sistema.

Se valor de OLD estiver alto, recomenda-se uma an�lise dos objetos em mem�ria atrav�s de um dump da heap: Como obter e analisar o consumo de mem�ria em aplica��es Java?

Sess�es correntes

Tamb�m � possivel verificar o que cada usu�rio est� executando em um dado instante.
Para isso, acesse a tela

LstSessions

Logs da aplica��o

O monitoramento pode ser feito atrav�s da consulta aos logs do sistema. Em primeira inst�ncia, as queries SQL abaixo ir�o dar uma vis�o geral do comportamento da aplica��o nos �ltimos 30 minutos.
Se quiser aumentar este per�odo, basta alterar a express�o do primeiro comando "select".

select '30 minute' as tx;
let p=last;

select count(1) as Requisicoes
, round(avg(tempo)) as "Tempo m�dio (ms)"
, sum(tempo) as "Tempo total"
, round(sum(tempo)/extract(epoch FROM (interval '${p.tx}'))/10) as "% Tempo"
, round(count(1)/30) as "Requisi��es/min"
, count(distinct sessao_id) as "Sess�es"
, count(distinct usuario) as "Usu�rios"
from logs
where data_hora > (current_timestamp - interval '${p.tx}')
and tipo='REQUEST';

select ct as "Tempo da requisi��o", count(1), count(1)*100/${last.requisicoes} as "%"
from (
   select case 
   when tempo <= 100 then '0) 0 - 100ms'
   when tempo > 100 and tempo <= 500 then '1) 100ms - 500ms'
   when tempo > 500 and tempo <= 1000 then '2) 500ms - 1s'
   when tempo > 1000 and tempo <= 5000 then '3) 1s - 5s'
   else '4) > 5s' end as ct
   from logs
   where data_hora > (current_timestamp - interval '${p.tx}')
   and tipo='REQUEST'
) q
group by ct
order by ct;

select origem as "Tela de origem"
, count(1) as "Requisi��es"
, round(avg(tempo)) as "Tempo m�dio (ms)"
, min(tempo), max(tempo)
, sum(tempo) as "Custo total (ms)"
from logs
where data_hora > (current_timestamp - interval '${p.tx}')
and tipo = 'REQUEST'
group by tipo, origem
order by avg(tempo) desc;

select origem as "Tela de origem"
, count(1) as "Requisi��es"
, round(avg(tempo)) as "Tempo m�dio (ms)"
, min(tempo), max(tempo)
, sum(tempo) as "Custo total (ms)"
from logs
where data_hora > (current_timestamp - interval '${p.tx}')
and tipo = 'REQUEST'
group by tipo, origem
order by sum(tempo) desc;

A primeira parte d� um resumo dos �ltimos 30 minutos de uso do sistema.
A segunda parte, tabula as requisi��es conforme o tempo de execu��o. Espera-se que o maior n�mero de requisi��es se concentre nas faixas mais r�pidas de execu��o.
A terceira e quarta partes, apresenta as telas que est�o tem a m�dia mais alta e que est�o sendo mais "caras" para o sistema em termos de performance.

Observa��es

Estas queries apenas demonstram como est� a performance do sistema com rela��o � requisi��es executadas. Elas n�o indicam a causa e requisi��es que ainda est�o em execu��o n�o s�o contabilizadas.
Em alguns casos, tempos elevados n�o oferecem impacto de performance no resto do sistema e s�o causados por depend�ncias externas, tais como o envio de e-mail, comunica��o com um web-service, etc.

Uso de CPU no servidor

Verificar como est� o uso da CPU no servidor.
Em caso de Linux, � necess�rio ter acesso SSH ao servidor e executar o comando:

top

Em caso de Windows, pela aba "Processos" do Gerenciador de Tarefas (ordenar por CPU decrescente).

N�mero de requisi��es chegando ao servidor

No servidor, execute o comando abaixo. Este comando apresenta o n�mero de requisi��es que o tomcat est� respondendo a cada minuto.

grep "`date +%d/%b/%Y`" localhost_access_log.2014-03-18.txt|cut -d"[" -f2|cut -d":" -f1-3|uniq -c