Conjunto interessante de slides sobre boas práticas de desenvolvimento de software e de construção de soluções escaláveis:

É, ao que tudo indica o Page Speed era apenas a ponta do iceberg. O Google acaba de lançar mais uma página relacionada ao aumento de desempenho na web: Let’s make the web faster. A página trás uma série de tutoriais sobre como tornar as páginas mais rápidas. Vários temas são abordados, inclusive PHP, veja o vídeo:

Isso tudo faz parte de uma nova iniciativa do Google de compartilhamento e geração de novas informações para que a web, sua plataforma de desenvolvimento, se torne cada vez mais eficiente. Bem, acho que ninguém tem nada a perder, correto?

As dicas para PHP:

1. Não copie variáveis sem ter um motivo
2. Utilize aspas simples para delimitar strings
3. Utilize echo e, ao invés de concatenar as strings e variáveis, passe-as como argumentos:

   echo 'Escrevendo duas variáveis: ', $var1, ' e ', $var2;

4. Utilize switch/case ao invés de if/else.

Tradução livre de um e-mail recente do Dave na DailyDave:

———————————————

Um tempo atrás alguém que eu conhecia estava tentando resolver um problema relacionado à criptografia. Ele acabou dizendo “Eu consigo fazer isso rápido e de maneira fácil se tiver menos que 40 bits”, no que uma outra amiga minha, matemática, disse: “Se é tão pequeno, resolva por exaustão”.

De qualquer forma, esta foi uma lição importante que me mostrou como o que é “grande” para algumas pessoas é apenas “resolva por exaustão” para outras. Se você vai à uma empresa comum de porte médio que constrói aplicações para a web, você verá pessoas lutando bravamente para construir clusters para rodar a sua base de dados relacional, gerenciando a sua Storage Area Network, e fazendo várias outras coisas do tipo de maneira essencialmente errada. No mundo real, não dá para aumentar a escalabilidade de armazenamento centralizado de maneira satisfatória. E não dá também para fazer o mesmo utilizando um banco de dados relacional. A própria idéia de a sua aplicação já saber de antemão tudo que ela precisa saber é engraçada. Em um sistema escalável, tudo que se sabe é que nada se sabe.

http://highscalability.com/google-architecture é um bom exemplo de arquitetura feita para ser escalável. A pergunta principal é “o que a BigTable NÃO pode fazer?”. Escalabilidade tem a ver com o que não pode ser feito, e não com algoritmos estupidamente legais que PODEM fazer alguma coisa. A investida do Google para contratar o Guido Van Rossum pode ser vista como “Sim, mas qual é a graça de se projetar uma linguagem para executar em um sistema não escalável? Daria na mesma programar apenas para calculadoras”. E, no presente momento, é possível dizer que apenas o Google possui um sistema escalável.

Na mesma linha de raciocínio, é claro, as formigas não utilizam som para se comunicar. O livro clássico no assunto é avaliado aqui: http://www.nytimes.com/2008/11/23/books/review/Jones-t.html. Biólogos geralmente estão lidando com sistemas que eles não conseguem entender – eles são ou muito grandes, ou muito numerosos, ou muito pequenos ou são muito complexos ou há pouca verba para pesquisa. Mas em super organismos do tamanho de uma colônia de formigas, eles conseguem observar que algoritmos reais não possuem um comportamento único, mas vários comportamentos emergentes. O livro também possui várias fotos bonitinhas de formigas. Formigas constituem um sistemas grande e complexo de troca de mensagens. O que é muito legal, e provalmente é este o motivo pelo qual Nico utiliza formigas em suas apresentações. Analisar comportamentos emergentes é um chute no saco, mas o David Beazley, criador do PLY, criou este vídeo muito bom:

Debugging é difícil, mas assim é a vida.

——————————–

Se você não tem tempo para ver a apresentação, acho que vale a pena dar uma olhada pelo menos nos slides. Eu não sabia que Python era tão ruim assim pra trabalhar com threads. O que eu sabia é que há algum tempo tem gente estudando sobre as formigas em computação.

Conforme prometido no meu último post, começo aqui a série de resumos das boas práticas do google para aumento de desempenho na Web.

Otimização de caches

Trata-se de um dos alicerces para aumento de desempenho em computação: Localidade Temporal – manter em meio de armazenamento mais rápido os dados que foram acessados recentemente, porque a probabilidade de acessá-los novamente é grande. Tratando-se de páginas da Web, estamos falando de que? CSS, imagens, Javascript, arquivos binários (PDF, Flash, etc) entre outros.

O que pode ser feito? Ao invés de fazer o download desses arquivos, que são atualizados com pouca frequência, a cada refresh de página, por que não salvar uma cópia local ou em um proxy?

O que se ganha? Redução do tempo de Round Trip e do tamanho do download (payload) da resposta.

O que se perde? É possível que a página renderizada contenha informações defasadas, pois sempre existe a possibilidade de o arquivo original ter sido atualizado desde o momento em que a cópia local foi recebida. Assim, quanto mais tempo um dado ficar na cache, maior será a probabilidade de ele estar defasado.

Como fazer?

