Antes de iniciarmos com os desdobramentos técnicos, vamos lembrar brevemente o que é um CDN e quando utilizamos. CDN – sigla para Content Delivery Network, prevê uma entrega mais eficiente do conteúdo estático de um site, uma vez que permite uma melhor distribuição geográfica para o usuário, facilitando a entrega, independente da localização do acesso. Assim, agiliza o processo e praticamente elimina a demora para acessar os dados.

cdn-enge-servers-screen

Você deve estar se perguntando se precisa disso. E a resposta é simples: depende do seu público-alvo. Se ele está concentrado em uma única região e não pretende expandir para outros mercados, por exemplo, o uso da CDN não será efetivo, pois agregará somente uma camada de cache e mantê-la apenas para essa finalidade torna-se caro. Para essa situação podemos utilizar outras situações, que veremos a seguir.

Você também deve querer saber se a CDN resolve um problema geográfico. E a resposta é sim, quando trata-se de cache de conteúdo. Mas somente a CDN resolve problemas de performances quando temos um fluxo grande de requisições? Nesse caso, a resposta é não. Para isso existem técnicas de crescimento de front-end e back-end para ganho de vazão. No entanto, veremos aqui a técnica de cache que permite atender uma demanda maior sem a necessidade de aumento proporcional de back-end e front-end.

Quando falamos em front-end, compreende-se a camada de middleware e não o meio físico (roteadores, balanceadores de carga, etc). Envolve webservers e portais modulares, que são os primeiros a receber a demanda, algumas vezes devolvendo a resposta, outras distribuindo para servidores de aplicação (integradores e webservices), que aqui são tratados de back-ends.

Independente do uso de CDN, quando a proporção de acessos aumenta faz-se cada vez mais necessário o uso de cache local, ou seja, a implementação de uma camada antes dos webservers que receberão as requisições. Elas ainda serão repassadas para os webservers, mas já entregarão ao usuário objetos, imagens e outros dados que constam em sua memória, dando ao usuário a percepção de agilidade no acesso.

Essa camada será efetiva quando o índice de acertos (hitratio) do cache for elevado. Para tal, e temos dois métodos de uso:

1 – Regras Locais: é a administração da configuração do que será armazenado ou não no cache, e por quanto tempo é responsabilidade da solução de cache ou webserver. Assim, ainda que as regras constem no cabeçalho (header) do objeto, serão sobrescritas.

 if(req.url ~ “^/search/forum_search_results”) {

   set beresp.http.Cache-Control = “max-age=15”;

   set beresp.ttl = 15s;

   set beresp.grace = 15s;

 }

2 – Regras do Objeto (HTML, JSP, etc): as configurações de persistência e do que será armazenado em cache será realizado no próprio objeto. Um exemplo:

<?php

//set headers to NOT cache a page

header(“Cache-Control: no-cache, must-revalidate”); //HTTP 1.1

header(“Pragma: no-cache”); //HTTP 1.0

header(“Expires: Sat, 26 Jul 1997 05:00:00 GMT”); // Date in the past
//or, if you DO want a file to cache, use:

header(“Cache-Control: max-age=2592000”); //30days (60sec * 60min * 24hours * 30days)
?>

.

Quais são os headers de cache mais comuns?
cache-control
Este é o header que faz o controle de cache. Para obter informações de controle de um objeto basta procurar por essa palavra-chave.
private ou public
Este parâmetro do header ‘cache-control’ permite aos caches intermediários saber se devem ou não realizar cache de um objeto. Ele não está relacionado à segurança ou a algum conteúdo que não pode ser visto.
no-cache
Esse parâmetro faz com que o objeto alvo sempre seja revalidado. Na prática essa tag diz: “não faça cache de mim”.
no-store
Normalmente é seguido do ‘no-cache’. Ele informa à sua solução de cache ou navegador que não se deve armazenar parte dele, no caso, o objeto.
max-age

Aí está a configuração de idade do cache, ou seja, em quanto tempo ele deverá expirar. Este valor varia de acordo com o tipo de conteúdo.

 

Os mais usados

Temos alguns fornecedores importantes de CDN, como Amazon, Microsoft e Akamai, cada um com seus pontos fortes e fracos. A Amazon, no entanto, é superior no que diz respeito à maturidade e quantidade de oferta de produtos para nuvem.

Em relação ao cache total, podemos citar Varnish, Nginx e Traffic Server. Apesar de ser uma solução de cache com possibilidade extensa de configurações – importante para ajustes específicos em determinados ambientes – o Varnish acaba deixando a desejar por falta de um suporte ao SSL, enquanto o Nginx disponibiliza resposta de forma ágil e com baixo consumo de recursos.

.

Os erros mais comuns

Quando se fala em cache é muito comum termos falhas de expressões regulares: deixar de incluir um controle de cache em objetos estáticos ou incluir de forma incorreta de controle de cache em conteúdo dinâmico. Isso gera problemas para os usuários de renovação de objetos e, consequentemente, a falha no acesso da página.

.

CDN é um tema complexo e certamente há mais coisas que poderíamos abordar a respeito. No entanto, por ora vamos nos ater em como a junção das duas camadas de cache mencionadas acima pode ser interessante e performática. Lembrando também que é preciso estar atento à complexidade da junção delas para não transformar algo benéfico em um pesadelo técnico e de gestão de configuração.   

.

Referências

https://www.bizety.com/2016/01/07/nginx-vs-varnish-vs-apache-traffic-server-high-level-comparison

http://www.computerworlduk.com/it-vendors/microsoft-azure-vs-amazon-aws-public-cloud-comparison-which-cloud-is-best-for-enterprise-3624848

https://www.maxcdn.com/blog/cdn-framework-step-2

http://dev.mobify.com/blog/beginners-guide-to-http-cache-headers

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

CAPTCHA
Change the CAPTCHA codeSpeak the CAPTCHA code