[1] O documento descreve uma estratégia implementada para melhorar o desempenho e disponibilidade de um site institucional dos Correios que rodava no ColdFusion. [2] A estratégia envolveu duplicar as instâncias do ColdFusion em cada servidor para melhor aproveitar os recursos, otimizar configurações do servidor e do banco de dados, e estabelecer rotinas de reciclagem noturna. [3] As mudanças permitiram dobrar a capacidade do ambiente existente sem necessidade de novos servidores.

1. Performance e disponibilidade
ColdFusion MX 6.1 Server
Estudo de caso: Correios
Alex Hubner
alex@cfugsp.com.br
ColdFusion User Group de São Paulo
VISITE O CFGIGOLÔ – http://www.cfgigolo.com

2. O que vamos falar hoje?
• Apenas do ColdFusion Server e relacionados
• Não vamos falar de codificação!
• E desejável que você já conheça o ColdFusion Server e saiba administrá-lo,
bem como suas principais características
• Um bom começo caso você não conheça o CF: http://www.cffaq.com
• Depois, assine a lista CF-Brasil: http://www.coldfusion.org.br (350 usuários!)
• Comentar um caso real de settings de arquitetura e ambiente em que
houveram melhorias significativas em performance e principalmente,
disponibilidade.
• O nosso “case” é o site institucional dos Correios
• Esta apresentação foi autorizada pelos mesmos, porém com ressalvas, por isso
não vou poder comentar e contar tudo o que gostaria
• Qual é o perfil da audiência (pool)?

3. O nosso bom e velho ColdFusion Server…
• É uma aplicação Java Enterprise (J2EE)
• É uma linguagem de programação rápida (RAD)
• Roda em servidores Java como BEA Logic, IBM Websphere, Tomcat e o próprio
Macromedia Jrun 4.0 (embutido)
• Sun Verified Java Application
• Multiplataforma (Linux, Windows, Solaris, MacOS, etc)
• Interoperável, suporte à muitos serviços e produtos externos tais como banco de
dados, softwares, COM, Corba, Java, etc
• Tecnologia madura. Tem 10 anos de vida. Foi criada pensando em web (TAGS),
diferente de outras linguagens, que são derivadas
• Uma das linguagens web mais usadas nos EUA (mais do que JSP e ASP.NET - dados
Netcraft Março 2005)
• Em poucas palavras: a melhor camada de produtividade para J2EE

4. Como o ColdFusion funciona – A arquitetura (resumo)
J2EE Infrastructure
ColdFusion MX
ColdFusion Language Compiler
Charting and
Graphing
Full-Text
Search
Flash
Remoting
Web
Services

5. Como o ColdFusion funciona - O runtime (resumo)
ColdFusion
Language Runtime
ColdFusion
Pages & CFCs
Initial
Request
Subsequent
Requests
Java
Bytecode
Web
Container
HTTP
Request Compilation

6. O ColdFusion é escalável? Tem boa performance? É estável?
• Sem rodeios: sim, totalmente!
• Por que? Me dê motivos...
• Para que eu iria mentir? Não ganho nada fazendo isso
• É Java. Dizer que ColdFusion não é escalável é o mesmo que dizer que Java
não é escalável
• MySpace.com – 7º site mais visitado de toda a internet (dados Yahoo! Finance – Março
2005) – roda ColdFusion MX 6.1 com Fusebox 3
• Macromedia.com – dispensa comentários
• Usado por 75% das companhias da lista Fortune 100 do mundo
• No Brasil, usado por empresas “pequenas” e descomprometidas, tais como
Embraer, Vivo, Itaú, VR Vales, Intelig, StarOne, FGV, UOL, Terra, entre outros
• Alguém sabe de algum outro exemplo?

