Histórico da Página
A A primeira meta é identificar o ponto de lentidão no sistema e levantar os tempos aproximados.
Com base na reclamação do cliente monitorar os tempos de resposta do servidor usando as ferramentas de desenvolvimento do navegador (F12). A monitoração O monitoramento dos tempos de resposta é feita feito pela ferramenta de rede (networkNetwork).
Tabela Geral para
...
tempo de
...
resposta
Tempo | Percepção |
---|
...
Reação | |
---|---|
menor que 1 segundo | Instantâneo |
...
Feliz | |
até 3 segundos | Rápido |
...
Indiferente | |
de 3 a 5 segundos | Aceitável |
...
Desconforto | ||
de 5 a 10 segundos | Lento | Irritação |
maior que 10 segundos | Travado |
...
Reenvio da solicitação |
Tempos esperados para algumas operações do
...
fluig
Operação | 1 usuário | 30 usuários | 100 usuários |
---|---|---|---|
Carregar pagina | < 3 segundos | < 5 segundos | 12 segundos |
Movimentação de processos | < 5 segundos | < 8 segundos | 20 segundos |
Publicar documento | < 3 segundos | < 5 segundos | 10 segundos |
...
Após levantar o recurso e os tempos é possível fazer uma rápida
...
análise para identificar alguns pontos que costumam interferir na resposta do servidor:
Páginas
Tamanho das páginas
...
Ainda na aba de network da ferramenta de desenvolvimento ver a quantidade de bytes transferidas para montar a pagina.
...
...
As paginas padrões do Fluig não passam de 1100 bytes . Números acima de 2 megas podem prejudicar a performance dependendo da infra estrutura de rede.
...
Widgets
...
síncronas
...
Em alguns casos as widgets demoradas "travam" o desenho de toda página. Retire a widget da pagina e efetue um novo teste. Caso o tempo de resposta seja aceitável verificar a possibilidade da widget ser
...
transformada em
...
assíncrona.
Banco de Dados
...
Caso o cliente possua um DBA ou uma equipe que monitore o banco solicite um relatório de Queries lentas e peca para verificar se não existe locks demorados ou DeadLocks.
Configurações
...
O fluig na instalação padrão sai com apenas 20 conexões com o banco. Esse numero é baixo. O ideal é deixar esse numero próximo ao numero de usuários concorrentes esperado. Mais é importante tomar cuidado. Um numero muito alto de conexões gera gasto no gerenciamento do pool.
...
Para identificar se o cliente esta sofrendo com falta de conexões é necessário habilitar o console de gerenciamento do JBoss.
...
- No prompt de comando do Windows ou no shell do
...
- Linux, navegue até o diretório bin do JBoss (
...
- [Instalação do fluig]/jboss/bin);
...
- Executar o script add-user.bat ou add-user.sh;
...
- Para a primeira pergunta, apenas digite ENTER;
...
- Digite o nome do usuário na segunda pergunta;
...
- Escolha uma senha e digite-a
...
- na terceira e quarta pergunta;
...
- Após a confirmação da senha digite ENTER na
...
- quinta pergunta;
...
- Na sexta e sétima
...
- perguntas é necessário digitar "sim" (ou
...
- yes
...
- , se o console estiver em
...
- inglês) e confirmar com
...
- a tecla Enter.
Após o cadastro do usuário acesse o console de monitoramento http://<IP_OU_HOST>:9990.
...
O ideal é usar o IE (até o Fluig 1.5)
...
pois a visualização dos dados no
...
Chrome ou Firefox trazem informações confusas.
A informação "Available" indica quantas conexões estão livres para serem usadas. O "Active Count" informa a quantidade de conexões com o banco sendo usadas no momento. O "Max Used" é o registro do numero máximo de conexões usadas desde que o servidor foi iniciado. Se o percentual do "Max Used" estiver em 100% em algum momento o cliente sofreu com falta de conexões com o banco.
Ainda no console de monitoramento é possível acompanhar o uso de memoria do Jboss.
Caso Caso o percentual do uso de memoria fique variando na casa dos 90% por um longo período é possível que o servidor precise mais memoria.
Uma ultima avaliação a ser feita no console é o acumulo de mensagens nas filas e tópicos.
Avaliar Avaliar todas as filas e tópicos. Caso algum tenha a informação "In Delivery" maior que 30 provavelmente algum componente do fluig precise ser revisto..