Performance e disponibilidade
ColdFusion MX 6.1 Server
Estudo de caso: Correios
Alex Hubner
alex@cfugsp.com.br
ColdFusion ...
O que vamos falar hoje?
• Apenas do ColdFusion Server e relacionados
• Não vamos falar de codificação!
• E desejável que v...
O nosso bom e velho ColdFusion Server…
• É uma aplicação Java Enterprise (J2EE)
• É uma linguagem de programação rápida (R...
Como o ColdFusion funciona – A arquitetura (resumo)
J2EE Infrastructure
ColdFusion MX
ColdFusion Language Compiler
Chartin...
Como o ColdFusion funciona - O runtime (resumo)
ColdFusion
Language Runtime
ColdFusion
Pages & CFCs
Initial
Request
Subseq...
O ColdFusion é escalável? Tem boa performance? É estável?
• Sem rodeios: sim, totalmente!
• Por que? Me dê motivos...
• Pa...
Principais fatores que inflenciam a performance do CFMX
1. Qualidade do código rodando no servidor.
2. Qualidade do código...
E qual era o problema com o site dos Correios?
• O site estava com problemas de disponibilidade, com taxas inferiores a
98...
O site dos Correios em números
• 4 servidores HP Quad-Xeon 3.06 com 4Gb de RAM clusterizados sob um load-
balancer Cisco
•...
Como estruturamos o trabalho
• Frentes de trabalho (e seus respectivos produtos)
1. Qualidade de código das aplicações (nã...
1ª ETAPA: a análise
• Logs, sempre eles...
• Os servidores ficaram cerca de 2 semanas em observação e intensa coleta de lo...
1ª ETAPA: as conclusões da análise
• Rapidamente percebeu-se que o maior culpado pelas quedas era a aplicação...
(novidade...
1ª ETAPA: arquitetura (simplificada) de servidores que encontramos
Internet 100Mps
100Mpbs
Roteador e
balanceador
De carga...
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...
2ª ETAPA: discussão e definição de estratégia de ambiente
• Adotar múltiplas instâncias de ColdFusion com JRun 4.0, melhor...
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
cfus...
2ª ETAPA: arquitetura (simplificada) de servidores que deixamos
Internet 100Mps
100Mpbs
Roteador e
balanceador
De carga
Ba...
2ª ETAPA: discussão e definição de estratégia de ambiente
• Otimizar settings do ColdFusion Server visando melhorar a disp...
2ª ETAPA: discussão e definição de estratégia de ambiente
• Estabelecimento de uma rotina de “recycle” nos servidores
• In...
3ª ETAPA: validação da estratégia
• Separamos uma das 4 máquinas em produção e destinamos como “cobaia” (piloto)
• Período...
3ª ETAPA: validação da estratégia
• Implementações paulatinas de
melhorias com aferimento de
resultados com base em testes...
4ª ETAPA: implementação em produção e monitoramento
• Bem, não há muito o que falar. Bastou repetir o que foi feito no
amb...
Ferramentas que usamos para o trabalho
• Um pouco de suporte Macromedia USA (stack traces)
• Muita pesquisa (algumas fonte...
Resumo da ópera
1. Aperfeiçoamento da arquitetura de servidores, criando divisões
mais eficientes (e por conseqüência efic...
E como ficou? Deu certo?
• Sim!  cóf, cóf.... (tosse aristocrática)
• Estamos há 2 meses (desde a finalização da consulto...
Próximos passos
• “Recauchutagem” e melhorias diversas nas aplicações existentes
• Migração para CF 7 - gerência de cluste...
Agradecimentos
• À equipe dos Correios, fizemos uma grande parceria!
• À Macromedia Brasil;
• À CTIS;
• À ContentObjects -...
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.petefreita...
Referências de ambiente utilizadas na consultoria:
[15] http://www.petefreitag.com/articles/gctuning/
[16] http://java.sun...
Referências de ambiente utilizadas na consultoria:
• Publicações:
[01] Advanced ColdFusion MX 6.1 Application Development,...
Próximos SlideShares
Carregando em…5
×

Performance e disponibilidade ‐ Um estudo de caso: website dos Correios

448 visualizações

Publicada em

Apresentação de case de consultoria durante o 1º Encontro Nacional de UserGroups Macromedia ‐ São Paulo, Julho de 2004.

Publicada em: Internet
0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
448
No SlideShare
0
A partir de incorporações
0
Número de incorporações
5
Ações
Compartilhamentos
0
Downloads
5
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Performance e disponibilidade ‐ Um estudo de caso: website dos Correios

  1. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 16. 2ª ETAPA: cluster virtual usando múltiplas instâncias de ColdFusion
  17. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 29. Dúvidas?
  30. 30. Obrigado! (se tivermos tempo, vamos falar de Adobe e CF?)
  31. 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. 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. 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

×