InfoQ

Notícias

Caching HTTP suave com Rack::Cache

Postado por Sebastien Auvray , traduzido por Flávia Castro de Oliveira em 17 Nov 2008 02:13 PM

Comunidade
Ruby
Tópicos
Ruby on Rails,
Performance & Escalabilidade,
Frameworks Web
Tags
Escalabilidade,
Caching,
Ruby on Rails,
HTTP,
Rails

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.

Conteúdo Educacional

13 Razões para Programadores Java aprenderem Flex e BlazeDS

Treze razões para que programadores java aprendam Flex e BlazDS. Ele discute sobre o porquê que Flex e BlazeDS é uma das melhores opções para desenvolver aplicações ricas de internet.

Ruby in Practice com Jeremy McAnally

Rob Bazinet e Matthew Bass, ambos da InfoQ, tiveram a oportunidade de conversar com Jeremy McAnally, sobre o livro "Ruby in Practice" no qual foi co autor junto à Assaf Arkin.

Esclarecendo os Equívocos Mais Comuns Sobre Refatoração

Danijel Arsenovski tenta esclarecer alguns mitos sobre refatoração e como isso se aplica para desenvolvedores .NET

As 10 Maiores Mudanças no Flex 4

Em maio, Adobe lançou a primeira versão beta do Flex 4, codinome Gumbo. A lista a seguir proporciona uma visão geral de alto nível dos itens que foram modificados na última versão do framework RIA.

Conversa sobre RubyMine e JetBrains

Um dos anúncios mais interessantes recentemente feito à comunidade Ruby foi o lançamento da IDE JetBrains RubyMine para aplicações Ruby e Ruby on Rails.

Introdução à Data Services

Data Services são serviços de software que encapsulam operações das entidades chave relevantes para a empresa.

Esquemas para Web Services – Parte 1: Tipos de dados básicos.

O uso do XML traz consigo desvantagens, como problemas em potencial com desempenho, mas também oferecem um nível de abstração que permite diminuir o acoplamento entre as partes envolvidas na troca.

Revisão do livro: Clean Code: A Handbook of Agile Software Craftsmanship

Como programadores, a nossa primeira prioridade é criar código que funciona. Infelizmente, código que simplesmente “funciona” não é suficiente.