Nginx é um web server e proxy de alta performance capaz de servir milhares de requisições simultâneas.

Tendo usado desde a época da boo-box, recentemente em dois sites que hospedo e também no BuzzVolume, eu posso dizer algo sobre o famoso “nginx bem configurado”: funciona e me faz dormir tranquilo.

O nginx é um web server. Responde as requisições na porta configurada, faz redirecionamentos, retorna arquivos estáticos e aceita módulos:

A comunidade está contribuindo bastante e é sobre alguns módulos “3th party” que vou falar.

Obs: Por “backend” entenda que é a aplicação Ruby, PHP, Python, “escolha sua linguagem”, que estiver rodando.

NginxHttpUpstreamFairModule

O upstream_fair faz com que as requisições batam no backend que estiver com menos carga. Sem esse módulo as requisições são distribuídas para qualquer backend, mesmo que esse estiver ocupado.

NginxHttpEmptyGifModule

O ngx_http_empty_gif_module mantém na memória um GIF de 1×1 pixels e o entrega diretamente, sem buscar no disco.
Eu considero esse o módulo mais curioso. Ele mostra a preocupação com performance e a facilidade de fazer algo assim com o nginx.
Esse gif de 1×1 pode servir como favicon.ico em sites que não usam icone, evitando que o arquivo (que não existe) seja procurado e retorne um erro. Também pode ser usado como “beacon” para rastreamento de impressões de ads.

NginxHttpLimitReqModule

Construindo o próximo Twitter? Mais um encurtador de URL? O módulo NginxHttpLimitReqModule permite impor limite de requisições por cliente nas suas páginas. Acabe com os engraçadinhos que abusam da API no seu URL-Short.

nginx-ey-balancer

Com o nginx-ey-balancer é possivel limitar o número de requisições simultâneas passadas ao backend. Ao invés de todas requisições cairem na aplicação elas ficam em fila no nginx aguardando um processo disponível. Segurar a requisição na aplicação precisa de mais memória e faz a performance da aplicação cair consideravelmente. Ótima solução desenvolvida pela EngineYard.

NginxHttpMemcachedModule

Memcached é um software desenvolvido para diminuir a carga da base de dados. Ele faz cache de objetos na memória e permite acesso pela interface rede. O NginxHttpMemcachedModule dá ao nginx o poder de procurar por um objeto no memcached e caso encontrar retorna o seu conteúdo para o navegador.

NginxHttpImageFilterModule

NginxHttpImageFilterModule é outro software interessante. Esse desenvolvido pelo criador do nginx, muda o tamanho da imagem na hora de entregar para o cliente evitando armazenar vários “thumbnails” do mesmo arquivo.

Estão surgindo cada vez mais módulos para o nginx. Confira outros “oficiais” e “3th party“.

Então nós temos o HTTP a muito tempo e algumas coisas que foram revistas na versão 1.1 (RFC 2616) do protocolo só estão estão sendo implementadas para valer agora.

Uma parte importante do REST é a preocupação com o uso e implementação de alguns metodos HTTP esquecidos até agora.

Outra nova preocupação é sobre as implementações de cache do protocolo.
O protocolo HTTP vem com várias especificações sobre como cache pode ser feito nessa camada, porém, até agora foi uma parte esquecida tanto nas aplicações como nos clientes de HTTP.

Como várias aplicações (não pense somente em navegadores, mas também Web Services) começaram a seguir essas especificações para fazer cache local, era lógico que viriam implementações para os servidores que utilizamos hoje em dia.

Eu não sei você, mas eu já estou com Nginx + Rack a muito tempo. Rack é uma interface entre o servidor HTTP e o framework Ruby. No meu caso o framework é o Merb e o servidor é o Thin. O Nginx só dá uma de proxy reverso. E é ai que entra um grande potencial para ele. Com alguns cabeçalhos HTTP sendo trocados corretamente o Nginx consegue funcionar como servidor de cache facilmente.

Rack::Cache é um adapter para Rack (que servidores como Thin e Ebb usam e frameworks como Merb e Sinatra também). Além de usar corretamente os cabeçalhos HTTP sobre cache, o Rack::Cache age como um mecanismo de caching completo e totalmente fora da aplicação. Permitinde inclusive que o armazenamento seja feito no Memcached.

Por enquanto é necessário a inclusão manual do código na aplicação que está executando o Rack. Em breve espero que os próprios servidores ou frameworks incorporem as funcionalidades dessa gem Ruby.

Outro dia eu perdi uma boa meia hora de produtividade porque não conseguia testar as alterações que eu fazia no RSS. O motivo? Elas não apareciam no Google Reader (ou Netvibes, ou qualquer outro agregador) pois a versão passada estava em cache.

Hoje quando precisei novamente fazer e testar as mudanças, a solução foi tão simples, tão igual a gente já está acostumado que fiquei até com vergonha.

Olha só. Lembra lá no AJAX ou no CSS quando você quer enganar o cache do navegador e coloca algo do tipo “&randcache=665″ na requisição HTTP? Então…

Quando precisar testar mudanças ignorando o cache do leitor de RSS, adicione um novo feed no reader com a mesma URL e um “&qualquer-coisa” no final. O Google Reader entende como um novo feed e vai no servidor buscar, pegando a nova versão ;D