Para garantir que um arquivo seja cacheado (eu sei, é horrível, mas não consigo imaginar um termo melhor, caso você conheça, deixe um comentário) é necessário que o servidor HTTP especifique os cabeçalhos relativos a caching para todos os recursos, e não apenas para imagens, por exemplo, excetuando-se as páginas HTML.

Cabeçalhos do HTTP 1.1 relativos a caching: Expires, Cache-Control: max-age, Last-Modified e ETag.

Os dois primeiros são obedecidos incondicionalmente pelo browser. Com o primeiro é possível definir uma data (seguindo o RFC 1123, por exemplo, Expires: Thu, 01 Dec 1994 16:00:00 GMT)) a partir da qual o dado deve ser considerado obsoleto. Já com o segundo é possível definir uma idade, em segundos, a partir da qual o dado pode ser considerado obsoleto. É importante notar que, caso os dois cabeçalhos sejam definidos, o Cache-Control prevelecerá.

O Last-Modified permite definir a data de última modificação do dado. Por fim, com o ETag é possível definir um valor que identifique unicamente um dado (um hash de um arquivo, exemplo). Com os dois últimos, é possível realizar um GET Condicional para fazer o download do dado apenas se uma versão mais recente estiver disponível no servidor. Definir os dois cabeçalhos, entretanto, assim como no caso dos dois primeiros, é redundante.

Ok, agora que já sabemos informar o browser sobre o nosso desejo de que ele crie uma cache dos dados que estamos fornecendo. Quais políticas de cache devem ser seguidas, então, segundo o Google?

Definir políticas agressivas de caching para recursos estáticos: defina Expires (tem mais suporte que Cache-Control) de 1 (um) ano, pois é o máximo permitido. Caso você saiba que o recurso vai ser atualizado antes disso, defina-o de acordo com essa data prevista. Defina também Last-Modified para a data correspondente (à última atualização do recurso).

Use fingerprinting para permitir caching dinâmico: inclua na URL do recurso um fingerprint do mesmo. Um exemplo para um arquivo css: fingerprint_keydoozercompiled.css.  Use o md5sum do arquivo, por exemplo, para gerar o seu nome. Qual a vantagem? Você poderá definir um Expires de um ano e, mesmo assim, garantir que o cliente vai receber a última versão do CSS assim que a mesma estiver disponível pois, como a URL do arquivo mudou (ao se modificar o arquivo, muda-se também o valor do md5sum e, por consequência, o seu nome), o browser não vai ter uma versão local e vai ser obrigado a fazer o download da nova versão. A não ser que você esteja usando o Firefox e o seu fingerprint seja menor que 8 caracteres. Por que isso? Veja o próximo parágrafo!

Evite URLs que gerem colisões de cache no Firefox: garanta que as URLs da sua aplicação possuam mais que 8 caracteres diferentes entre si. Caso isto não ocorra, apenas um dos recursos (com o mesmo valor hash) será armazenado na cash.

Não utilize o cabeçalho Vary: ou utilize-o apenas em conjunto com os cabeçalhos Accept-Encoding e User-Agent. Em todos os outros casos (Vary com outros cabeçalhos) o Internet Explorer não fará caching.

Em relação a servidores proxies que possam estar entre o cliente o servidor:

• Não fazer acesso a recursos estáticos por meio de URLs que contenham query strings. Alguns proxies simplesmente não realizam caching, nestes casos.
• Não realizar caching de recursos que utilizem cookies. Uma opção é definir Cache-Control: private ou utilizar um domínio separado apenas para fornecer recursos que não utilizam cookies (cookieless domains). Mais sobre esta segunda alternativa em outra parte.
• Tomar cuidado com versões compactadas de JavaScript e de CSS. Alguns proxies armazenam apenas a versão compactada, servindo estes arquivos também para clientes que não possuem suporte. Para evitar isto, utilize Cache-control: private ou Vary: accept-encoding (preferível).

Bem, esse foi o resumo do resumo. Dá pra perder uma tarde só com isso, se os links com mais detalhes forem seguidos

O Google acaba de lançar mais uma ferramenta open source. Desta vez eles liberaram uma extensão para o Firefox chamada Page Speed que trabalha junto com a Firebug.

Além da ferramenta, na página do projeto há a documentação do que eu traduzo livremente como  “Boas Práticas para o Aumento de Desempenho na Web” (Web Performance Best Practices, gosto do inglês principalmente por seu alto nível de condensação de informação).

O que a extensão faz é avaliar uma página para identificar possíveis gargalos no tempo de carregamento. Caso alguma fonte de atrasos seja encontrada, a extensão aponta também como removê-la. Descobri, por exemplo, que as miniaturas que o flickr gera no menu da direita aqui do meu site poderiam ser mais leves, entre outras coisas.

Enfim, como ainda não existe versão em português do site do projeto e para me forçar a estudar e entender melhor as tais boas práticas, resolvi resumir aqui o que cada uma delas define. Como é um bocado de informação:

• Otimização de caches
• Minimização de tempo de Round-Trip (RTT)
• Minimização do tamanho das requisições
• Minimização do tamanho de respostas, downloads e cache de páginas
• Otimização de tempo de renderização no browser

Vou fazer em partes. Em breve libero a parte 1: Otimização de caches.