7. Principais fatores que inflenciam a performance do CFMX
1. Qualidade do código rodando no servidor.
2. Qualidade do código...
3. Qualidade do código.....
4. Configurações e características de hardware (incluindo rede)
5. Configurações de recursos externos utilizados pela aplicação.
Exemplo: banco de dados, LDAP, SMTP, WebService
6. Configurações do ColdFusion Server e componentes
relacionados. Exemplo: JVM, Requests Simultâneos, Cache, etc
7. Configuração do servidor web e componentes relacionados.
Exemplo: IIS, Apache, alocação de memória RAM, threads, etc

8. E qual era o problema com o site dos Correios?
• O site estava com problemas de disponibilidade, com taxas inferiores a
98% mensais, inaceitáveis para um site da importância dos Correios
• O ColdFusion estava sendo “culpado” pelas quedas, uma vez que o
serviço que efetivamente caía (efeito) era o ColdFusion, porém
desconhecia-se a causa
• A Macromedia Brasil foi chamada, por intermédio da CTIS (empresa que
prestadora de serviços para os Correios) para uma consultoria e
consequente proposta de melhoria de ambiente, antes que se fizesse
investimento em mais servidores (caros) para o site institucional ou
partisse-se para uma outra solução mais radical (troca de tecnologia)
• A equipe de consultoria da Macromedia foi formada por Marcantonio
Silva, Douglas Camargo, Abilio Cipriano e Alex Hubner

9. O site dos Correios em números
• 4 servidores HP Quad-Xeon 3.06 com 4Gb de RAM clusterizados sob um load-
balancer Cisco
• ColdFusion MX 6.1 Enterprise Server Config (“stand alone”)
• Windows 2003 e IIS 6 como webserver (“limpos”)
• SQL Server e Oracle (em outros servidores separados)
• Pesadas consultas via HTTP à outros sistemas
• 7k-9k unique visitors POR HORA (média horário comercial)
• Logs de acesso diários com cerca de 1Gb de tamanho
• Mais de 5k scripts CFML
• Links em diversos sites, sistemas e afins (exemplo: consulta à CEP no programa de
IRPF, sites de e-commerce, etc)
• Em resumo: tráfego para ninguém botar defeito!

10. Como estruturamos o trabalho
• Frentes de trabalho (e seus respectivos produtos)
1. Qualidade de código das aplicações (não vamos falar )
• PRODUTO: códigos corrigidos e/ou novos visando (1) disponibilidade e (2)
performance
2. Ambiente de produção (vamos falar )
• PRODUTO: novo ambiente adequado às necessidades de (1) disponibilidade e (2)
performance
3. Metodologia de desenvolvimento e gerenciamento (não vamos falar )
• PRODUTO: nova metodologia para ambas as frentes acima, sempre visando (1)
disponibilidade e (2) performance
• Cada frente foi divida em 4 etapas consecutivas (e seus prazos):
1. Análise do problema
2. Discussão e definição de uma estratégia para solução do problema
3. Validação da estratégia escolhida em ambiente separado/controlado
4. Aplicação da estratégia em produção, monitoramento e finalização do
projeto

11. 1ª ETAPA: a análise
• Logs, sempre eles...
• Os servidores ficaram cerca de 2 semanas em observação e intensa coleta de logs
(gastou-se um HD inteiro com isso...)
• O monitoramento foi dividido em:
• Ativo: a var tempo é eliminada, mostrando a situação momentânea
• “Como o servidor está se comportando agora, no horário de pico?”...
• “Veja que comportamento estranho da CPU agora”...
• Serve apenas para se “cheirar” o que pode estar acontecendo, não permite apontar culpados (prematuro
demais fazê-lo, apesar de muitos fazerem só isso)
• Só permite correlacionar dados com outros monitores ativos no momento (ex: CPU graph)
• Exemplo de ferramenta: CFSTAT, crt+alt+del...
• Histórico: mostra a evolução do servidor ao longo do tempo
• “Como o servidor se comportou ao longo da semana, correlacionando-se os dados de (por exemplo) o
número de threads do CF com o número de page-views à páginas CF pelos dados do Webtrends?”
• Dá pistas decentes sobre o que pode estar acontecendo e direciona a investigação (as vezes para o lado
errado, mas aí é só voltar...)
• Te faz dar tiros mais certeiros e sanar o problema usando 80% cérebro e 20% força bruta (apesar de eu ser
um adepto entusiasmado do “arranca tudo e instala de novo”)...
• É mais “bonito” e enche relatório com dados coletados, sem aproximações
• Exemplo de ferramenta: Jrun Metrics
• O segredo é CORRELACIONAR DADOS para decifrar a misteriosa pergunta que nos tira
o sono: que raios está acontecendo com esta máquina!?!

