Maximum number of simultaneous requests e ThreadTimeOut

Ainda falando de tunning de performance no ColdFusion Server. Quando você configura o seu ColdFusion para processar X requests simultâneos (veja a opção “Maximum number of simultaneous requests” dentro de “Server Settings” no ColdFusion Administrator) você está dizendo a ele mais ou menos o seguinte: “CFServer, atenda 10 requests (por exemplo) ao mesmo tempo e mande os demais esperarem na fila”.

Como o hardware do servidor é limitado em termos de recursos (CPU principalmente), fica fácil perceber que quanto mais requests o servidor tiver que atender, simultâneamente, mais lentamente ele irá fazê-lo. Eu costumo fazer uma analogia entre um ônibus e uma Ferrari. O primeiro anda devagar (se bem que isso é relativo, no Rio os motoristas dos coletivos são loucos), mas leva 40 pessoas ao mesmo tempo. A Ferrari voa, mas leva apenas 2 passageiros. Essa analogia é válida para o setting “Maximum number of simultaneous requests”. Quanto maior o número, mais lentamente o CFServer irá atendê-los. Quanto menor, mais rápido.

Mas qual é o número ideal? O número mágico é o que faz o seu servidor atender um número adequado de requests (de acordo com o seu tráfego), sem deixar muitos esperando na fila e de forma mais rápida possível. Mistura impossível? Nem tanto. O script de CFSTAT (e o CFSTAT propriamente dito) poderá ajudá-lo a chegar à melhor métrica para o seu servidor. Veja quantos requests estão rodando simultâneamente no horário de pico, quantos estão sendo “dropeados” e chegue a um número adequado, de preferência um que não deixe ninguém perder a paciência na fila (leia-se: um request dar timeout). Mas e quando você não pode (por limitações de CPU) atender todos os requests ao mesmo tempo? Simples: aumente o tempo de permanência da fila. Você já deve estar pensando: “ah, é só aumentar aquele atributo “Timeout Requests after (seconds)” na mesma seção do CFAdministrator”?. Não, este setting é válido apenas para requests que já estão sendo processados, o que não é o caso da fila de espera para processamento. Veja mais adiante:

O ColdFusion MX 6.1 trouxe uma mudança que não me agradou muito, que foi a modificação deste tempo (que era de 350ms) para apenas 20ms, muitas vezes absolutamente insuficiente. Não entendi muito bem porquê da mudança, mas me senti aliviado por saber que podemos alterá-la.

No arquivo “jrun.xml”, normalmente localizado em “cf_rootruntimeserversdefaultSERVER-INF” você vai encontrar uma entrada como esta:

<attribute name="threadWaitTimeout">20</attribute>

Basta alterar este valor (20) para um mais elevado. Eu custumo colocar 250 (o valor é expresso em ms). É tempo suficiente para que os seus usuários não “percam a paciência” esperando na fila e você tenha muito menos requests sendo negados (JRun closed connection) apesar do tempo maior para processá-los. Fica aí a dica, especialmente para quem tem máquinas cujo tráfego é bastante elevado.

Heap “agressivo” e mudanças nos settings de JVM

Semana que passou pude confirmar na prática uma valiosa dica postada há algum tempo pelo Pete Freitag: a de incluir, no startup do JVM, a opção: -XX:+AggressiveHeap em servidores parrudos. A máquina era um alucinante XSeries 225 (quem me dera ter um destes!) com 2Gb de RAM ECC e “quatro” processadores Xeon (na verdade são apenas dois processadores físicos, mas cada die leva dois processadores quase distintos, semelhante (mas não igual), ao HT do P4. E por incrível que pareça o servidor estava sofrendo (acredito que este servidor seja responsável por um dos sites feitos em CF com maior volume de visitação no país – não posso dizer qual). A melhora na performance não foi muito expressiva (não pude mensurar isso no ambiente de produção), mas o dito cujo pode respirar um pouco mais aliviado com a mesma carga.

O campo “JVM Arguments” do ColdFusion Administrator ficaria como neste arquivo txt.

Um outra pequena (mas importante) modificação que fiz pode ter auxiliado neste alívio: o ColdFusion MX 6.1 vêm com uma versão do Java HotSpot VM já relativamente antiga (de um ano). Se não me engano é a 1.4.2b28. Migrar para a última compatível e existente (1.4.2_05) ajudou um pouco creio (nem pense em usar a beta 1.5, o CF NÃO é compatível (por enquanto) com ela). Não é má idéia fazer isso em qualquer ambiente, independente da sua máquina. A mudança é bastante simples mas requer cuidado:

1) No ColdFusion Administrator, vá na opção do menu superior chamada “System Information” e veja a especificação “Java VM Version”, que deverá ser 1.4.2b28 (se não me engano);
2) Baixe a última versão do Sun J2SE no site da Sun. O J2SE é a base para o Java em qualquer aplicação baseada no Java da Sun, de desktops à servidores (J2EE), exceto aplicações “micro”, que usam um JVM especial (o J2ME));
3) Minha recomendação é de instalá-lo numa pasta simples e com nome sem espaços ou pontos (sei que não tem mais problema, mas eu sempre fui fresco com isso). Em ambiente Windows, por exemplo, instalo em “C:Java”;
4) No ColdFusion Administrator, vá em “Java and JVM” e mude o “Java Virtual Machine Path” para o novo local (no meu exemplo seria: “C:Javajre”) e clique em submit changes;
5) Páre e reinicie o ColdFusion Server. Verifique a mudança de JVM na opção “System Information” do ColdFusion Administrator (passo 1).

