Outro assunto muito controverso é o caso de Performance vs Escalabilidade de sites Web. Por incrível que pareça pouca gente parece realmente entender que existem diferenças fundamentais entre as duas coisas.
Muitos assumem que para ter escalabilidade você precisa de performance máxima, ou pior ainda, que performance e escalabilidade são a mesma coisa. Esse assunto foi muito discutido principalmente porque muitos disseram que “Ruby on Rails não escala”. Uma das maiores besteiras do mundo geek, coisa que foi iniciada pelo site TechCrunch no início do sucesso do Twitter, cujo front-end roda em Rails.
No caso específico do Twitter, o que não escalava era o Banco de Dados! Sim, bancos de dados relacionais, por definição, não escalam bem horizontalmente, apenas verticalmente. Escalabilidade vertical significa adicionar mais memória, trocar o processador ou melhorar o I/O da mesma máquina. Escalabilidade horizontal significa colocar mais máquinas em paralelo e a carga se dividir.
O mais importante num website não é a performance bruta e sim sua capacidade de escalar. Um exemplo simples: se sua aplicação persiste objetos de Sessão no disco local, ela por definição, não escala. Se ela grava em RAM então, não escala mesmo. Pior ainda, muitos filesystems não suportam mais que algumas dezenas de arquivos por diretório, o que pode levar um site muito acessado a ficar lento rapidamente. Gravar sessões em banco certamente tem performance bruta menor, porém ela escala trivialmente: basta colocar outro máquina de webserver apontando para o mesmo banco de dados, um balanceador de carga na frente e voilá, escalabilidade.
A chave para escalabilidade numa aplicação Web é o conceito de “shared nothing”, ou seja, cada máquina, cada processo, é auto-suficiente, sem depender de outros e sem compartilhar recursos. Ter recursos em memória compartilhada (como no antigo ASP quando se tinha o objeto Application) pode ser conveniente para desenvolver mas será terrível para escalar.
Leia este artigo sobre a palestra do Michael Koziarski, contribuidor do Ruby on Rails sobre esse assunto. Também assista à série RailsLab , da NewRelic, com diversas dicas sobre performance e escalabilidade de aplicações Ruby on Rails – e que também serve igualmente para a maioria dos outros frameworks web do mercado.
Uma observação importante: considere um website que leva 3 segundos para carregar completamente. Usando plugins como o Firebug do Firefox, ou o Web Inspector do Safari/Webkit, podemos ver exatamente onde esse tempo está sendo gasto. Num exemplo como o site da Locaweb por exemplo, o tempo total de carga foi de 3 segundos (o tempo pode variar dependendo da velocidade da sua conexão). Desse total, apenas 62ms (milissegundos) foram gastos processando o código inicial. Todo o resto (2,038seg) foi gastos no resto da página (stylesheets, javascript, imagens, etc).
Agora, digamos que nosso programador se empenhasse muito na parte da programação e conseguisse incríveis 50% de performance, diminuindo o tempo de 62ms para 30ms. No tempo total, isso não faz nem cócegas, vai diminuir de 3 segundos para 2,070 segundos, ou seja, o usuário sequer vai sentir isso.
Antes de se preocupar com performance bruta do seu código, lembre-se “otimização prematura é a origem de todo o mau”. Primeiro faça sua aplicação funcionar. Depois faça medições (otimização sem medição é perda de tempo), otimize onde importa primeiro (procure o plugin YSlow para Firefox, para começar) e só no final disso procure por gargalos de código que realmente tem impacto significativo.