Tuning de Servidores de Aplicação Java EE Fernando Lozano www.lozano.eti.br <fernando@lozano.eti.br> Arquiteto de Soluções Neki Technologies www.neki.com.br
Sobre o Autor Consultor com mais de 12 anos de atuação no desenvolvimento de sistemas e integração de redes Detentor de diversas certificações profissionais da Microsoft, Sun, IBM, Red Hat e LPI Autor do Livro Java em GNU/Linux Colunista da revista Java Magazine Colaborador do IBM dw e da NetBeans Magazine Ex-Conselheiro do Linux Professional Institute Webmaster da Free Software Foundation Community Manager do Java.Net Palestrante em eventos internacionais como JavaOne, FISLI, LinuxWorld Expo, Sun Tech Days e LatinoWare
Patrocinador Missão: Otimizar Resultados Especialista em soluções open source baseadas na plataforma Java Consultoria em Desenvolvimento e Infra-Estrutura de Sistemas Capacitação e Mentoring em Tecnologia e Processos
Parcerias Neki Truth Happens Gerenciamento de Riscos Soluções em Segurança e Biometria Professional Open Source
Agenda 1. Performance de Aplicações Java EE 2. Performance da JVM 3. Performance do Servidor Java EE 4. Monitoração
Performance de Aplicações Java EE Tradicionalmente, os desenvolvedores focam na performance da aplicação em si, que é afetada por diversos fatores: Qualidade dos frameworks Conhecimento de uso dos frameworks Escolha dos algoritmos Caches e pools de objetos Uso de stored procedures do banco de dados Eliminação de lógica redundante ou desnecessária
Profiling de Aplicações É a principal ferramenta para tuning de aplicações Depende de um processo de instrumentação do código O profiling identifica os métodos e classes onde a aplicação gasta mais tempo executando Mas tem algumas desvantagens: Muito pesado para o ambiente de produção Interferência com otimizações do JIT Necessidade de acesso aos fontes da aplicação
Performance da JVM Focada na redução do tempo gasto com a coleta de lixo (GC) ou na freqüência das coletas maiores Cada fornecedor de JVM (Sun, IBM, BEA) fornece documentação extensivo sobre o tuning do GC Hoje recursos como reflexão estão maduros o suficientes para deixarem de ser uma preocupação para o desenvolvedor de aplicações O Tuning do GC em geral expõe bugs da aplicação (leaks)
Threads Verdes x Nativas Alguns SOs são reconhecidamente incapazes de gerenciar quantidade quantidade de tarefas / processos / threads concorrentes, levando à duplicação desta funcionalidade dentro da própria JVM Entretanto nos SOs mais modernos (Linux, Solaris, Windows) o melhor desempenho em SMP é obtido com threads nativas Pode ser necessário rodar várias JVMs separadas para contornar limitações de volume (threads / heap)
Performance do Servidor Java EE O servidor de aplicações deve ser visto como uma coleção de serviços, cada qual necessitando de tuning individualizado O objetivo primário do tuning é evitar a contenção por recursos como: Threads de trabalho DataSources Instâncias de EJB
O Servidor Java EE como um Pipeline Conector / Listener Pool EJBs DataSources
O Servidor Java EE como um Pipeline (2) Conector / Listener DataSources Pool SLSBs A Pool SLSBs B Fila JMS Pool MDBs
Primeiro Abrir... 1. Estimar a quantidade de recursos em cada estágio de acordo com a previsão de usuários ou TPS 2. Dimensionar cada recurso para que tenha uma folga 3. Monitorar o uso de recursos do SO (CPU, memória, disco e rede), assim como o uso dos recursos em cada estágio do pipeline durante um teste de stress, aumentando a carga gradativamente 4. Se algum estágio ficar saturado, aumentar seus recursos e voltar ao passo 1
...Depois Fechar 5. Atingido um gargalho do SO, retornar os recursos do estágio relacionado ao patamar no estágio anterior 6. Reduzir os recursos no primeiro estágio do pipeline para manter a contenção fora do servidor de aplicações, não dentro A contenção dentro do servidor de aplicações diminui o throughput com a mesma carga de trabalho
Servidor Java EE x SO Conector / Listener Threads / FH / CPU Pool EJBs Memória / CPU DataSources Memória / FH / Rede
Parece Tuning de BD.. Verdade, os pools de threads / EJBs / DataSources de um servidor Java EE são análogos aos row buffers e sort buffers de um BD Relacional Entretanto um servidor Java EE tem uma quantidade potencialmente ilimitada de pools......além de maior quantidade de tipos de pools diferentes (JMS, SLSB, SFSB, MDB, etc)
O Servidor Java EE como Múltiplos Pipelines Conector / Listener Pool EJBs A Pool EJBs B DataSources A DataSources B DataSources C
Tuning É um Processo Interativo! Mudanças e sazonalidades nos padrões de uso da aplicação podem tornar um tuning obsoleto A quantidade de EJBs e DataSources em um mesmo servidor Java EE pode inviabilizar uma estimativa precisa da quantidade de recursos em cada estágio, tornando o tuning um processo de tentativa e erro Tenha sempre testes de stress automatizados e logs de acesso para validar os testes de stress
Como Medir a Contenção? Ferramentas do SO Sysstat (Unix) Performance Monitor (Windows) SNMP JMX JConsole JSR 77 MBeans do container Gateways HTTP / SNMP
Cuidado com os Logs! Podem prejudicar a performance porque: E/S é sempre bem mais lenta do que processamento Os arquivos e discos onde eles estão geram contenção Como melhorar: Nível ERROR ou SEVERE em produção Seletivamente em INFO para depuração Arquivos de log separados por componente / contexto Discos dedicados para logs
Perguntas? http://www.lozano.eti.br fernando@lozano.eti.br