IMPORTANTE: caso o serviço do ColdFusion não reinicie, você fez alguma coisa errada e precisará restaurar o setting anterior. Mas como fazer isso se você não tem acesso mais ao CFAdministrator? Simples, no diretório “cf_rootCFusionMXruntimebin” você vai encontrar dois arquivos, um chamado “jvm.bak” e outro “jvm.config”. Você deverá trocar o nome deles. Renomeie o “jvm.config” para qualquer coisa (ex: “jvm.bak2”) e volte o backup, renomeando o “jvm.bak” para “jvm.config”. Pronto, o CF deve reinicializar como antes (ufa!).

Não tenho métricas sobre esta mudança com relação a estas duas JVM. Já fiz uma análise mais detalhada e técnica no passado porém para o ColdFusion MX 6.0 e trocando o HotSpot Client (padrão no MX 6.0) para Server. Mas o resultado é quase sempre certo: a mudança do JVM para um mais novo (da mesma “marca”) quase sempre resulta em melhoria de performance.

Por último, gostaria de disponibilizar um pequeno script CFML que escrevi (com base no excelente livro “Optimizing ColdFusion 5”) há muito tempo atrás, mas que funciona igualmente bem no CFMX e traz para a interface web as métricas do CFStat. Você pode vê-lo em ação aqui, numa máquina da Locaweb, e baixá-lo aqui, em formato zip (míseros 500 bytes!). Use-o, é uma ferramenta simples, mas bastante útil quando se está fazendo o tunning de servidores e aplicações em CF.

MM Technote: ColdFusion MX e o Windows XP SP2

Neste post eu relato um documento da Microsoft listando o ColdFusion como uma aplicação “incompatível” com o Service Pack 2 do Windows XP.

Apesar de ser um mero detalhe e com workaround/fix bastante simples, a resposta da Macromedia veio rápido:

Enabling ColdFusion MX and ColdFusion MX 6.1 on Windows XP Service Pack 2 with the Windows Firewall Enabled

Incluindo settings para que o servidor K2 (que acompanha o CFMX) rode também sem problemas.

VR Vales + ColdFusion = novo portal

Esta semana foi ao ar o novo portal da VR Vales, feito em ColdFusion usando o framework de desenvolvimento Navita Content em tempo recorde (2 semanas). É mais um case de uma grande empresa brasileira rodando ColdFusion Server.

Confiram: http://www.vr.com.br

Outros mais virão!

Oportunidade

Recebi por e-mail com um pedido para repassar. Parece ser interessante:

“We are looking for a ColdFusion Developer. You MUST speak good english. Send your resume and hourly rate to dquinze@powershore.com”

Enviar curriculo conforme instruções acima para Douglas Quinze.

É o offshoring de ColdFusion chegando ao Brasil! Na Navita já estão pintando trabalhos para o exterior neste esquema. Tomara que a onda pegue. 😉

CFDJ edição de Agosto dísponível para download

Já está disponível para download a edição de Agosto do ColdFusion Developer’s Journal. Matérias interessantes intercaladas por páginas pesadíssimas de belos anúncios de produtos relacionados, num PDF com quase 6 Mb de tamanho.

Não deixe de conferir e baixar: Volume: 06 Issue: 08 – August 2004

ColdFusion MX e o Windows XP SP2

