Performance tunning de servidores ColdFusion MX

325 visualizações

Publicada em

Apresentação no 14º encontro do Grupo de Usuários de ColdFusion do Rio de Janeiro (CFUG-Rio), Rio de Janeiro.

Publicada em: Software
0 comentários
1 gostou
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
325
No SlideShare
0
A partir de incorporações
0
Número de incorporações
8
Ações
Compartilhamentos
0
Downloads
5
Comentários
0
Gostaram
1
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Performance tunning de servidores ColdFusion MX

  1. 1. Macromedia ColdFusion MX Tunning Alex Hübner – CFUG-SP/Friends of The Earth alex@hubner.org.br http://www.cfugsp.com.br
  2. 2. 2 Lembrando do nosso amigo ColdFusion  Um servidor de aplicações como outro qualquer (que heresia!)  Sintaxe muito “solta”, vítima perfeita de aplicações não escaláveis e lentas (paradoxal não?)  Mudança radical de arquitetura em 2002, tornando-se um Servlet Java Enterprise (J2EE)  Mudança radical de idéias e conceitos sobre as versões anteriores  Esqueça tudo o que você sabe sobre otimização em versões 5 e anteriores
  3. 3. 3 Principais fatores que influenciam a performance  Configuração de hardware (incluindo rede)  Qualidade da aplicação (código)  Tempo de resposta do BD ou qualquer outro recurso externo (ex LDAP, WebServices)  Configuração do software ColdFusion Server e componentes relacionados (ex JVM)  Configuração do servidor web (IIS, Apache), incluindo sistema operacional
  4. 4. 4 Considerações sobre Hardware  Para aqueles acostumados com versões pré ColdFusion Server 5, uma má notícia: o CFMX consume MUITO mais memória (mas também é mais rápido!)  MHzs extras nunca é demais, porém priorize o seu gasto em memória e armazenamento confiáveis. Depois, se sobrar, compre o processador (MHz) topo de linha
  5. 5. 5 Considerações sobre Hardware  Os templates são temporariamente armazenados na memória física, portanto um bom servidor deve ter:  Boa quantidade de memória RAM (recomendado: 1Gb ou mais)  RAM com boa velocidade de acesso (recomendação: memórias DDR/Rambus, etc)  Memória de processador (cache) grande. Um PIII 1Ghz Mhz com 512k de cache é “melhor” do que um P4 de 1.5 Ghz com 256K de cache ou um esquentado Duron 2Ghz com apenas 128k
  6. 6. 6 Considerações sobre Hardware  Discos rígidos rápidos e confiáveis (arquitetura RAID ou SCSI), exclusivos para o armazenamento de templates (separar do disco onde estão instalados aplicativos e outros componentes do servidor) – Instalar o CFMX (pasta cfclasses) no disco SCSI (D:)?  Uma rede que suporte o volume de transações esperado, com baixa latência e boa velocidade
  7. 7. 7 Considerações sobre Software  Vamos falar de plataforma Windows (80% dos casos em CFMX)  IIS ainda é o melhor e mais rápido webserver para plataforma Windows, não invente moda!  Java é relativamente mais rápido sob Windows do que em Linux (melhor suporte à threads). Em termos de performance para Java, temos: Solaris<Windows<Linux<FreeBSD. Isso tende a mudar com o tempo
  8. 8. 8 Considerações sobre Software  Dê trabalho ao IIS, não ao CFMX! Templates de erros http genéricos tais como 404, 500 devem ser lidados pelo IIS, não pelo CFMX. Lembre-se de que muitas vezes os acessos inválidos (404) gerados por scanners e worms como Nimba, RedCode, etc, são muitas vezes maiores que os acessos normais ao um site (use um “UrlScan”, vale a pena);  Use o connector mais recente (Updater 3);
  9. 9. 9 Considerações sobre Software  Remova todas as extensões que você não for usar (.asp, .jsp, etc);  Dê prioridade (“suba”) ao filtro ISAPI do ColdFusion “JRunConnector” nas propriedades gerais do IIS e remova os filtros desnecessários (ex. printer, etc);  Faça o mesmo para os documentos padrões (index.cfm, default.cfm, etc);
  10. 10. 10 Considerações sobre Software  Marque a opção “Check that file exists” nas propriedades da aplicação do IIS  Para maior estabilidade, crie uma dependência em nível de serviço entre o IIS e o ColdFusion MX Application Server ou use um software de checagem como o Servers Alive (free até dez processos/serviços)  Dê prioridade às aplicações de fundo (background applications)  Otimize as configurações de TCP/IP no registro (veja referências)  Otimize as configurações do IIS no registro (veja em referências)
  11. 11. 11 Considerações sobre Software  Aumente a área de swap do log do IIS para poupar repetidos acesso ao disco rígido (veja links abaixo)  Os logs devem ser gravados numa partição de disco separada  Configure sua placa de rede para usar o máximo número de buffers permitido  Disabilite quaisquer serviços inúteis (ex. Messenger, Alerter etc)  Fique ligado nos patches! Além de serem correções de segurança, são correções de performance também
  12. 12. 12 Considerações sobre Software  ColdFusion MX StandAlone é um servidor Java Enterprise (J2EE), baseado numa versão modificada do JRun  A otimização da JVM trará reflexos para a performance do ColdFusion  Você pode obter grandes ganhos de desempenho se trocar a sua JVM de 1.3.1_03 (Sun), que vêm como default no CFMX, para uma mais nova tal como a 1.4.2_02 (Sun) ou mesmo de um fabrincante como a IBM (1.3.1), Rockit (1.2), Bea, etc, porém TESTE!  Use o JVM HotSpot Server, não o Client (usado como default). A troca é simples e existem ganhos de aproximadamente 20- 30% na velocidade de resposta usando o “HotSpot Server VM”  Para se considerar: arquitetura do Pentium III é mais rápida nas versões Java 1.0 a 1.3
  13. 13. 13 Considerações sobre Software  Tempo de compilação (e gravação) - primeiro carregamento de um template - do fonte Java (gerado pelo CFMX) para Java byte-code pode ser melhorado atualizando a sua versão do “jikesw.exe” para um compilador mais rápido (eg. IBM Jikes, free)  Configure corretamente as opções de “Initial heap size” e “maximum heap size”, de acordo com o seu hardware e o tamanho de suas aplicações  Idealmente estes valores devem ser idênticos, porém lembre- se do ponto acima  Cuidado! Configurando um heap mais alto do que o necessário corre-se o risco de ter extrema lentidão – swap de memória em disco  Configurando para “baixo”, obriga um número grande de drops e até mesmo erros de java.lang.OutOfMemoryError
  14. 14. 14 Considerações sobre Software  Opções do CFServer Administrator:  Simultaneos Requests: idealmente o número de requests atendidos pelo ColdFusion deve ser de 2 a 3 requests POR PROCESSADOR. O CFMX vêm como default com o número 8 marcado. Mude para 2 ou 3 se você tiver apenas um processador e 4 e/ou 6 caso seja um bi-processado. Metáfora da Ferrari e do Caminhão  Trusted Cache: use em servidores de produção!  Debuging: desligue em servidores de produção!  Client variables: use um RDBMS para armazenar!  Desabilite serviços não utilizados do ColdFusion (eg. ODBC Server e Agent) se você não usa ODBC
  15. 15. 15 Considerações sobre recursos externos  Por favor, NÃO use Access quando você puder usar MySQL, SQL Server e outros RDBMS de verdade  Prefira drivers certificados e Type4 (puramente em Java) para os seus drivers JDBC  Se sentir que há melhorias, use um driver JDBC diferente (ex: MySQL JDBC, Microsoft SQL Server JDBC driver, etc) dos que vêm como padrão no CFMX. Isso inclusive pode habilitar algumas particularidades (ex: triggers em SQL Server) que não estão disponíveis com o driver JDBC padrão do CFMX
  16. 16. 16 Considerações sobre recursos externos  Prefira usar números de IP puros ao invés de hosts em conexões na configuração de datasources externas. Isso elimina um passo (resolução do host para IP pelo CFMX) e pode previnir falhas de DNS quando estas existiram  Separe o servidor de banco de dados do seu servidor de aplicação CFMX  Tenha um canal de comunicação exclusivo entre estas duas máquinas (par trançado e cruzado não dá 100Mps!, prefira usar um switch)  Saiba desenhar/normalizar os seus bancos de dados!  Mantenha a conexão aberta com o seu BD!  Use e abuse das opções JDBC “direct” ou “cursor”
  17. 17. 17 Considerações sobre o seu código CFML  Fator mais determinante depois do hardware  Coloque sempre o escopo das suas variáveis  Use e abuse das diferentes formas de caching (cached queries, escopos de aplicação/sessão, cfcache etc)  Dê trabalho ao banco de dados, não ao CFServer. Use funções do banco (eg. GetDate()) ao invés de funções do CFMX (ex. #Now()#)  Use storedprocedures e/ou <cfqueryparam> ao invés de queries puras sempre que possível  Saiba usar parâmetros extras e altamente recomendáveis tais como blockfactor
  18. 18. 18 Considerações sobre o seu código CFML  Evite loops exagerados  Prefira CFOUTPUT QUERY=“” ao invés de CFLOOP QUERY=“” (cfmx)  Evite sequencias longas de cfif/cfelses/cfelseifs, cfswitch/cfcase é muito mais rápido  Em situações simples (um CFIF e um CFELSE), prefira a função Iif()  Evite usar “Evaluate()” para acessar o valor de variáveis complexas. Acesse-os usando notação de brakets (ex: “#Estrutura[valor_dinamico]#”) (cfmx)  Dimensione suas Arrays antes de populá-las com grandes volumes de dados  <CFSET variavel=outra_variavel> ao invés de <CFSET variavel=#outra_variavel#>
  19. 19. 19 Considerações sobre o seu código CFML  Remova <CFLOCKS> desnecessários, lembre-se de que o CFMX é thread safe  Prefira usar números de IP puros ao invés de hosts em conexões com CFHTTP, CFPOP, Consumo de WebService. Isso elimina um passo (resolução do host para IP pelo CFMX) e pode previnir falhas de DNS quando estas existiram  Sempre olhe o seu application.log à procura de erros de aplicação e elimine-os!  Se não for necessário, não habilite a Advanced Security, ela acarreta em performance menor em comparação com uma box em “Basic Security”
  20. 20. 20 Considerações sobre o seu código CFML  Não contorne um problema criando outro. Aprenda a usar os recursos do CFMX (eg. Esquemas de autenticação próprios versus CFLOGIN) e não faça uso subterfúgios para contornar a ausência de conhecimento sobre uma determinada feature/tag/função (ex: usar listas ao invés de arrays, usar ifs ao invés de cfswitch, usar loops absurdos para criar listas de valores ao invés de funções simples tais como “ArrayToList(nome_query[“nome_campo”])”  Não reinvente a roda, procure soluções já prontas, disponíveis e testadas (Macromedia DevNet!)  Faça testes de carga na sua aplicação!
  21. 21. 21 O que é um teste de carga?  Uma ciência obscura e cheia de mistérios?  Uma arte dominada por geeks e nerds?  Perfeccionismo?  Exclusivo de aplicações com muito tráfego e/ou volume de transações?  Algo sempre deixado por último?  Ajuda a responder quanto (volume) a sua aplicação/servidor podem suportar
  22. 22. 22 Porquê fazer testes de carga nas suas aplicações?  O que custa mais?  Descobrir que a aplicação “trava”  Antes de ser disponibilizada?  Depois de ser disponibilizada?  Modificar seu parque de hardware  Depois de tê-lo montado?  Antes de tê-lo montado?  Lembre-se da velha máxima: prevenir é melhor que remediar
  23. 23. 23 Testes de carga, como fazê-los  Em aplicações JSP/Servlet usa-se, preferivelmente, carga sobre HTTP em oposição a outros métodos existentes de performance Java (ex transaction-based metrics - EJB)  Usando um simulador de carga sobre um “script” pré-determinado na sua aplicação  Microsoft Web Stress Application Tool é gratuíto e cumpre bem a tarefa
  24. 24. 24 Testes de carga, como fazê-los  Defina um “script” clássico dentro do seu site ou aplicação  NÃO adianta ficar estressando templates únicos, isso nada vai te mostrar como o seu servidor se comporta sob carga real  NÃO adianta olhar quanto de CPU seu servidor alvo do teste está consumindo. Estressar um servidor não é sinônimo de estressar uma aplicação
  25. 25. 25 Microsoft WAST
  26. 26. 26 Microsoft WAST  Preferivelmente rode o aplicativo em outra máquina que não a alvo do teste  Testes curtos não são significativos, comece com pelo menos 30 minutos  Faça os seus testes comportarem-se de forma mais real possível, insira intervalos entre os “cliques” e “warmups”. Você está testando a sua aplicação em primeiro lugar, depois o servidor
  27. 27. 27 Microsoft WAST  Métricas básicas informadas nos resultados:  Número de hits  Número de requests por segundo  Número de usuários atentidos (threads X sockets)  Estatística dos estatus requests retornados (200, 500)  Estatística detalhada de cada request, incluindo:  Hits  TTFB (Total Time First Byte is Received) - média  TTLB (Total Time Last Byte is Received) - média
  28. 28. 28 Microsoft WAST
  29. 29. 29 Como interpretar os resultados?  Os testes de carga devem ser realizados sempre confrontando um situação existente ou desejada  O número de usuários esperados  O throughput que o seu hardware suporta  A mesma aplicação rodando sob outras condições (configurações de JVM, por exemplo)  Pergunta básica: quanto (usuários? conexões?, transações?) minha aplicação suporta?  Métricas básicas para dar a resposta:  Número de usuários  Número de hits/pageviews  Número de requests corretamente atendidos
  30. 30. 30 Como interpretar os resultados? Exemplo  Hardware utilizado  Pentium 3 933 Ghz (256k de cache L2)  512 Gb de RAM (133 Mhz)  Aplicação utilizada  Macromedia PetMarket BluePrint Application 1.2 (versão para CFML)  Script 4 (inclui sessão) – vide referências  Banco de dados  Microsoft SQL Server 2000  Servidor ColdFusion  ColdFusion MX Professional (“as is”)  ColdFusion MX Professional com Updater 3
  31. 31. 31 Como interpretar os resultados? Exemplo  Resumo de resultados  Nitidamente obtem-se uma performance 30% a 40% superior apenas modificando-se o JVM e o updater 3 em ColdFusion MX (CFCs?)  Em alguns testes é comum encontrar requests falhando, este é um bom indicador de que sua aplicação está com algum problema, veja os logs!  Imagine um hardware mais poderoso
  32. 32. 32 Como interpretar os resultados?  JVM 1.3.1 (client hotspot), CFMX 6.0, Windows 2000/IIS, rodando PetMarket application em CFML durante 2 horas sem intervalo de cliques  466.201 requests status 200  90 usuários servidos por segundo  33,88 requests por segundo  3 requests queued por segundo em média  JVM 1.4.2 (server hotspot), CFMX 6.0 (updater3), Windows 2000/IIS, rodando PetMarket application em CFML durante 2 horas sem intervalo de cliques  778.780 requests status 200  90 usuários servidos por segundo  59,60 requests por segundo  2 requests queued por segundo em média
  33. 33. 33 Referências  ColdFusion MX: Tips for performance and scalability http://www.macromedia.com/support/coldfusion/ts/documents/cf mx_perf_tips.htm  ColdFusion Performance Tuning http://www.macromedia.com/support/coldfusion/ts/documents/t n17054.htm  ColdFusion Performance Tuning (part 2) http://www.macromedia.com/support/coldfusion/ts/documents/t n17125.htm  ColdFusion Tech Tips http://www.macromedia.com/support/coldfusion/ts/documents/t n17462.htm  Macromedia BluePrint PetMarket Application http://www.macromedia.com/devnet/mx/blueprint/
  34. 34. 34 Referências  Windows platform-specific performance settings http://www.macromedia.com/support/coldfusion/ts/documents/t n17277.htm  Improving Java Application Performance and Scalability by Reducing Garbage Collection Times and Sizing Memory http://wireless.java.sun.com/midp/articles/garbage/  Improving Java Application Performance and Scalability by Reducing Garbage Collection Times and Sizing Memory Using JDK 1.4.1 http://wireless.java.sun.com/midp/articles/garbagecollection2/  Java HotSpot VM Options http://java.sun.com/docs/hotspot/VMOptions.html  ColdFusion MX Performance Brief http://www.macromedia.com/software/coldfusion/whitepapers/p df/cfmx_performance_brief.pdf
  35. 35. 35 Boas novas para o ColdFusion MX 6.1  Apresentação MM

×