Macromedia
ColdFusion MX
Tunning
Alex Hübner – CFUG-SP/Friends of The Earth
alex@hubner.org.br
http://www.cfugsp.com.br
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Microsoft WAST
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
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
Microsoft WAST
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
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
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
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
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
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
Boas novas para o ColdFusion MX 6.1
 Apresentação MM

Performance tunning de servidores ColdFusion MX

  • 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 Lembrando do nossoamigo 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 Principais fatores queinfluenciam 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 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 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 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 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 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 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 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 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 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 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 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 Considerações sobre recursosexternos  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 Considerações sobre recursosexternos  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 Considerações sobre oseu 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 Considerações sobre oseu 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 Considerações sobre oseu 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 Considerações sobre oseu 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 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 Porquê fazer testesde 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 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 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.
  • 26.
    26 Microsoft WAST  Preferivelmenterode 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 Microsoft WAST  Métricasbá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.
  • 29.
    29 Como interpretar osresultados?  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 Como interpretar osresultados? 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 Como interpretar osresultados? 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 Como interpretar osresultados?  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 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 Referências  Windows platform-specificperformance 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 Boas novas parao ColdFusion MX 6.1  Apresentação MM