12. 1ª ETAPA: as conclusões da análise
• Rapidamente percebeu-se que o maior culpado pelas quedas era a aplicação...
(novidade... lembrem-se do “fatores que influenciam”). E como?
• Os logs são cruéis e apontam:
• Scripts levando cerca de 33.034 segundos para ser executadas (sim, são quase 10 horas...): há algo errado aí!
• Ausência de um controle de qualidade (deploy sem controle)
• Criação “em cascata” de variáveis de sessão (para armazenar coisas como datasources names, por exemplo)
• Ausência de controles de erro do tipo cftry/cfcatch em rotinas que envolviam recursos externos (exemplo:
consulta à banco de dados)
• Extensivo uso de loopings em queries ao invés de INNER JOINS
• Etc.. (papo para outro dia)
• Nós não vamos falar de código (torrem o saco do Abílio Cipriano ...). Por isso, no que
tange o ambiente, notamos que:
• O Hardware era subutilizado (baixa utilização de memória e CPU e isso poderia ser melhorado
substancialmente)
• As quedas do servidor não estavam necessariamente relacionadas à carga enfrentada (olha a
correlação de dados). O servidor apresentava problemas mesmo sob baixa demanda.
• A aplicação conseguia deteriorar a saúde do servidor até o ponto de derrubá-lo completamente
(efeito “bola de neve”)
• Configuração do ColdFusion não era totalmente otimizada para o tipo de aplicação existente (ex:
JVM arguments usando settings inúteis e “legados” de outras versões MX 6.0)
• O sistema operacional (Windows 2003) e o webserver (IIS6) poderia ser melhorado visando o
máximo desempenho dos servidores ColdFusion

13. 1ª ETAPA: arquitetura (simplificada) de servidores que encontramos
Internet 100Mps
100Mpbs
Roteador e
balanceador
De carga
Banco de dados de
diversos sabores
Pool de servidores web com
16 CPUS e 16Gb de RAM,
sendo utilizados 4GB
COLDFUSION STANDALONE:
.Única instância
.Apenas 1GB de RAM;
.Sem tunning de JVM
.Sem recycle

14. 2ª ETAPA: discussão e definição de estratégia de ambiente
• O problema estava com o código, mas a configuração de ambiente
pode (e deveria) ser refeita visando o controle (no sentido de
segurar) do código “rebelde” da melhor forma possível, minimizando
quedas ocasionadas por má codificação
• Não iríamos mexer com hardware, o que existia era suficiente e não
teria sentido a consultoria dizer: “botem aí mais dois servidores no
cluster que vai resolver o ‘pobrema’ chefia”...
• Não iríamos mexer com o software (código CFML e banco de dados)
de forma expressiva, apenas corrigir gargalos óbvios e mortais (me
perguntem no final quais foram as aplicações que foram alteradas)
• Deveríamos consertar o motor com ele em funcionamento, o carro
(site) não poderia encostar na oficina e ficar lá por uns dias

