Performance e disponibilidadeColdFusion MX 6.1 ServerEstudo de caso: Correios
Alex [email protected] User Group de São Paulo
VISITE O CFGIGOLÔ – http://www.cfgigolo.com
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)?
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
Como o ColdFusion funciona – A arquitetura (resumo)
J2EE Infrastructure
ColdFusion MX
ColdFusion Language Compiler
Charting and Graphing
Full-TextSearch
FlashRemoting
WebServices
Como o ColdFusion funciona - O runtime (resumo)
ColdFusion Language Runtime
ColdFusionPages & CFCs
InitialRequest
SubsequentRequests
Java Bytecode
Web Container
HTTPRequest Compilation
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?
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
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
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!
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
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!?!
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
1ª ETAPA: arquitetura (simplificada) de servidores que encontramos
Internet 100Mps100Mpbs
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
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
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)
2ª ETAPA: cluster virtual usando múltiplas instâncias de ColdFusion
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, duplicandoo ambiente existente
Antes
2ª ETAPA: arquitetura (simplificada) de servidores que deixamos
Internet 100Mps100Mpbs
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
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!
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!)
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
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çãon
Teste de cargan
Setting/códigoResultados“Fotografia”
Análisecomparativa
Setting/códigoAplicado/aprovado MELHOR (avanço)
PIOR (retorno)
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
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!
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)
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
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)
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)...
Dúvidas?
Obrigado!
(se tivermos tempo, vamos falar de Adobe e CF?)
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
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
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