Ir para o conteúdo principal
Voltar aos artigos

Leitura parcial no cache: economizar bytes exige preservar a versão do arquivo

Origin Range Requests combina blocos e buscas parciais. O limite técnico é servir uma representação consistente, não só transferir menos.

·3 min de leitura·20 visualizações

A Cloudflare apresentou Origin Range Requests para reorganizar como o cache atende pedidos de intervalos de bytes.[12] A implementação em Pingora combina blocos disponíveis em disco, transferências em andamento e buscas dos trechos ausentes, permitindo que requisições concorrentes aproveitem o mesmo download.[12]

A ideia é atraente para arquivos grandes, mas não se resume a recortar uma resposta. Ao montar partes, o serviço assume uma responsabilidade: provar que elas pertencem à mesma representação. Ganhar desempenho entregando bytes de versões diferentes seria uma otimização do arquivo errado.

O que muda para quem desenvolve

No modelo anterior descrito, uma leitura pequena que cruzasse uma fronteira no R2 podia provocar 128 MiB de transferência.[12] O novo desenho limita o desperdício pelos blocos usados no armazenamento, embora ainda possa ler bytes além do intervalo solicitado.[12]

A implementação trata identificadores, tamanho, If-Range, respostas 206 e 416 e a interação com descompressão; quando não consegue preservar as condições necessárias, serve a representação completa.[12] Minha análise: esse fallback é parte da correção, não um fracasso de desempenho que deva ser eliminado a qualquer custo.

Para uma aplicação, vale separar duas métricas. O usuário percebe o tempo de resposta, enquanto a operação paga também pelos bytes buscados e pelas requisições feitas. Uma melhora em uma não garante redução automática da outra.

Como aplicar

Escolha um arquivo grande de teste e prepare pedidos para trechos próximos, distantes e cruzando limites de blocos. Compare bytes entregues ao cliente, bytes lidos na origem, número de buscas e tempo até o primeiro byte.

Repita com requisições concorrentes para observar se existe reaproveitamento. Depois, substitua o arquivo por uma nova versão entre duas leituras e confira como o cliente e o cache tratam a mudança. Use conteúdo conhecido em cada versão para detectar uma combinação incorreta, sem depender apenas do tamanho final.

Inclua também um intervalo fora do arquivo e uma origem que não atende leitura parcial. O roteiro deve verificar a resposta correta, não apenas o caso em que a otimização funciona. Preserve esses casos como regressão antes de alterar configurações de cache.

Cuidados e limites

A Cloudflare relata redução de aproximadamente metade no p99 de tempo até o primeiro byte do R2 e cerca de 6% menos tráfego entre camadas de cache após uma melhoria posterior.[12] Esses são resultados da operação descrita, não uma promessa de ganho para qualquer aplicação.

O recurso está disponível em todos os planos por Cache Rules, mas não torna cacheável um conteúdo que já não era; a origem precisa suportar intervalos para que as buscas parciais sejam úteis.[12] Avalie-o com o formato e o padrão de acesso reais. Se a maioria das leituras consome o objeto inteiro, a complexidade adicional pode oferecer pouco valor.

Fonte

[12] Fonte: Cloudflare Blog

Continue lendo