A Microsoft liberou, na área de suporte de seu site, uma lista de programas que apresentaram problemas após a instalação do Service Pack 2. Nesta lista (não muito extensa), encontramos o ColdFusion Server “version 6”. A maioria dos problemas se resumem à falhas de comunicação entre os programas listados e o novo sistema de segurança Windows Firewall, que substitui o Internet Connection Firewall e já vem configurado para bloquear o acesso não solicitado de redes externas, o que impede o recebimento de dados pelo computador. No caso do ColdFusion Server, o problema mais óbvio é o acesso ao CFAdministrator (tanto pela porta 8500 quanto pela 80).

Em resumo: nada de mais! 😉

[via UOL InfoNews]

Cold Fusion: o Sol engarrafado

Off-topic que vale a pena. Leia esta interessante(e básica) explicação sobre o que é fusão à frio e sua história: Cold Fusion – The Sun in a bottle.

ColdFusion limitado a 1.8Gb de RAM

Poucos sabem, mas a arquitetura x86/32bits (Linux/Windows) oferece uma limitação importante para aplicações Java no tocante ao consumo de memória RAM. A arquitetura 32 bits pode endereçar nativamente no máximo 4GB de memória RAM (2^32 = 4.2 bilhões ~ 4Gb). Destes 4GB, metade (2GB) é reservada para o funcionamento do kernel e a outra metade (2GB) fica disponível para outros processos e aplicações. Não vou entrar no mérito da questão do porquê isso ocorre, até porque não me sinto seguro para comentar sobre algo que não pude estudar muito, porém adianto que existem algumas alternativas no Windows 2k/2k3/XP (/PAE) para endereçar um número maior de memória ao invés de 2GB, o mesmo é válido para os kernels mais novos do Linux (2.4 para cima), mas até agora não compreendi muito bem o que isso pode mudar em relação ao suporte à Java.

O fato é que a pilha (heap) do JVM utiliza a memória de forma contínua, alocando um bloco unitário, como um único processo, limitando o uso de RAM por uma instância JVM única à 1.8GB (os 200Mb restantes são usados pelo JVM para atender processos internos, como o garbage collection e afins). Estes são números aproximados, não há uma métrica precisa.

Em resumo: se você está pensando em comprar um servidor na arquitetura x86/32bits (Intel/AMD) e pretende instalar mais do que 4GB de memória RAM pense e estude esta questão, pois você poderá estar comprando memória extra (e cara) que não fará a menor diferença, pois não poderá ser usada pelo JVM.

Se a sua aplicação precisar de algo maior (o que está se tornando bastante comum hoje em dia), a solução é partir para a arquitetura 64bits (tanto em Windows quanto em Linux), arquitetura que graças à AMD está se tornando mais popular e viável ($) para os nossos bolsos. Em alguns casos você pode optar pelo modelo híbrido 32/64bits (Atlhon64) e ficar pronto para quando for a hora de migrar. Caso estas não sejam uma opção, você pode adotar um modelo de cluster, com quantas máquinas (inclusive um falso cluster, com várias instâncias dentro de um mesmo servidor) forem necessárias para suportar seu site/aplicação. Uma continha gostosa de se conhecer: na arquitetura 64bits teríamos: 2^64 = alguns terabits para muitos anos…).

O interessante é saber que a arquitetura 32bits Sparc (Risc?) da Sun não apresenta este problema com o JVM. Que diferença faz ser dona da tecnologia não? :o)

Alguns links para ajudar a compreender o problema:

– Maximum JVM heap size greater than 1.8GB will prevent ColdFusion MX from starting;
– The 4GB Windows Memory Limit: What does it really mean?;
– 1.8GB Heap Limit in ColdFusion MX;
– How to avoid 2GB memory limit of JVM in Linux (bastante informativo);
– http://forum.java.sun.com/thread.jsp?thread=525731&forum=37&message=2521405

E claro, o bom e velho Google.

CFCs como web services

Quem usa CFCs como web services já deve ter se deparado com um problema as vezes irritante. Os argumentos de uma função, embora programados como opcionais (isto é, required=”no”) devem ser passados quando o componente for invocado como um web service.

Isso ocorre porque o ColdFusion MX 6.1 utiliza o Axis 1.1, da Apache, como responsável para os webservices, que não suporta argumentos opcionais.

Por tanto, em suas chamadas a web service a CFCs, todos os argumentos devem ser passados, estejam eles marcados como requeridos ou não.