Performance JEE. Haroldo R. J. de Macêdo

(1)

Performance JEE

Haroldo R. J. de Macêdo

(2)

Agenda



_{Conceitos de performance}



_{Testes para performance}



_{Lições aprendidas}

(3)

Programa Java x JEE



_Java

◦ Interface gráfica ◦ Cliente / Servidor ◦ Um usuário ◦ Executa localmente 

_JEE

◦ Roda remotamente em um contêiner JEE

◦ Recebe requisições de vários usuários

◦ N camadas

(4)

Custo da baixa performance



_{Custos de suporte altíssimos}

◦ Mais recursos são necessários para a produção (CPU, Memória, Disco, Rede)



_{Perda de confiança}

◦ Tempo de resposta alto e piorando



_{Perda de credibilidade}

◦ Performance prometida não alcançada



_{Perda de receita}

(5)

Conceitos equivocados



_{Basta apertar o “botão mágico”}



_{Acrescente mais memória ao sistema}



_{Inclua mais servidores}



_{Aumente a quantidade de CPUs}



_{Basta escrever o código e fazer deploy}



_{Não se pode criar um ambiente performático para}

um aplicativo mal projetado

(6)

Quando pensar em performance



_{No projeto da arquitetura}



_{Durante o desenvolvimento}



_{Nos testes unitários}



_{Nos testes de integração}



_{Nos testes de carga}



_{No momento de deploy}

(7)

Modelo em camadas JEE

(8)

Topologia JEE em produção

(9)



_{Servidor Web}



_Rede



_{Balanceador de carga}



_{Servidor de Aplicação}



_{Banco de Dados}



_Hardware



_Projeto



_Firewall



_{Back End}



_EJBs



_Etc.

15/09/2009 Performance JEE - Just Java 2009 9

Qual é a causa da baixa performance

(10)

 _{Atendimento em um supermercado}

 _{Exemplo centrado no atendimento no caixa do supermercado} ◦ Dirigir-se ao caixa

◦ Passar os produtos pelo caixa

◦ Pagar

◦ Ensacar os produtos

◦ Sair do caixa com os produtos no carrinho

 _{Não leva em consideração}

◦ Deslocamento até o supermercado

◦ Estacionar o carro

◦ Escolher os produtos

◦ Colocar as compras no carro

◦ Dirigir para casa

Exemplo da apresentação

(11)

Agenda



_{Conceitos de performance}



_{Testes para performance}



_{Lições aprendidas}

(12)

Conceitos de performance



_{Tempo de resposta}



_Carga



_{Fluxo (Throughput)}



_Capacidade

(13)

Outros conceitos



_{Enfileiramento}



_{Escalabilidade}



_Gargalo



_{Monitoramento}



_Arquitetura



_Isolamento

(14)

Tempo de resposta



_{Tempo que um indivíduo aguarda pela resposta de}

uma requisição

◦ Normalmente a média dos 95% melhores tempos



_{Componentes principais}

◦ Tempo de processamento

(15)

Tempo de resposta



_{É uma medida crítica}



_{Baixo tempo de resposta desagrada os usuários}



_{Tempo de resposta deve ser considerado em:}

◦ Momentos de pico

◦ Cargas altas fora do normal

◦ Clientes usando rede discada

(16)

Tempo de resposta



_{Na Web}

◦ Tempo entre uma requisição e sua resposta

◦ Tempo entre o clique de um botão e apresentação da nova tela



_{No exemplo do supermercado}

◦ É o tempo que o cliente demora desde o momento que chega ao caixa até o momento que sai do caixa com as compras

(17)

Carga



_{É a pressão em um site expressa em:}

◦ Atividade dos usuários

 _{Usuários chegando}  _{Usuários se logando}

 _{Usuários enviando requisições} ◦ Atividades de requisição

 _{Requisições por segundo}  _{Páginas por hora}

 _{Transações por segundo}

(18)

Carga



_{No exemplo do supermercado}

◦ Quantidade de clientes no supermercado que estão indo em direção ao caixa ou que já estão na fila do caixa



_{Quantidade de clientes que usam o site ao mesmo}

(19)

Fluxo



_Throughput



_{Mede tarefas concluídas por unidade de tempo}



_{É uma medida de capacidade}



_{Não mede todas as solicitações, apenas as que}

foram atendidas

◦ Solicitações em excesso serão enfileiradas, abandonadas ou descartadas

(20)

Fluxo



_{No exemplo do supermercado}

◦ Quantidade de clientes atendidos por minuto no caixa do supermercado

◦ Não contabiliza os clientes que desistiram ao ver uma fila grande



_{Outros exemplos}

◦ Carros que passam por minuto em uma ponte

◦ Requisições por segundo num site

(21)

Fluxo



_{Caixa de supermercado}

◦ Cada caixa atende a um cliente a cada 5 minutos

◦ Com 1 caixa, o supermercado atende

 _{12 clientes / hora}

◦ Com 10 caixas, o supermercado atende

 _{2 clientes / minuto}

(22)

Capacidade



_{Descreve a carga suportada}



_{O resultado final do teste de carga e performance}

◦ Determina a infraestrutura de hardware e software necessária

◦ Deixa uma “gordura” para emergências

◦ Leva em consideração o crescimento do site para um aumento futuro da carga

(23)

Capacidade



_{No exemplo do supermercado}

◦ Quantidade de caixas disponíveis na loja do supermercado

◦ Tipo do caixa

 _{Leitora de código de barras}  _{Digitação do preço}

◦ Quantidade da caixas em operação

