Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

Performance tunning de servidores ColdFusion MX

381 Aufrufe

Veröffentlicht am

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

Veröffentlicht in: Software
  • Als Erste(r) kommentieren

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

×