15. 2ª ETAPA: discussão e definição de estratégia de ambiente
• Adotar múltiplas instâncias de ColdFusion com JRun 4.0, melhorando o
aproveitamento do hardware existente, permitindo “dobrar” o parque de
recursos disponíveis com a criação, em cada máquina, individualmente, de
um cluster de duas instâncias idênticas (vide próximos dois slides)
1. O Windows te “toma” metade da RAM disponível para seu kernel, deixando
somente 2Gb livres (cada máquina tinha 4Gb). É possível contornar, mas (veja
itens 6 e 7 abaixo)
2. Destes 2Gb só 1.8Gb podem ser usados pelo JVM (limitação da arquitetura 32 bits
– endereçamento de memória contínua)
3. Criamos duas instâncias de 1Gb cada
4. A aplicação não podia ser desmembrada em instâncias por páginas/pastas
específicas, tinha que se manter um “bloco” único
5. Poderiam ser 4 de 512Mb? Sim, mas o tipo de aplicação que tínhamos era do tipo
que gosta de comer memória, com isso 512Mb separados em 4 partes poderia ser
um gargalo maior do que duas partes de 1Gb. Lembrar que uma instância não
“sabe” que a outra existe, é um abstração completa, literal, do servidor
6. São 4 máquinas no total, vezes 4 instâncias em cada = 16 instâncias para cuidar.
Muito complexo e trabalhoso
7. Existiam aplicações ASP e .NET no mesmo servidor, não poderíamos deixá-las com
apenas 1Gb de RAM (usam a do kernel do Windows)

16. 2ª ETAPA: cluster virtual usando múltiplas instâncias de ColdFusion

17. 2ª ETAPA: discussão e definição de estratégia de ambiente
cfusion1 - 1GB
cfusion2 - 1GB
cfusion1 - 1GB
cfusion2 - 1GB
cfusion1 - 1GB
cfusion2 - 1GB
cfusion1 - 1GB
cfusion2 - 1GB
Depois, duplicando
o ambiente existente
Antes

18. 2ª ETAPA: arquitetura (simplificada) de servidores que deixamos
Internet 100Mps
100Mpbs
Roteador e
balanceador
De carga
Banco de dados de
diversos sabores
Pool de servidores web com
16 CPUS e 16Gb de RAM,
sendo utilizados 8GB
COLDFUSION SOB JRUN
.Duas instâncias
.2GB de RAM para solução;
.Tunning de JVM
.Recycle noturno

19. 2ª ETAPA: discussão e definição de estratégia de ambiente
• Otimizar settings do ColdFusion Server visando melhorar a disponibilidade
(em outras palavras: deixar o CFMX mais “resistente” à quedas em
decorrência da aplicação mal escrita)
• Reformulação de argumentos JVM (o uso do JVM Stat e do Visual GC foi
fundamental nesta etapa, bem como suporte da Macromedia USA)
• AgressiveHeap
• MaxPermSize
• Xss
• Etc
• Uso da última JVM (Sun 1.4.2_08) por questões de performance e bugs
confirmados pela própria Macromedia USA
• Consolidação de settings do CFMX tais como
• Simultaneous requests
• Template caches
• Últimos patches/hotfixes e drivers JDBC
• Maximum templates
• Trusted cache
• Etc, etc... (daria uma apresentação inteira – que tal a próxima?)
• Segurança também!

20. 2ª ETAPA: discussão e definição de estratégia de ambiente
• Estabelecimento de uma rotina de “recycle” nos servidores
• Instância por instância, de forma seqüencial
• Via Windows Schedule tasks
• No período de menor movimento (madrugada)
• Sem perda de conexão para quem visita no momento (lembre-se que é um cluster)
• Muito importante para promover uma limpeza de dead-locks e threads presos que
causavam o efeito “bola de neve”
• Processo todo dura cerca de 30 minutos, o “pool” de atendimento conta com 7
instâncias, ao invés de 8 (bastante razoável, ainda mais para o horário)
• Otimizações diversas no webserver (IIS6) e no servidor (Windows 2003)
• Dar prioridade ao filtro ISAPI do CFMX
• Tweaks no registry para melhorar performance
• Eliminação do swap em disco do Windows (para previnir JVM de usá-lo)
• Algumas outras (papo para outro dia também!)