◦ Qualidade do pessoal do caixa

(24)

Capacidade



_{Exemplo do supermercado}

◦ Quantas caixas registradoras serão necessárias para atender a 10.000 clientes por dia?

◦ Há necessidade de caixas extras no fim do mês?

◦ Será necessário mais espaço físico para expansões futuras?

 _{Mais estacionamento}  _{Mais andares}

(25)

Gargalo

 _{Ponto de redução de fluxo}

 _{Aparece em programas multithread ou multiusuários}  _{Usuários enfileirados esperando recurso compartilhado}

◦ CPU, I/O, Registro no BD

 _{Threads esperando por uma tarefa ser completada}  _{Resolva os gargalos em ordem de severidade}

 _{O sistema é tão rápido quanto o seu componente mais lento}

(26)

Gargalo



_{No aeroporto}

◦ Check-in ◦ Detector de metais ◦ Porta do avião 

_{Nas estradas}

◦ Construções ◦ Pedágios ◦ Acidentes

(27)

Escalabilidade



_{Define a facilidade de expansão do sistema}



_{Sites precisam se expandir, às vezes}

inesperadamente

◦ Novos mercados

◦ Crescimento normal

◦ Picos extremos

(28)

Escalabilidade



_{No supermercado}

◦ Caixas disponíveis na loja

◦ Espaço para instalação de mais caixas

◦ Redução do espaço ocupado por um caixa

(29)



_{Tempo de Resposta}



_Carga



_{Fluxo (Throughput)}



_Capacidade



_{Enfileiramento}



_{Escalabilidade}



_Gargalo



_{Monitoramento}



_Arquitetura



_Isolamento

Conceitos de performance

(30)

Como melhorar a performance



_{Aumentar a capacidade}

◦ Quantidade de CPU

◦ Quantidade de caixas de supermercado



_{Reduzir o tempo de processamento}

◦ Acelerar um ou mais passos da transação

◦ Código mais eficiente

◦ Caixas trabalhando mais rápido



_{Reduzir o número de passos necessários para a}

transação

◦ Reduzir o número de telas

(31)

Agenda



_{Conceitos de performance}



_{Testes para performance}



_{Lições aprendidas}

(32)

Quando testar?

(33)

Análise de código



_{Análise estática de código}

◦ Implementação das melhores práticas

 _Código

 _Arquitetura



_{Análise dinâmica de código}

◦ Profiling

◦ Leak de memória

◦ Gargalos

◦ Problemas com thread

(34)

Por que fazer teste de performance



_{Melhorar a qualidade percebida pelo usuário}



_{Descobrir mais cedo defeitos que reduzem a}

performance

◦ Custo por defeito:

 _{1 no projeto}  _{10 nos testes}

 _{100 em produção}



_{Obter dados para decidir sobre funcionalidades que}

(35)

Objetivos dos testes de performance



_{Identificar os tempos de resposta}

◦ Validar os requisitos e tempos de resposta

◦ Fazer benchmark

◦ SLA (Nível de serviço acordado)



_{Determinar o número máximo de usuários}

◦ Plano de capacidade

◦ Escalabilidade



_{Descobrir a melhor configuração}

◦ Carga normal e pico

◦ Ambiente de failover

(36)

Agenda



_{Conceitos de performance}



_{Testes para performance}

(37)



_{Sistema Web com 1.200 transações / segundo}



_{Preocupações de Projeto}

◦ Código que demore mais 1ms sem necessidade

 _{Tem o impacto de 1,2 segundo em consumo de CPU}  _{Preocupação com o código que possui laços de loop} ◦ Gargalo que pare o sistema por 30 segundos

 _{Enfileira 36.000 transações}  _{Derruba o sistema}

 _{Monitoração e ação automática}

Altíssima carga

(38)

Gargalo no BD



_{Acesso serializado a uma tabela do BD}

◦ O sistema é tão rápido quanto o tempo de resposta do banco

◦ Não adianta acrescentar CPU ou memória no contêiner, nem melhorar a rede

◦ Melhora no projeto para aumentar a concorrência



_{Queries demoradas}

◦ Alto consumo de I/O e CPU do servidor de BD

(39)

Loop no código



_{Uma das funcionalidades entrava em loop}

◦ Consumo alto de CPU

◦ Baixo impacto inicial

 _{Arquitetura de threads}

◦ Melhora no processo de desenvolvimento de software, com mais testes e controle de versão

(40)

Melhores práticas

 _{Defina os objetivos de performance o mais cedo possível}  _{Valide a arquitetura e o projeto o mais cedo possível}  _{Use o design-pattern MVC}

 _{Não reinvente a roda}

 _{Programe as especificações e não o servidor de aplicativos}  _{Use o desenvolvimento iterativo}

 _{Sempre use Sessions Facade quando usar componentes EJBs}  _{Pegue os recursos compartilhados tarde e os devolva rápido}  _{Coloque o processamento perto do recurso que ele necessita}  _{Use o JEE ao invés de tentar enganá-lo}

(41)

(42)

Referência



_Curso

◦ WF-881 – IBM WebSphere V6 Performance Testing and Monitoring Tools for Administrators



_{IBM Red Books}

◦ SG246392 – WebSphere Application Server V6 Scalability and Performance Handbook

◦ SG247497 – Designing and Coding Applications for Performance and Scalability in WebSphere Application Server

(43)

Obrigado

Merci Grazie

Gracias

Thank You

Danke Japanese English French Russian German Italian Spanish Arabic Traditional Chinese Simplified Chinese Thai Korean Hindi Tamil Brazilian Portuguese