Formando equipes de alto desempenho, parte 1: Início e fases de evolução
Nesta primeira parte de uma série sobre equipes de alto desempenho e gerenciamento Agile, veja uma introdução geral e uma apresentação dos estágios de formação das equipes.
Notícias
O conteúdo foi adicionado aos favoritos!
Houve um erro ao adicionar aos favoritos! Por favor, tente novamente.
Caching HTTP suave com Rack::Cache
Postado por Sebastien Auvray , traduzido por Flávia Castro de Oliveira em 17 Nov 2008
As formas de cache de uma aplicação web são numerosas e muitas vezes complexas. O caching básico do Rails pode tornar tedioso o gerenciamento da infra-estrutura conforme sua aplicação cresce.
Rails 2.2 introduziu conditional GET através do uso de cabeçalhos http: last_modified e etag. Seguindo a seção de caching padrão da internet da RFC2616, Ryan Tomayko introduziu Rack::Cache.
Rack::Cache é uma peça do Rack middleware que implementa a maioria das funcionalidades da caching da RFC 2616 com um conjunto básico de opções de storage (disk, heap, e memcached) e um sistema de configuração para ajuste do cache. Isto deverá funcionar igualmente bem com qualquer framework web Ruby habilitado para Rack e é testado em Ruby 1.8.6 e 1.8.7.
Parte do seu design foi inspirado pelo framework de cache do Django's (escrito em Python).
Rack::Cache age como um gateway proxy (Varnish , Squid) sem a dor de cabeça de configuração. O Rack::Cache supporta cache baseado em expiração, modelo de validação, e campos de cabelçalho do tipo Vary.
Como Ryan King afirma, você pode migrar suavemente para o gateway proxy de verdade se sua aplicação realmente precisar disso:
Uma vez que sua aplicação fica maior e mais complexa, faz sentido usar um cache de proxy http reverso como squid ou varnish, mas a transição do estilo de caching do rails para HTTP caching é não-trivial. Você tem que alterar seu deployment e sua aplicação de maneiras significativas. Não é divertido.
Com Rack::Cache você só tem que alterar seu deployment. Você pode fazer isso até mesmo de forma incremental. Você poderia começar usando Rack::Cache para cache no heap, depois mudar para o sistema de arquivos e finalmente para memcache. Quando isso atingir o limite de escalabilidade você pode adicionar o squid ou varnhish na fremte de sua aplicação e então remover Rack::Cache. Deployments que envolvem só uma alteração importante em cada passo são muito mais fáceis de acertar do que tentar várias mudanças maiores em uma única operação.
Será interessante dar uma olhada nos próximos benchmarks do Ryan.
Nenhum comentário
Acompanhar Discussão Responder