TOPOLOGIAS DO CACHE E ANÁLISE DOS SEUS PROCESSAMENTOS

Neste tutorial tentarei explicar todas as topologias usadas em servidor cache , vantagens e desvantagens , para que possam analisar e tirar suas conclusões sobre performance e aplicação dos mesmos.

Todas as análises feitas abaixo são calculadas após o link , pois como sabemos existem links dedicados, links adsl's e muitos tratam diferente suas opções como por exemplo usar load balance .

. CACHE COMO PARALELO AO SERVIDOR USANDO RB MIKROTIK OU ROTEADOR



1- CLIENTE faz requisição para SERVIDOR
2- SERVIDOR faz requisição para RB
3- RB faz requisição para CACHE
4- CACHE devolve requisição para RB
Se cache tem requisição cacheada
5- RB devolve requisição para SERVIDOR
6- SERVIDOR devolve requisição para CLIENTE
Se cache não tem requisição cacheada
5- RB faz requisição para LINK
6-LINK devolve requisição para RB
7- RB devolve requisição para CACHE
8- CACHE devolve requisição para RB (CACHEANDO OU NÃO)
9- RB devolve requisição para SERVIDOR
8- SERVIDOR devolve requisição para CLIENTE
Fim se
Fim se
Reparem que neste modo Paralelo existem 3 processamentos distintos, processamento da RB processamento do Servidor e processamento do Cache além do que a requisição percorre um longo caminho até ser devolvida ao cliente.
Em meu entendimento além do caminho longo percorrido e como ainda temos 3 processamentos distintos a sendo executados, existe uma considerável perda de performance nas requisições.


. CACHE COMO BRIDGE ENTRE SERVIDOR E LINK



1- CLIENTE faz requisição para SERVIDOR
2- SERVIDOR faz requisição para CACHE
Se cache tem requisição cacheada
5- CACHE devolve requisição para SERVIDOR
6- SERVIDOR devolve requisição para CLIENTE
Se cache não tem requisição cacheada
5- SERVIDOR faz requisição para LINK passando por dentro do cache transparente
6- LINK devolve requisição para SERVIDOR passando por dentro do cache transparente
7- SERVIDOR envia requisição para CACHE para cachear
8- SERVIDOR devolve requisição para CLIENTE
Fim se
Fim se

Reparem que neste modo Bridge existem 2 processamentos distintos, processamento do Cache e do Servidor e um caminho menor a ser percorrido por requisições , porém a fatos que podem ser preponderantes para uma perda de performance e neste caso tem a seguintes explicações :
- Como estão em modo Bridge , o Hardware do Cache e o hardware do servidor deveriam ser compatíveis e com o mesmo nível de qualidade e performance para que haja um sincronismo.
- Como os Caches não estão preparados para fazer exatamente um controle de tráfego (sabendo-se que a função dos mesmos não é esta) com certeza haverá uma perda de performance no envio e recebimento destas requisições que ficam passando por dentro dele indo e voltando.
Em todo caso ainda prefiro este modo comparando-se ao paralelo pois a performance deste considerando a quantidades de processamentos e caminhos de requisições é menor , desde que sejam bons hardwares para que tenham bom sincronismo é claro.

. CACHE COMO BRIDGE ENTRE SERVIDOR E CLIENTE




1- CLIENTE faz requisição para SERVIDOR passando por dentro do cache transparente
2- SERVIDOR faz requisição para CACHE
Se cache tem requisição cacheada
5- CACHE devolve requisição para SERVIDOR
6- SERVIDOR devolve requisição para CLIENTE
Se cache não tem requisição cacheada
5- SERVIDOR faz requisição para LINK
6- LINK devolve requisição para SERVIDOR
7- SERVIDOR envia requisição para CACHE para cachear
8- SERVIDOR devolve requisição para CLIENTE passando por dentro do cache transparente
Fim se
Fim se

Obs: Este segundo modo bridge diferencia-se do primeiro devido apenas a posição diferenciada do cache na topologia.

Reparem que neste modo Bridge existem 2 processamentos distintos, processamento do Cache e do Servidor e um caminho menor a ser percorrido por requisições , porém a fatos que podem ser preponderantes para uma perda de performance e neste caso tem a seguintes explicações :
- Como estão em modo Bridge , o Hardware do Cache e o hardware do servidor deveriam ser compatíveis e com o mesmo nível de qualidade e performance para que haja um sincronismo.
- Como os Caches não estão preparados para fazer exatamente um controle de tráfego (sabendo-se que a função dos mesmos não é esta) com certeza haverá uma perda de performance no envio e recebimento destas requisições que ficam passando por dentro dele indo e voltando.
Em todo caso ainda prefiro este modo comparando-se ao paralelo pois a performance deste considerando a quantidades de processamentos e caminhos de requisições é menor , desde que sejam bons hardwares para que tenham bom sincronismo é claro.


. CACHE COMO CLIENTE OU EM PARALELO COM O SERVIDOR




Obs1: O cache é ligado em uma ETH no servidor específica para ele

Obs2: Algumas vezes também são usadas RB MIKROTIK como servidor

Esta topologia é minha preferiada pois se trata de uma topologia com menos processamentos e com menos caminhos para as requisições percorrerem.

Para que este modo funcione corretamente tanto como cliente quanto paralelo com servidor é necessário uma programação devidamente correta para que haja um funcionamento com a perfonmace desejada no processamento e no encaminhamento das requisições.

1- CLIENTE faz requisição para SERVIDOR
2- SERVIDOR faz requisição para CACHE
Se cache tem requisição cacheada
5- CACHE devolve requisição para SERVIDOR
6- SERVIDOR devolve requisição para CLIENTE
Se cache não tem requisição cacheada
5- SERVIDOR faz requisição para LINK
6- LINK devolve requisição para SERVIDOR
7- SERVIDOR devolve requisição para CACHE caso a requisição precise ser cacheada e simultaneamente devolve a requisição que está sendo cacheada ao CLIENTE ou devolve diretamente para o CLIENTE caso a requisição não precise ser cacheada.
Fim se
Fim se

Reparem que neste modo com o Cache como cliente ou paralelo com o servidor, se tivermos um bom Hardware haverá um processamento central feito pelo Servidor economizando assim caminhos a serem percorridos por requisições.

.SERVIDOR CACHE GATEWAY



Este caso em específico deveria ser o melhor de todos devido à concentrar todos os processamentos, enviar e receber todas as requisições diretamente, porém a restrições que fazem com que seja ainda inviável esta aplicação :

1 - Neste caso precisamos de um hardware muito eficiente e de qualidade para fazer todos os processamentos que serão concentrados somente nele.

2 - Como necessitamos frequentemente de atualizações e reparos tanto no cache quanto no sistema de controle de banda , todas as vezes que necessitássemos de atulizações ou reparos tanto em um quanto o outro , o serviço de ambos seria pausado causando assim o interrompimento de suas funções e serviço.

3 - Um opinião pessoal ! Para pequenos provedores de internet, desconheço nos dias atuais um software a altura para que execute estas funções tanto no controle de banda quanto cache simultêneamente e devidamente sincronizado , aproveitando todo o processamento do hardware.

Marcio Marques
http://marquescsh.blogspot.com.br/p/topologias-do-cache-e-analise-dos-seus.html