21. 3ª ETAPA: validação da estratégia
• Separamos uma das 4 máquinas em produção e destinamos como “cobaia” (piloto)
• Período (uma semana) de tensão, pois contávamos com apenas três máquinas no pool
• Várias quedas...  mas não muito diferente do que vinha acontecendo, e o prejuízo se justificava:
• Aderência à realidade, com uma máquina idêntica e em ambiente de produção
• Testes de performance extensos, porém não 100% precisos por não haver isolamento de rede (citar
teste de carga com switch específico e isolado) e de banco de dados em produção. Métricas usadas:
• “Script” (tour e sessão de usuário tradicional) padronizado;
• Requests respondidos com status de sucesso (200) e com status de erro (500, 401, etc)
• TTFB, TTLB (time to first byte, time to last byte): throughput
• Outras (papo para outro dia...) 
• Não pudemos estressar toda a aplicação devido a características que nos impediam (ex:
cacheamento de serviços externos – consulta CEP – tag <BASE HREF> em muitos locais), etc.
• Em oposição criamos alguns scripts especiais que simulavam o comportamento normal da aplicação,
porém bypassando a limitação que poderia mascarar e descaracterizar o teste de performance

22. 3ª ETAPA: validação da estratégia
• Implementações paulatinas de
melhorias com aferimento de
resultados com base em testes de
carga e “fotografias”. Fluxo:
Modificação -> Teste de Carga -> “Fotografia” de
resultados -> Comparação -> Adoção/Descarte
Modificação
n
Teste de carga
n
Setting/código
Resultados
“Fotografia”
Análise
comparativa
Setting/código
Aplicado/aprovado MELHOR (avanço)
PIOR (retorno)

23. 4ª ETAPA: implementação em produção e monitoramento
• Bem, não há muito o que falar. Bastou repetir o que foi feito no
ambiente de validação (3ª ETAPA) nas máquinas restantes (3)
• Num primeiro final de semana, configurou-se uma máquina
adicional e voltou-se à que estava fora para o pool, restando
duas com a nova configuração, duas com a configuração antiga
• No final de semana seguinte fez-se o deploy nas outras duas
restantes
• Não houve interrupção no serviço, o site continuou no ar
durante toda a migração

24. Ferramentas que usamos para o trabalho
• Um pouco de suporte Macromedia USA (stack traces)
• Muita pesquisa (algumas fontes no final)
• Teste de cargas: Microsoft Web Stress Application Tool
• JRun Metrics (extremamente detalhados)
• Logs do ColdFusion
• Excel: planílhas e gráficos imensos, para correlação de dados das
fotografias
• Windows performance monitor (também extremamente detalhados)
• JVM Stat e Visual Garbage Collector (para otimização de JVM)
• Bom senso e experiência!

25. Resumo da ópera
1. Aperfeiçoamento da arquitetura de servidores, criando divisões
mais eficientes (e por conseqüência eficazes), fazendo uso de
múltiplas instâncias e clusters virtuais
2. Aperfeiçoamento dos settings do servidor de aplicações
ColdFusion MX 6.1 e do servidor (Windows 2003 e IIS 6.0)
visando solucionar o minimizar o problema das quedas. Nesta
etapa contamos com a ajuda de engenheiros da Macromedia USA
(envio de logs e análises específicas de stack-traces)
3. Criação de um processo de reciclagem dos servidores para
eliminar dead-locks gerados pela aplicação ruim (que não seria
significativamente alterada)

26. E como ficou? Deu certo?
• Sim!  cóf, cóf.... (tosse aristocrática)
• Estamos há 2 meses (desde a finalização da consultoria) com
disponibilidade de 99,98%, sendo que os 0,02% são decorrentes de
problemas de rede (conexão CF-DB) e afins
• O throughput está bastante adequado (e foi inclusive melhorado
consideravelmente)
• Os índices de disponibilidade estão dentro do desejado
• Cumprimos os prazos e excedemos as expectativas
• Aprendemos (ambos – consultoria e Correios) com o trabalho
• Documentamos tudo
• Treinamos o pessoal

