Primeiro vamos explicar de maneira resumida o que é CDN. CDN, que é a sigla abreviada de Content Delivery Network, provê uma entrega mais eficiente do conteúdo estático do seu site, isto porque possui uma melhor distribuição geográfica para o usuário que requisita tal conteúdo e faz a entrega baseada na geo-localização do requisitante. Isto praticamente elimina o "delay" geográfico para acesso aos dados.
Sua primeira pergunta deve ser: mas eu preciso disto? Isto variará com o público alvo, se o público que queres atingir é concentrado em uma só região, exemplo, tens uma empresa que atende somente o mercado do Rio Grande do Sul e não tem uma prospecção de crescimento geográfica, CDN não será efetiva em sua plenitude, pois agregará somente como uma camada de cache, e mantê-la para essa finalidade exclusiva torna-se caro e pode ser realizado com outras técnicas que mencionaremos abaixo.
A próxima pergunta será: a CDN resolve meu problema geográfico? Sim em termos de cache de conteúdo. Somente a CDN resolve meu problema de performance quando tenho um fluxo grande de requisições? Não. Para tal existem técnicas de crescimento de frontend, backend para ganho de vazão, mas o que abordaremos aqui é a técnica de cache, que permite atender uma demanda maior sem a necessidade de aumento proporcional do backend e frontend.
Quando cito frontend, compreende-se a camada de middleware e não meio-físico, roteadores, balanceadores de carga e etc, mas sim webservers, portais modulares que são os primeiros a receber a demanda, às vezes devolvendo a resposta, outrora distribuindo para servidores de aplicação, integradores e webservices, que aqui são tratados de backends.
Independente do uso de CDN, quando a proporção de acesso 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, repassarão as mesmas para os webservers, mas já entregarão ao usuário objetos, imagens e outros que constam em sua memória, dando ao usuário a percepção de agilidade no acesso.
Tal camada será efetiva quando o índice de acertos (hitratio) do cache for elevado, para tal, deve ficar claro que temos dois métodos de uso:
1 - regras locais: onde 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. Então regras, ainda que 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 e etc): as configurações de persistência, e do que será armazenado em cache, será realizado no próprio objeto. Um exemplo:
//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 os headers de cache comuns?
cache-control
Este é o header que faz o controle de cache, para obter informações de controle de um objeto procure por essa palavra-chave.
|
private ou public
Este parâmetro do header ‘cache-control’ permite aos caches intermediários saberem se devem ou não realizar cache de um objeto, 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 faz cache de mim.
|
no-store
O parâmetro normalmente é seguido do ‘no-cache’, ele informa a sua solução de cache ou navegador que não se deve armazenar parte dele, no caso, o objeto.
|
max-age
Ai está a configuração de idade do cache, ou seja, quanto tempo ele deverá expirar. Este valor varia de acordo com o tipo de conteúdo.
|
Aos mais usados...
Com relação a CDNs temos alguns fornecedores importantes como Amazon, Microsoft e Akamai. Cada fornecedor possui seus pontos fortes e fracos, entretanto a Amazon é superior no quesito de maturidade e quantidade de oferta de produtos para nuvem. O site dos comparativos podem ser acessados nas referências desta publicação.
Já quanto ao cache local podemos citar Varnish, Nginx e Traffic Server. O Varnish apesar de ser uma solução de cache com possibilidade extensa de configurações, o que é importante para ajustes específicos em determinados ambientes, perde muito com a falta de suporte ao SSL, e abre caminho ao Nginx em função de sua agilidade em respostas com baixo consumo de recursos.
Vamos aos erros...
Erros comuns relacionados a cache são falhas de expressões regulares, a não inclusão de controle de cache em objetos estáticos, ou a inclusão de controle incorreto de cache em conteúdo dinâmico, o que gera problema para os usuários de renovação de objetos e por consequência falha no acesso da página.
O tema é complexo e certamente podemos estendê-lo mais, entretanto por hora cabe-nos mencionar que a junção das duas camadas de cache mencionada nesta publicação pode ser interessante e performática, por outro lado, devemos estar atentos à 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
Versão também publicada em : http://ilegra.com/beyonddata/
very useful information, the post shared was very nice.
ResponderExcluirMicrosoft Azure Online Training