Performance e disponibilidadeColdFusion MX 6.1 ServerEstudo de caso: Correios

Alex Hubneralex@cfugsp.com.brColdFusion 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