27. Próximos passos
• “Recauchutagem” e melhorias diversas nas aplicações existentes
• Migração para CF 7 - gerência de clusters e instâncias bem mais
simples e performance melhorada
• Consolidação de metodologias de deploy, quality assurance, etc
• Aprofundamento do treinamento
• Replicar a estratégia em outros ambientes CF (intranet, por
exemplo)

28. Agradecimentos
• À equipe dos Correios, fizemos uma grande parceria!
• À Macromedia Brasil;
• À CTIS;
• À ContentObjects - Marcan;
• Ao Douglas, amigo de todas as horas e profissional referência
para mim
• Ao Fabrício pela excelente organização e empenho neste evento
• À todos vocês por assistirem! 
• E claro... ao meu capo/chefe mór na ADT, pela paciência em me deixar faltar tanto ao
trabalho para ir à Brasília, apesar de seus esporros e esperneios (Italianos são assim
mesmo)...

29. Dúvidas?

30. Obrigado!
(se tivermos tempo, vamos falar de Adobe e CF?)

31. Referências de ambiente utilizadas na consultoria:
[01] http://www.petefreitag.com/item/179.cfm
[02] http://www.petefreitag.com/archive/2004/6.cfm
[03] http://www.robisen.com/index.cfm?mode=entry&entry=FD4BE2FC-55DC-F2B1-FED0717CC1C7E0AF
[04] http://www.robisen.com/index.cfm?mode=entry&entry=39E0B0C6-55DC-F2B1-FBBDB70CEC963D6D
[05] http://livedocs.macromedia.com/jrun/4/JRun_Administrators_Guide/netmon.htm
[06] http://www.sumoc.com/blog/index.cfm?mode=entry&entry=CDCDBF8B-5004-2066-B7460CDEAB79328F
[07] http://gregs.tcias.co.uk/server
[08] http://www.unixville.com/%7Emoazam/stories/2004/05/18/visualizingGarbageCollection.html
[10] http://www.bpurcell.org/blog/index.cfm?mode=entry&entry=967
[11] http://www.macromedia.com/cfusion/knowledgebase/index.cfm?id=tn_18540
[12] http://www.macromedia.com/cfusion/knowledgebase/index.cfm?id=tn_18339
[13] http://www.macromedia.com/cfusion/knowledgebase/index.cfm?id=tn_18349
[14] http://www.macromedia.com/cfusion/knowledgebase/index.cfm?id=tn_18744

32. Referências de ambiente utilizadas na consultoria:
[15] http://www.petefreitag.com/articles/gctuning/
[16] http://java.sun.com/docs/hotspot/VMOptions.html
[17] http://java.sun.com/docs/hotspot/gc1.4.2/faq.html
[18] http://java.sun.com/j2se/1.4.2/docs/tooldocs/solaris/java.html
[19] http://java.sun.com/performance/jvmstat/windows.html
[20] http://www.petefreitag.com/item/141.cfm
[21] http://support.microsoft.com/default.aspx?scid=kb;EN-US;840875
[22] http://www.houseoffusion.com/cf_lists/messages.cfm/threadid:731/forumid:14
[23] http://livedocs.macromedia.com/jrun/4/JRun_Administrators_Guide/jrundotxml2.htm
[24] http://www.robisen.com/index.cfm?mode=entry&entry=FD4BE2FC-55DC-F2B1-FED0717CC1C7E0AF
[25] http://www.macromedia.com/support/coldfusion/adv_development/config_builtin_webserver/
[26] http://www.macromedia.com/cfusion/knowledgebase/index.cfm?id=tn_17277

33. Referências de ambiente utilizadas na consultoria:
• Publicações:
[01] Advanced ColdFusion MX 6.1 Application Development, Ben
Forta et al – ISBN 0321127102
[02] Java for ColdFusion Developers, Eben Hewitt – ISBN
0130461806
[03] Hack Proofing ColdFusion, Greg Meyer et al – ISBN
1928994776
[04] Cover your Ass – Securing IIS 6.0, Chun Hai (Bernard)
Cheah et al – ISBN 1931836256