Escalabilidade em Servidores Cache WWW

Goedson Teixeira Paixo a
Escalabilidade em servidores cache WWW
Dissertao apresentada ao Curso de Psca o Graduao em Cincia da Computao da ca e ca Universidade Federal de Minas Gerais, como requisito parcial para a obteno do grau de ca Mestre em Cincia da Computao. e ca
Belo Horizonte
Resumo O grande crescimento em popularidade da World Wide Web tem motivado vrias pesa quisas com o objetivo de reduzir a latncia observada pelos usurios. Os servidores cache e a tm-se mostrado uma ferramenta muito importante na busca desse objetivo. e Embora a utilizao de servidores cache tenha contribu para diminuir o trfego na ca do a Internet, as estratgias de cooperao utilizadas na composio de grupos (clusters) de e ca ca caches normalmente trazem uma degradao de desempenho aos servidores no sendo, por ca a isso, escalveis o suciente para acompanhar o crescimento atual da WWW. a Nesta dissertao, propomos uma nova forma de cooperao entre servidores cache que ca ca no causa um impacto to grande no seu desempenho, permitindo, assim, a criao de a a ca grupos de servidores cache que sejam capazes de crescer junto com a demanda dos seus usurios. a
Abstract The increasing popularity of the World Wide Web has led to signicant research targetting the reduction of the latency perceived by users. Cache servers proved to be an important resource in accomplishing this goal. Although the use of cache servers have reduced the data trac in the Internet, the cooperation strategies employed while building clusters of those servers scale poorly and are not able to sustain their throughput under increasing demands. In this work, we present a new cooperation strategy that does not aect signicantly the server performance. The use of this strategy allows clusters of cache servers to scale well with their usage growth.
ii
Agradecimentos
Gostaria de agradecer a todos que contribuiram para a realizao deste trabalho: ca Ao Wagner Meira Jr., no s pela orientao, mas, principalmente, pela amizade, a o ca pacincia e ajuda durante a realizao deste trabalho. e ca Aos meus colegas que proporcionaram um ambiente de trabalho agradvel e de consa tante busca de novos conhecimentos durante esse curso. Ao Joo Paulo Kitajima que, muito mais que um professor, foi um grande amigo durante a a sua estada na UFMG. Aos meus pais e irmos que, mesmo a quilmetros de distncia, sempre me incentivaram a o a a continuar na busca dos meus ideais. Finalmente, gostaria de agradecer ` Juliene, pelo carinho, pacincia e incentivo a cona e tinuar o meu trabalho, mesmo que isso `s vezes signicasse ser trocada pelo computador. a Ah! No posso esquecer da CAPES, o apoio nanceiro que tarda mas no falha. a a
iii
Sumrio a
Lista de Tabelas Lista de Figuras 1 Introduo ca 1.1 Motivao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ca 2 Trabalhos relacionados 2.1 Arquitetura da WWW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Cooperao entre servidores cache . . . . . . . . . . . . . . . . . . . . . . . ca 2.3 Limitaes dos mtodos de cooperao existentes . . . . . . . . . . . . . . co e ca 3 O servidor cache Squid 3.1 Viso geral do Squid . . . . . . . . . . . . . . . . . . a 3.2 Armazenamento de dados . . . . . . . . . . . . . . . 3.3 Estruturas de dados do Squid . . . . . . . . . . . . . 3.4 Funcionamento do Squid . . . . . . . . . . . . . . . . 3.4.1 Recebimento e atendimento de uma conexo . a 3.4.2 Recuperao de um objeto existente no cache ca 3.4.3 Recuperao de objeto em servidor parceiro . ca . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iv v 1 2 4 4 5 11 12 12 13 13 14 15 15 16 17 17 18 20 21 22 22 24 24 25 28 29 29 30 31 31 32 33 35
4 SHMSquid 4.1 Cooperao entre caches usando memria compartilhada . . . . . . . . ca o 4.2 Comunicao atravs de memria compartilhada . . . . . . . . . . . . . ca e o 4.3 O mdulo shmlib . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o 4.4 Implementao da cooperao usando memria compartilhada no Squid ca ca o 4.4.1 Congurao e compartilhamento dos dados . . . . . . . . . . . ca 4.4.2 Recuperao de um objeto em cache de outro servidor . . . . . ca 5 Anlise de desempenho do SHMSquid a 5.1 Mtricas de desempenho . . . . . . . . e 5.2 Critrios de anlise de desempenho . . e a 5.3 Ambiente experimental . . . . . . . . . 5.4 Anlise dos resultados . . . . . . . . . a 5.4.1 Cooperao . . . . . . . . . . . ca 5.4.2 Multiprocessamento . . . . . . . 5.4.3 Conectividade . . . . . . . . . . 5.4.4 Compartilhamento . . . . . . . 5.5 Discusso . . . . . . . . . . . . . . . . a 6 Concluses e trabalhos futuros o Bibliograa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
iv
Lista de Tabelas
5.1 5.2 5.3 Latncia do atendimento de clientes (segundos). . . . . . . . . . . . . . . . e Taxa de acerto no cache. . . . . . . . . . . . . . . . . . . . . . . . . . . . . Taxa de servio do servidor (operaes por segundo). . . . . . . . . . . . . c co 29 29 29
Lista de Figuras
2.1 2.2 2.3 2.4 5.1 5.2 Transao HTTP. . . . . . . . . . . . ca Transao HTTP com proxy. . . . . . ca Transao HTTP com consulta ICP. ca Falso acerto em um Cache Digest. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 6 7 9 27 30
Relao entre os critrios de anlise e as conguraes utilizadas. . . . . . . ca e a co Diferenas entre as vrias conguraes dos testes executados . . . . . . . c a co
Cap tulo 1 Introduo ca

A World Wide Web (referenciada neste trabalho como WWW ou Web) foi idealizada por Tim Berners-Lee, em maro de 1989, como um meio de divulgao de pesquisas e c ca novas idias pelo CERN, Centro Europeu de Pesquisa em F e sica de Part culas, localizado em Genebra, na Suca [4]. Foram desenvolvidos no CERN o primeiro servidor, o primeiro navegador WWW, a Hypertext Markup Language (HTML), uma linguagem para descrio ca de documentos para a Web, o Hypertext Transfer Protocol (HTTP), um protocolo de comunicao entre clientes e servidores e a forma de endereamento de objetos1 (URL, ca c Uniform Resource Locator ). Este desenvolvimento inicial foi divulgado pelo CERN em 1991. Em 1993 foi criado no NCSA, National Center for Supercomputing Applications, o Mosaic, primeiro navegador WWW com interface grca de fcil utilizao e multiplataforma, a a ca desenvolvido por Marc Andreseen. Neste mesmo ano, Robert McCool, outro pesquisador do NCSA, desenvolveu um novo programa servidor, menor e mais eciente que veio a se tornar a base para o servidor mais utilizado atualmente na WWW, o Apache[1]. Desde ento, a Web vem sofrendo um crescimento fantstico tanto em nmero de a a u usurios quanto em nmero de sites existentes. Para se ter uma idia desse crescimento, o a u e nmero de servidores Web em operao cresceu de 200 em 1993 para mais de 2 milhes em u ca o 1998[24]. H vrias justicativas para esse crescimento de utilizao: desenvolvimento de a a ca novos protocolos e linguagens que permitem o uso de dados multim dia, desenvolvimento de interfaces que permitem manipular esses dados, desenvolvimento da tecnologia de redes permitindo a interligao de computadores em escala global e, principalmente, a facilidade ca de compartilhar informaes a baixo custo. co
1
um objeto pode ser uma pgina de texto, uma imagem, um arquivo etc. a
CAP TULO 1. INTRODUCAO
1.1
Motivao ca
Desde a popularizao da WWW com o surgimento dos primeiros navegadores grcos ca a em 1993, muito esforo tem sido feito para reduzir a latncia percebida pelos seus usurios. c e a O acesso ` WWW pode se tornar lento por vrias razes. Os sistemas servidores se tornam a a o lentos quando submetidos a uma grande carga de requisies. Pode tambm haver congesco e tionamento nos canais responsveis pelo trfego dos dados entre o servidor e o usurio. a a a Uma estratgia comum, apesar do alto custo, de aliviar este problema aumentar a e e capacidade do recurso sobrecarregado: comprar um servidor mais rpido ou um link de a comunicao com maior largura de banda. Este mtodo, alm de no ser economicamente ca e e a vivel na maioria dos casos, ignora a diversidade das fontes de degradao de desempenho a ca a serem consideradas, mesmo em uma simples transao na Web. Alm do usurio e ca e a do servidor acessado, h provavelmente um grande nmero de provedores de servio que a u c participam do processo de prover a informao requisitada pelo usurio. Claramente, de ca a nada adiantaria aumentar a capacidade do servidor e dos seus links externos, se entre ele e o usurio existem canais com largura de banda que limita o nmero de requisies a u co atendidas. Por exemplo, a Netscape[20] poderia ter milhares de servidores e milhares de canais de comunicao que um usurio ainda precisaria de vrias horas para copiar a ultima ca a a verso do Navigator se o seu provedor utilizar apenas um link de 19,2Kbps para todas a as suas conexes. o Os servidores proxy, desenvolvidos inicialmente para permitir o acesso ` WWW por a usurios protegidos por rewalls, mostraram ser de grande utilidade, tambm, na reduo a e ca da latncia percebida por estes usurios no acesso ` Web, quando usados como servidores e a a proxy-cache (ou simplesmente cache). A utilizao de servidores cache provou ser uma tcnica util na reduo da latncia ca e ca e percebida pelo usurio nal. O conceito fundamental no qual se baseia o funcionamento a desses servidores a replicao de objetos populares da Web em um ponto mais prximo do e ca o usurio. Os benef a cios do uso de caches advm da repetio de acessos a um determinado e ca objeto. Se uma cpia do objeto armazenada no servidor cache na primeira vez em que ele o e acessado, os prximos acessos podem ser satisfeitos pela cpia local, no sendo necessrio e o o a a recorrer ao servidor original. Por exemplo, a maioria dos programas de navegao na ca Web possuem caches locais em disco porque, em geral, um usurio acessa um pequeno a conjunto de objetos freqentemente. Da mesma forma, h repetio de objetos acessados u a ca pelos membros de um dado grupo de usurios. Estes usurios poderiam beneciar-se da a a replicao desses objetos em um cache compartilhado em algum ponto da rede prximo ca o deles (seu provedor de acesso ` Internet, por exemplo). a Os caches WWW so implementados como agentes intermedirios entre o usurio a a a nal e os servidores Web. Estes agentes armazenam localmente os objetos acessados mais recentemente para que no seja necessrio recorrer ao servidor original em uma prxima a a o requisio. Embora a utilizao de caches tenha contribu para diminuir o trfego na ca ca do a Internet, as estratgias de cooperao utilizadas na composio de grupos (clusters) de e ca ca
CAP TULO 1. INTRODUCAO
caches normalmente trazem uma degradao de desempenho aos servidores [14, 15] no ca a sendo, por isso, escalveis o suciente para acompanhar o crescimento atual da WWW. a Neste trabalho, apresentamos um mtodo de comunicao entre servidores cache que e ca desenvolvemos[22] com o objetivo de minimizar o custo de processamento associado ` a cooperao entre eles, permitindo, assim, a criao de grupos de servidores que sejam ca ca capazes de crescer junto com a demanda de seus usurios. a Essa dissertao est dividida em seis cap ca a tulos. No cap tulo 2 fazemos a reviso de a estratgias de cooperao entre servidores cache j existentes, no cap e ca a tulo 3 descrevemos o servidor cache utilizado nesse trabalho, no cap tulo 4 descrevemos a nova estratgia de coe operao desenvolvida, no cap ca tulo 5 descrevemos os experimentos realizados e discutimos os resultados desses experimentos e no cap tulo 6 apresentamos as principais concluses e o contribuies obtidas neste trabalho e perspectivas de trabalhos futuros. co
Cap tulo 2 Trabalhos relacionados

O crescimento exponencial da Web e os problemas de desempenho causados por ele tm e incentivado diversas pesquisas que resultaram na criao de servidores cache e estratgias de ca e cooperao entre eles que sejam ecientes e escalveis. Neste cap ca a tulo, fazemos uma reviso a das estratgias de cooperao entre servidores cache existentes atualmente, analisando as e ca suas vantagens e seus problemas de escalabilidade.
2.1
Arquitetura da WWW
Clientes e servidores WWW comunicam-se atravs do protocolo HTTP. Este protocolo e funciona da seguinte forma (veja a Figura 2.1): 1. O cliente abre uma conexo com o servidor Web onde se encontra o objeto que deseja a recuperar; 2. O cliente envia para o servidor o nome (URL) do objeto desejado e quaisquer especicaes extras da transao (por exemplo, recuperar o arquivo somente se tiver sido co ca modicado aps determinada data); o 3. O servidor envia o objeto para o cliente e fecha a conexo. a Quando utilizamos um servidor proxy, a comunicao feita da seguinte forma (veja a ca e Figura 2.2): 1. O cliente abre uma conexo com o servidor proxy; a 2. O cliente envia para o servidor proxy a URL do objeto que deseja; 3. O servidor proxy abre uma conexo com o servidor Web; a 4. O servidor proxy envia para o servidor Web a URL do objeto desejado; 5. O servidor Web envia o objeto para o servidor proxy e fecha a conexo; a
CAP TULO 2. TRABALHOS RELACIONADOS
Cliente Servidor 1 CONECTA 2 URL
3 OBJETO
Figura 2.1: Transao HTTP. ca
6. O servidor proxy envia o objeto para o cliente e fecha a conexo. a No caso em que o servidor proxy faz, tambm, o servio de cache, os passos de 3 a 5 e c podem no ocorrer caso o proxy j tenha o objeto desejado no seu cache. a a No protocolo HTTP 1.0 [5], para cada objeto a ser recuperado, repetido o ciclo descrito e acima. Para recuperar uma pgina que contm 5 guras, por exemplo, so utilizadas 6 a e a conexes HTTP (1 para o texto da pgina e 1 para cada gura). O protocolo HTTP o a 1.1 [10] minimiza o nmero de conexes empregando conexes persistentes. u o o
2.2
Cooperao entre servidores cache ca
Nesta seo, descrevemos as estratgias de cooperao entre servidores cache existentes ca e ca atualmente, analisando as suas vantagens e seus problemas de escalabilidade. Internet Cache Protocol O ICP [28] um protocolo baseado em UDP/IP projetado para permitir a criao de e ca conjuntos de servidores cache que cooperam entre si. Este protocolo funciona da seguinte forma (veja a Figura 2.3): 1. O servidor, aps receber uma requisio HTTP e vericar a falta do objeto no seu o ca cache, envia para cada um dos seus parceiros uma mensagem ICP QUERY contendo a URL do objeto desejado;
Cliente
Proxy 1 CONECTA 2 URL 6 OBJETO
3 CONECTA 4 URL 5 OBJETO
Servidor
Figura 2.2: Transao HTTP com proxy. ca
2. Cada parceiro, ao receber a mensagem ICP QUERY, consulta o seu cache local e responde com uma mensagem ICP MISS caso esse objeto no esteja armazenado ou a ICP HIT caso esse objeto esteja armazenado; 3. O servidor que originou a pesquisa, ao receber a primeira resposta ICP HIT, estabelece uma conexo HTTP com o parceiro que enviou esta resposta para recuperar o objeto; a 4. O parceiro envia o objeto para o servidor que o solicitou; 5. O servidor envia o objeto para o cliente que originou a requisio. ca Uma grande desvantagem desse protocolo o atraso adicional introduzido pela troca e de mensagens ICP no tempo de resposta ao cliente. Como os servidores cache podem processar as mensagens ICP de forma bastante rpida, esse atraso , geralmente, pouco a e maior que o tempo de ida e volta de uma mensagem entre os servidores cooperantes. Outro problema grave do ponto de vista de escalabilidade do servidor, o fato de que e o nmero de mensagens trocadas proporcional ao produto entre o nmero de servidores u e u no grupo e o nmero de requisies HTTP recebidas levando a uma rpida degradao u co a ca no desempenho dos servidores quando submetidos a grandes cargas de trabalho com um nmero grande de parceiros [17]. u Cache Digests Na tentativa de eliminar o tempo adicional introduzido pela troca de perguntas e respostas no protocolo ICP, foi introduzida na verso 2.0 do servidor cache Squid[19] a consulta a
Parceiro 1
1 I
QU CP_
ERY
Cliente HTTP_GET
Servidor
_M ICP
ISS
Parceiro 2
1 ICP_QUERY 5 OBJETO 2 ICP_MISS 1 I CP_ QUE RY 2 I CP_ HIT 3 H TTP _GE T 4 O BJE TO
Parceiro 3
Figura 2.3: Transao HTTP com consulta ICP. ca
atravs de Cache Digests, que so resumos dos contedos dos caches dos servidores trocados e a u periodicamente entre eles. Um Cache Digest [26] consiste de um vetor de bits que podem estar ativados ou desativados. Para acrescentar uma entrada no Cache Digest, computamos um pequeno nmero u de funes hash independentes para a chave dessa entrada. Os valores das funes indicam co co quais os bits devem ser ativados. Para vericar a presena de uma determinada entrada c no Cache Digest, computamos as mesmas funes e vericamos os valores dos bits corresco pondentes, se todos estiverem ativados, h alguma probabilidade de que a entrada esteja a presente no cache. A remoo de uma entrada do Digest, no entanto, no pode ser feita ca a com a mesma facilidade porque no podemos simplesmente desativar os bits referentes ` a a entrada removida, pois isso poderia resultar na desativao de bits referentes a entradas que ca ainda esto presentes. Por isso, essa operao no implementada no Squid, sendo feita a ca a e periodicamente uma reconstruo do Digest incluindo as entradas referentes aos objetos ca presentes no cache em um Digest que se encontra inicialmente vazio. O tamanho do vetor de bits determina a probabilidade de uma pesquisa que encontra todos os bits ativados estar correta. A diminuio desse vetor resultar em um nmero ca a u maior de erros para o mesmo conjunto de dados. A cooperao entre servidores Squid utilizando Cache Digests funciona da seguinte ca forma: 1. O Squid, no in de sua execuo, solicita de cada um dos seus parceiros o Cache cio ca Digest local;
2. Ao receber um pedido de um objeto que no esteja presente no cache local, o servidor a consulta os Digests dos seus parceiros; 3. Caso algum dos Digests indique a probabilidade de existncia do objeto, o Squid e solicita ao parceiro correspondente o objeto desejado. A atualizao peridica das cpias remotas do Digest, assim como a cpia inicial, feita ca o o o e utilizando o protocolo HTTP. Este mtodo soluciona o problema da troca de mensagens a e cada requisio do protocolo ICP, tornando o sistema menos suscet a uma degradao ca vel ca no desempenho provocada por excesso de comunicao. No entanto, ele traz alguns novos ca problemas: 1. O Cache Digest uma estrutura de tamanho consideravelmente grande (geralmente e entre 200KB e 2MB). Como cada servidor deve armazenar localmente o Digest de cada parceiro, h um aumento signicativo no consumo de memria pelo Squid. a o 2. A atualizao peridica dos Digests provoca trfego em rajadas. ca o a 3. E poss que consultas ao Digest resultem em respostas erradas. vel Por exemplo, suponhamos um Cache Digest de 16 bits (representado na Figura 2.4) cujas funes hash so h1 e h2. A presena do objeto A no cache, causa a ativao co a c ca dos bits 3 e 7 do Digest enquanto a presena do objeto B ativa os bits 6 e 10. c Ao consultarmos esse Digest, procurando pelo objeto C, que ativaria os bits 10 e 3, concluiremos, erroneamente, que este objeto est presente no cache. a A probabilidade de ocorrncia de falsos acertos pode ser diminu atravs do aue da e mento do tamanho do Digest. A diminuio de falsos acertos, no entanto, pode ca no compensar a quantidade extra de dados que devero ser transmitidos entre os a a servidores. Uma consulta a um Digest desatualizado tambm pode resultar em erros indicando e a inexistncia de objetos que foram incorporados recentemente ao cache do servidor. e Ambas as situaes podem resultar em desperd de recursos. co cio 4. A reconstruo peridica do Digest pode ser uma operao computacionalmente inca o ca tensiva em caches com um grande volume de objetos armazenados.
CRISP Pesquisadores da AT&T e da Duke University desenvolveram em 1997 o Caching and Replication for Internet Service Performance (CRISP) [12], uma estratgia de cooperao e ca entre servidores cache baseada em diretrios. o Esta estratgia baseia-se na existncia de uma mquina centralizadora dedicada ` mae e a a nuteno de um diretrio das URLs dos objetos armazenados em todos os servidores cache ca o
A
Bit 15 0 0 0 0 0 1 0 0 1 1 0 0 1 0 0 0 0
B C
Objetos A e B presentes: h1(A)=3 h2(A)=7 h1(B)=6 h2(B)=10 h1(C)=10 h2(C)=3 Ao procurar por C, temos uma resposta positiva apesar de C estar ausente
Figura 2.4: Falso acerto em um Cache Digest.
do grupo. Cada servidor cache, ao adicionar ou remover um objeto do seu cache local, deve enviar uma mensagem ` mquina centralizadora informando a operao. Ao receber a a ca o pedido de um objeto que no est presente no seu cache, um servidor consulta o diretrio a a o na mquina centralizadora para saber em quais servidores esse objeto est armazenado (se a a estiver em algum deles). Recebendo a resposta da mquina centralizadora, o servidor estaa belece uma conexo HTTP com o parceiro que possui o objeto e o recupera, repassando-o a para o cliente. Esta estratgia reduz o nmero de comunicaes de consultas por requisio de N (no e u co ca caso de ICP) para 1 sem o custo adicional da transmisso de resumos dos caches dos a servidores. A existncia de um servidor de diretrio central, no entanto, apresenta os e o seguintes problemas: A indisponibilidade do servidor de diretrio transforma o grupo de servidores cache o em vrios servidores que no cooperam entre si. a a A centralizao de consultas no servidor de diretrios, pode levar a uma degradao ca o ca no desempenho do sistema com o crescimento da demanda e do nmero de servidores u atendidos por esse diretrio. o Alm disso, servidores que detm objetos muito populares, podem acabar sobrecarree e gados por serem muito requisitados por clientes e outros servidores, aumentando o tempo de resposta aos usurios. Este problema poderia ser resolvido se um servidor, ao recuperar a um objeto de um parceiro, armazenasse uma cpia no seu prprio cache. Essa medida, no o o
10
entanto, levaria a um desperd de espao de cache nos servidores devido ` existncia de cio c a e cpias dos mesmos objetos nos vrios servidores do grupo. o a CARP A Microsoft introduziu, em 1997, no Microsoft Proxy Server 2.0, o Cache Array Routing Protocol [17], um protocolo para cooperao entre servidores cache que permite, a qualquer ca servidor cache, descobrir, sem a necessidade de comunicao, qual servidor possivelmente ca possui um determinado objeto. Este protocolo funciona da seguinte forma: 1. Ao receber uma requisio de um cliente, o servidor calcula uma funo hash para a ca ca URL do objeto desejado; 2. O valor da funo hash para a URL combinado com o valor de uma outra funo ca e ca hash para cada um dos servidores do grupo; 3. O servidor, cuja combinao servidor+URL tiver o maior valor, o que dever conter ca e a o objeto. O servidor que recebeu o pedido estabelece uma conexo HTTP com aquele a que provavelmente possui o objeto e o recupera para o cliente. Esta estratgia consegue eliminar totalmente a comunicao efetuada para consultar os e ca servidores, sendo necessria apenas uma comunicao peridica entre eles para comunicar a ca o a sua disponibilidade. O espao de cache melhor aproveitado porque apenas um dos c e servidores do grupo possui uma cpia de cada objeto. o O fato de apenas um servidor possuir uma cpia de cada objeto, no entanto, pode o causar uma degradao no desempenho do sistema, j que todas as requisies por um ca a co objeto muito popular tero que passar pelo servidor que o possui (mesmo que a requisio a ca original tenha sido feita a um outro servidor) aumentando o nmero de requisies que u co esse servidor precisa tratar. Cisco Cache Engine O servidor cache da Cisco[8] pode ser utilizado de forma transparente para o usurio. a Os roteadores utilizando o Web Cache Control Protocol, interceptam todas as requisies co para o porto TCP do protocolo HTTP(80) e as redirecionam para um servidor cache que se encarrega de fazer o atendimento. Essa arquitetura permite a criao de grupos, ca particionando o conjunto de endereos IP entre os servidores do grupo. c Essa estratgia, como o CARP, tem a vantagem de no necessitar de consultas para e a determinar qual o servidor que possui um determinado objeto. Ela, no entanto, pode ser afetada pelo mesmo problema de degradao de desempenho para servidores que possuem ca objetos muito populares. Alm disso, a indisponibilidade de um dos servidores, pode tornar e imposs acessar os objetos pelos quais ele responsvel. vel e a
11
2.3
Limitaes dos mtodos de cooperao existentes co e ca
Os mtodos de cooperao entre servidores cache descritos neste cap e ca tulo podem comprometer o desempenho dos servidores que os utilizam. Nesta seao iremos discutir proc blemas comuns a todos eles, que fazem com que estes mtodos no utilizem ecientemente e a os recursos dispon veis. Os mtodos descritos utilizam sempre o protocolo TCP/IP [27] como base para a coe municao entre os servidores, ignorando a existncia de subsistemas de comunicao mais ca e ca ecientes e conveis como redes locais[7] e comunicao entre processos numa mesma a ca mquina via memria compartilhada. Projetado para prover uma comunicao convel a o ca a em ambientes de rede no conveis e a longas distncias, o protocolo TCP/IP inclui a a a vrios cabealhos e mecanismos para controle de erros desnecessrios em ambientes mais a c a conveis como as redes locais atuais. E notrio que uma mquina dedicada ` execuo a o a a ca de um servidor cache tem uma carga baixa de processamento[25], o que signica que seria vivel utilizar mais de um servidor cache ao mesmo tempo em uma mquina. O uso de a a mais de um processo servidor em uma mesma mquina torna este processamento extra a ainda mais indesejvel, pois o kernel precisa fazer todo um trabalho de diviso dos dados a a em pacotes, criao de cabealhos e clculos de checksums no envio dos dados, para em ca c a seguida desfazer todo esse trabalho para entregar os dados ao processo receptor. Um outro problema de desempenho dos mtodos j citados est no fato de que para cada e a a objeto recuperado de outro servidor estabelecida uma nova conexo de rede[5] cujo estado e a deve ser vericado periodicamente. Esta vericao feita, em geral, atravs da chamada ca e e de sistema select. Como esta chamada de sistema trabalha vericando, seqencialmente, u cada um dos descritores de arquivo passados para ela como parmetro, o maior nmero de a u conexes a serem verifcadas implica um maior tempo gasto pelo processo dentro do kernel o fazendo este trabalho[18]. Este aumento linear no tempo gasto para fazer a vericao ca do estado das conexes pode signicar um grande aumento no tempo total de servio o c quando o servidor est submetido a grandes cargas de trabalho, levando a uma degradao a ca signicante na sua capacidade de atendimento. Estes mtodos tm ainda a desvantagem de causar uma diminuio no desempenho e e ca no s do servidor que origina a requisio mas tambm no servidor que a atende, j que a o ca e a este ultimo precisa dedicar parte do seu tempo de processamento e da sua capacidade de comunicao ao primeiro como a um outro cliente qualquer. ca Ou seja, o custo do processamento de pacotes TCP/IP, aliado ` serializao do kernel, a ca tornam pouco escalveis os mtodos de cooperao entre servidores cache que utilizam a e ca conexes HTTP para o transporte de dados entre servidores. o
12
Cap tulo 3 O servidor cache Squid

O Squid [19] um servidor cache derivado do Harvest Project [9], desenvolvido na e Universidade do Colorado em Boulder. Atualmente o seu desenvolvimento liderado e por Duane Wessels do National Laboratory for Applied Network Research e nanciado pela National Science Foundation. Ele atende a requisies nos protocolos HTTP, FTP co e GOPHER, suportando conexes SSL (Secure Sockets Layer ) e um controle de acesso o que permite, por exemplo, especicar quais clientes podem fazer uso do servidor ou quais dom nios este servidor pode acessar. Este o servidor cache mais popular atualmente e, e como o seu cdigo fonte dispon gratuitamente, modicaes no seu funcionamento o e vel co podem ser feitas facilmente. Por essas razes escolhemos este servidor para este trabalho. o Nas prximas sees iremos descrever o seu funcionamento a m de subsidiar a elaborao o co ca de uma nova estratgia de cooperao. e ca
3.1
Viso geral do Squid a
O Squid utiliza um unico processo para atender a todas as requisies que recebe. Para co evitar que a espera pelo m de uma operao demorada, como a leitura de dados de um ca arquivo ou o recebimento de dados pela rede, impea a execuo de outras operaes, todo c ca co o processamento orientado a eventos e utiliza operaes ass e co ncronas. O mecanismo de eventos no Squid funciona da seguinte forma: Ao iniciar uma operao ass ca ncrona (uma leitura de arquivo, por exemplo), o Squid adiciona aquela operao ` sua lista de eventos pendentes, indicando qual rotina deve ca a ser chamada quando acontecer o evento esperado (por exemplo, o arquivo terminou de ser lido); Periodicamente o Squid verica se ocorreu algum evento pelo qual ele est esperando a (atravs da chamada de sistema select) e trata aqueles eventos que tenham ocorrido, e chamando as rotinas especicadas no momento de in das operaes. cio co
CAP TULO 3. O SERVIDOR CACHE SQUID
13
O Squid composto por trs programas principais (squid, dnsserver e unlinkd). O e e squid o responsvel pela funo principal do servidor, ou seja, atender `s requisies feitas e a ca a co por clientes. O dnsserver e o unlinkd so responsveis, respectivamente, pela traduo a a ca de nomes de dom nios para nmeros IP e pela remoo de arquivos quando solicitados pelo u ca squid. Esta separao em trs programas diferentes foi feita devido ao fato de que a traduo ca e ca de nomes de dom para endereos IP no pode ser feita de forma ass nio c a ncrona, a remoo ca de arquivos no precisa ser feita em tempo real e ambas podem ter um custo computacia onal alto. Como o Squid utiliza apenas um processo para atender a todas as requisies co recebidas, a execuo de uma dessas operaes iria bloquear o atendimento de outras reca co quisies, caso fosse feita pelo prprio processo squid. Para evitar esse bloqueio, o processo co o squid mantm um conjunto de processos dnsservers e unlinkds ativos e, quando necessita e executar tais operaes, envia uma requisio para um desses processos. co ca
3.2
Armazenamento de dados
Para evitar a utilizao de diretrios com um nmero muito grande de arquivos, o que ca o u resultaria em um tempo maior para as operaes de abertura de arquivos (quanto maior o co nmero de arquivos em um diretrio, mais demorada a operao de abertura de arquivos), u o e ca o Squid organiza os objetos do seu cache em disco da seguinte forma: No arquivo de congurao, o administrador dene um ou mais cache dirs; ca o a Para cada cache dir, ele dene o caminho do diretrio onde sero armazenados os seus dados, a quantidade mxima de dados a serem armazenados, o nmero de a u subdiretrios que devem ser criados no caminho especicado (diretrios de primeiro o o n vel) e o nmero de diretrios a serem criados em cada diretrio de primeiro n u o o vel (diretrios de segundo n o vel); Todos os arquivos so armazenados em algum dos diretrios de segundo n a o vel. Cada objeto identicado por um nmero que tambm indica o caminho exato do arquivo e u e que o contm. e
3.3
Estruturas de dados do Squid
O Squid foi projetado para ser um servidor cache eciente, otimizando o mximo a poss o tempo de resposta ao usurio. Para isso o Squid mantm em memria principal vel a e o objetos em trnsito, objetos quentes (aqueles objetos que so acessados mais freqena a u temente), dados sobre todos os objetos no cache (metadados do cache), o resultado das ultimas consultas ao DNS e os ultimos objetos que no puderam ser recuperados. Man a tendo todas estas estruturas em memria, o Squid evita: (1) fazer chamadas desnecessrias o a
14
ao DNS, (2) tentar buscar objetos inexistentes e (3) fazer acessos a disco para objetos muito populares. Duas estruturas de dados do Squid so diretamente relacionadas ` cooperao entre a a ca servidores: Metadados do cache: Um dos conjuntos de dados mais importantes mantidos pelo Squid o conjunto de metadados do cache. Estes dados so armazenados em uma e a tabela hash de StoreEntrys. Uma StoreEntry contm a assinatura MD5 [23] da e URL a que se refere o objeto, ultima vez que o objeto foi referenciado, quando foi modicado, prazo de expirao do objeto, tamanho do objeto e identicador do ca arquivo que contm esse objeto no cache alm de vrios outros dados sobre o estado e e a atravs de uma consulta a essa tabela que o Squid pode determinar se do objeto. E e um dado objeto est no cache e, em caso positivo, onde encontr-lo. a a Dados de congurao: O Squid mantm, em uma estrutura chamada Config, os ca e dados referentes ` congurao do servidor. Esta estrutura contm a denio de a ca e ca endereos nos quais o servidor atende a requisies, dados sobre outros servidores c co cache que podem ser consultados quando um objeto no encontrado localmente, a e quantidade de memria a ser utilizada pelo servidor, entre outras informaes. Para o co a implementao de uma estratgia de cooperao mais eciente, ser de grande ca e ca a importncia as informaes sobre quais os diretrios utilizados pelo servidor para a co o armazenar os objetos do cache. Estas informaes so mantidas no campo cacheSwap, co a na forma de um vetor de estruturas contendo o caminho, o nmero de diretrios no u o primeiro n e o nmero de diretrios no segundo n para cada diretrio denido vel u o vel o pela diretiva cache dir no arquivo de congurao. ca
3.4
Funcionamento do Squid
Como dito anteriormente, o Squid utiliza um unico processo para atender todas as requisies recebidas de clientes. Para que esse atendimento possa ser feito de forma co eciente, ele utiliza rotinas ass ncronas de entrada e sa de forma que o atendimento da a um cliente no seja interrompido enquanto se espera, por exemplo, o trmino de uma a e operao de leitura necessria para atender outro cliente. ca a Nesta seo, descreveremos o processo de atendimento de uma requisio HTTP (ouca ca tros protocolos funcionam de forma semelhante). Devemos lembrar que esta sequncia de e operaes no ser encontrada de forma to expl co a a a cita no cdigo fonte do Squid, j que a o a maioria das operaes de comunicao e acessos a disco so feitos de forma ass co ca a ncrona, atravs da instanciao de eventos a serem tratados quando a operao completada. e ca ca e A descrio que faremos nas sees a seguir no pretende ser uma descrio completa ca co a ca do funcionamento do servidor Squid, sendo omitidas, principalmente, o tratamento das condies de erro que podem ocorrer durante o processamento de uma requisio. O nosso co ca
15
objetivo permitir o entendimento da tarefa realizada sem explicar detalhes do cdigo do e o servidor.
3.4.1
Recebimento e atendimento de uma conexo a
Ao receber um pedido de conexo, o Squid aceita esse pedido e aguarda o envio da a requisio HTTP. Aps o recebimento da requisio, ele faz a anlise do texto recebido ca o ca a para determinar o mtodo utilizado (por exemplo, PUT ou GET) e a URL do objeto desejado, e fazendo em seguida, uma consulta ` tabela de metadados do cache para determinar se o a objeto existe no cache local. Caso o objeto exista no cache e a cpia existente ainda seja o vlida, o servidor envia o objeto para o cliente. Caso o objeto no exista no cache local, a a o Squid pode recorrer a algum servidor cache parceiro ou ao servidor HTTP que possui o objeto. O processo de recuperao de arquivos do cache e de colaborao entre servidores ca ca cache descrito com maiores detalhes nas prximas sees. e o co
3.4.2
Recuperao de um objeto existente no cache ca
Quando o Squid encontra o objeto solicitado pelo cliente no seu cache, este objeto pode estar na memria principal (por ser um objeto quente ou por ainda estar em trnsito) o a ou pode estar dispon somente no disco. vel No caso de o objeto estar dispon em memria principal, o processo de atendimento vel o bastante simples. Basta enviar os cabealhos da resposta HTTP e, em seguida, enviar e c partes do objeto at que todo o seu contedo tenha sido enviado. e u No caso de o objeto estar dispon somente no disco, no entanto, antes que se possa vel enviar qualquer dado ao cliente, necessrio determinar qual o arquivo que contm esse obe a e jeto. Para isso, o campo swap file number da StoreEntry referente ao objeto requisitado interpretado da seguinte forma: e e 1. Os oito bits mais signicativos determinam qual cache dir contm o arquivo; 2. Sendo L1 o nmero de subdiretrios no primeiro n do cache dir indicado e L2 u o vel o nmero de subdiretrios de segundo n u o vel, (swap file number/L2) mod L2 determina o diretrio de segundo n e (swap file number/L2/L2) mod L1 determina o vel o subdiretrio de primeiro n que contm o arquivo; o vel e 3. O nome do arquivo a representao hexadecimal de swap file number; e ca Uma vez determinado o arquivo que contm o objeto desejado, o Squid pode abrir este e arquivo e, em seguida, comear a envi-lo para o cliente ` medida em que o mesmo lido c a a e do disco.
16
3.4.3
Recuperao de objeto em servidor parceiro ca
Quando o Squid no encontra o objeto desejado no seu prprio cache, ele pode cona o sultar servidores parceiros sobre a existncia desse objeto e, caso algum parceiro tenha o e objeto, solicitar esse objeto atravs de uma requisio HTTP. Essa consulta pode ser feita e ca utilizando mtodos descritos no Cap e tulo 2: Internet Cache Protocol (ICP), Cache Digests ou Cache Array Routing Protocol. Como j dissemos anteriormente, esses mtodos de cooperao no tm boa escalabilia e ca a e dade e no so capazes de tirar um bom proveito dos recursos de comunicao existentes a a ca em redes locais, j que baseiam toda a sua comunicao no protocolo TCP/IP. No prximo a ca o cap tulo descrevemos uma nova estratgia de cooperao entre servidores cache desenvole ca vida com o objetivo de tirar o mximo proveito dos recursos de comunicao existentes, a ca eliminando os custos de consulta e reduzindo a transferncia de dados entre os servidores. e
17
Cap tulo 4 SHMSquid

Como dissemos na Seo 2.3, os mtodos tradicionais de cooperao entre servidores caca e ca che podem no fazer um bom uso dos recursos dispon a veis quando aplicados em instalaes co mais espec cas como redes locais de alta velocidade ou mquinas com vrios processadoa a res. Neste cap tulo, apresentamos a implementao de uma nova estratgia de cooperao ca e ca entre servidores cache projetada com o objetivo de eliminar os custos associados ` troca a de informaes entre os servidores. Essa estratgia utiliza as facilidades de comunicao co e ca dispon veis para processos que estejam executando em uma mesma mquina ou ambientes a de memria compartilhada distribu (DSM)[16, 6]. o da Na prxima seo, fazemos uma descrio do mtodo implementado, discutindo as o ca ca e suas vantagens e desvantagens quando comparado aos mtodos j existentes. Em seguida, e a explicamos mais detalhadamente a implementao deste mtodo no servidor Squid, a que ca e denominamos SHMSquid.
4.1
Cooperao entre caches usando memria comca o partilhada
A disponibilidade de mquinas com arquitetura SMP a baixo custo vem crescendo de a maneira acelerada. Isto torna vivel (e possivelmente mais barato devido ao compartilhaa mento de vrios componentes) a substituio de um grupo de servidores cache composta a ca por uma rede de mquinas de pequeno porte por uma mquina dotada de vrios procesa a a sadores semelhantes aos das mquinas originais. Esta substituio traria o benef a ca cio de uma comunicao mais eciente entre servidores executando nesta nova congurao (em ca ca comparao com servidores executando em mquinas separadas na rede original). Entreca a tanto, o servidor de cache Squid no capaz de tirar proveito desta nova capacidade de a e comunicao porque, como j explicamos, os seus mtodos de cooperao so baseados no ca a e ca a protocolo TCP/IP, no importando o meio de comunicao utilizado e ignorando recursos a ca que possam estar sendo compartilhados pelos processos.
CAP TULO 4. SHMSQUID
18
A m de aproveitar as facilidades de comunicao dispon ca veis para processos que estejam executando em uma mquina SMP, implementamos no Squid um novo mtodo de a e cooperao que permite que um servidor recupere dados existentes no cache de um parca ceiro sem interferir no processamento deste ultimo. A nova estratgia funciona da seguinte e forma: 1. Cada servidor cria um espao de memria compartilhado no qual coloca a sua tabela c o de StoreEntrys; 2. Ao receber uma requisio, o servidor procura na sua prpria tabela de StoreEntrys ca o pela existncia do objeto desejado (como j feito normalmente); e ae 3. Caso no encontre o objeto desejado, o servidor procura na tabela de cada um de a seus parceiros pela existncia do objeto; e 4. Se o objeto encontrado na tabela de algum dos parceiros, o processamento da e requisio continua como descrito na Seo 3.4.2, diferindo apenas na localizao do ca ca ca arquivo, que agora feita com base na congurao do parceiro em lugar da prpria e ca o congurao do servidor. ca Fazendo a recuperao de objetos existentes no cache de parceiros desta forma, evitamos ca os custos de comunicao e eliminamos as vrias chamadas de sistema feitas para troca de ca a dados entre os servidores tornando o custo deste atendimento igual ao de um atendimento satisfeito pelo cache local. A principal desvantagem deste mtodo, com relao aos mtodos j existentes, vem e ca e a do fato de o parceiro no participar na transao e, portanto, no contabilizar o acesso a ca a feito. Como o acesso feito via memria compartilhada no contabilizado pelo servidor o a e que controla aquele objeto, a sua lista de objetos utilizados mais recentemente no ca a corretamente atualizada podendo acontecer de ele eliminar do seu cache um objeto que foi acessado recentemente pelos seus parceiros (mas no por ele prprio) e conservar objetos a o menos acessados ocasionando uma taxa de acerto global mais baixa. Este problema, no entanto, pode ser resolvido pela implementao de um mecanismo de comunicao entre ca ca os servidores que torne poss informar ao parceiro sobre a utilizao de objetos do seu vel ca cache.
4.2
Comunicao atravs de memria compartilhada ca e o
A variao System V dos sistemas operacionais UNIX [2] introduziu trs mecanismos ca e de comunicao entre processos que esto atualmente dispon ca a veis na maiorias das verses o de UNIX dispon veis no mercado. Entre esses mecanismos de comunicao est o uso de ca a memria compartilhada, que descreveremos nesta seo. o ca
19
A implementao de memria compartilhada no System V permite que um processo ca o compartilhe uma regio do seu espao de endereamento e atribua a essa regio permisses a c c a o de acesso para leitura e/ou escrita, discriminando entre processos do mesmo usurio, proa cessos de usurios do mesmo grupo ou processos de usurios de outros grupos. Um oua a tro processo pode, ento, anexar essa regio de memria ao seu prprio espao de ena a o o c dereamento e acessar os dados nela contidos utilizando as mesmas instrues que usaria c co para acessar qualquer outra parte da sua memria (obedecendo as restries de acesso o ` co estabelecidas pelo processo criador). Para manipular regies de memria compartilhada, o o um processo deve utilizar as seguintes chamadas de sistema: int shmget(key, size, flags) - Esta chamada de sistema utilizada para criar e um novo segmento de memria compartilhada ou obter o identicador de um sego mento j existente. O sistema procura na tabela de memria pela chave key: se a a o encontra e o controle de acesso atribu ` regio permite o acesso, retorna o idendo a a ticador da regio (que pode ser usado para anexar a regio de memria ao espao a a o c de endereamento do processo). Caso no seja encontrada uma entrada associada ` c a a chave key e a opo IPC CREAT tenha sido especicada no parmetro flags, o sisca a tema verica que o tamanho especicado esteja entre o tamanho m nimo e mximo a denidos para regies compartilhadas e aloca a regio com o tamanho especicado e o a retorna o seu identicador. void* shmat(id,addr,flags) - Esta chamada usada para acoplar uma regio de e a memria compartilhada ao espao de endereamento do processo. O parmetro id o c c a e o valor retornado por shmget e identica a regio de memria a ser acoplada, addr a o o endereo onde o usurio quer acoplar a memria compartilhada e flags indica e c a o se a memria vai ser usada somente para leitura (SHM RDONLY) e se o sistema deve o a e fazer alinhamento do endereo (SHM RND) passado pelo usurio. O valor de retorno c o endereo onde a regio foi realmente acoplada que pode ser diferente do endereo c a c fornecido. Se o endereo fornecido na chamada a shmat igual a 0, o sistema procura c e por um endereo onde a regio de memria possa ser acoplada. c a o int shmdt(addr) - Esta chamada remove a regio de memria compartilhada que foi a o acoplada em addr do espao de endereamento do processo e retorna o identicador c c da regio especicada. a shmctl(id,cmd,buf) - Esta chamada utilizada para ler ou alterar vrias infore a maes relacionadas ` regio de memria compartilhada identicada por id. O co a a o parmetro cmd pode assumir os valores IPC STAT (para ler informaes sobre a regio a co a de memria), IPC SET (para alterar informaes sobre a memria compartilhada) ou o co o IPC RMID (para marcar a regio para ser removida quando no houver mais processos a a que a estejam utilizando). O parmetro buf deve ser um apontador para uma esa e a co a o trutura do tipo shmid ds, que contm vrias informaes sobre a regio de memria
20
compartilhada, como, por exemplo, permisses de acesso, ultima vez que foi acoplada o por um processo, ultima vez que foi removida do espao de endereamento de um c c processo, nmero de referncias, identicador do usurio que criou etc. u e a
4.3
O mdulo shmlib o
Para facilitar a utilizao de memria compartilhada no Squid implementamos um ca o mdulo que nos permite criar um segmento de memria compartilhada e gerenciar esse o o espao fornecendo uma interface para alocao e liberao de memria semelhante `s c ca ca o a funes calloc e free da biblioteca C padro. Esse mdulo fornece as seguintes funes co a o co para manipulao da memria compartilhada: ca o int shm init(key, size) - Esta funo cria um segmento de memria associado ca o ` chave key com tamanho suciente para conter size bytes mais um apontador, a ou seja, o tamanho m nimo do bloco size + sizeof(void*). O nmero de bytes e u dispon veis para alocao no segmento de memria inicializado por shm init igual ` ca o e a menor potncia de 2 que seja maior ou igual ao valor size. O valor de retorno igual e e a 0 em caso de sucesso e o endereo no qual o segmento de memria compartilhada c o foi acoplado colocado na primeira palavra do segmento para permitir que outros e processos traduzam apontadores que possam estar contidos nesse segmento para o seu prprio espao de endereamento. Esta funo cria tambm as listas de blocos o c c ca e de memria livres e alocados utilizadas no gerenciamento do espao de memria o c o compartilhada. ca o void *shm connect(key) - Esta funo acopla o segmento de memria associado com a chave key ao espao de endereamento do processo em modo de somente c c leitura e retorna o apontador para a rea onde o segmento foi acoplado. a shm disconnect(mem) - Esta funo retira do espao de endereamento do processo ca c c o segmento de memria apontado por mem. Caso o segmento tenha sido marcado o para remoo e no haja mais processos o utilizando, ele ser liberado pelo sistema. ca a a ca o shm clear(mem) - Esta funo marca o segmento de memria apontado por mem para ser removido quando no houver mais processos que o estejam utilizando. a SHARED PTR(base, ptr) - Esta macro permite a um processo traduzir endereos c contidos no segmento de memria compartilhada do espao de endereamento do o c c processo criador do segmento para o seu prprio espao de endereamento de forma o c c a poder referenciar a memria apontada por ele. O parmetro base o endereo onde o a e c o segmento foi acoplado no espao de endereamento do processo e ptr o apontador c c e a ser traduzido. Esta macro utiliza o fato de o segmento de memria conter em sua o primeira posio o endereo inicial na memria do processo criador. ca c o
21
A funo shm calloc(n, size) aloca um bloco de tamanho suciente para conter ca n size bytes na regio de memria compartilhada inicializada por shm init. O algoritmo a o utilizado na alocao o seguinte: ca e 1. Fazemos block size igual ` menor potncia de 2 que seja maior ou igual a n size; a e 2. Procuramos por um bloco livre de tamanho igual a block size e retornamos o endereo desse bloco caso ele exista adicionando-o ` tabela de blocos alocados; c a 3. Caso no existam blocos livres de tamanho block size, procuramos por um bloco a de tamanho maior e, se encontrarmos, dividimos esse bloco em partes menores at e conseguirmos um bloco de tamanho block size, o endereo do bloco encontrado c e ento retornado pela funo e adicionamos esse bloco ` tabela de blocos alocados; a ca a 4. Se no conseguimos encontrar um bloco de tamanho suciente nos passos 2 e 3, a a funo retorna NULL. ca A funo shm free(addr) usada para liberar o bloco de memria iniciado em addr ca e o que foi alocado com a funo shm calloc. O algoritmo que implementamos na funo ca ca e shm free o seguinte: 1. Procuramos o endereo addr na tabela de blocos alocados. Se no encontramos o c a endereo, ele no foi alocado usando shm calloc e acusamos um erro no programa; c a 2. Se encontramos o bloco correspondente a addr, passamos o seu descritor para a tabela de blocos livres; 3. Se o bloco sendo liberado cont e guo a um outro do mesmo tamanho, ns os unimos o em um unico bloco e o inserimos na lista de blocos com tamanho igual ao dobro do anterior. Este passo repetido at que o bloco seja inserido em uma lista onde no e e a haja blocos cont guos a ele.
4.4
Implementao da cooperao usando memria ca ca o compartilhada no Squid
Neste trabalho, zemos a implementao de um mecanismo de colaborao entre serca ca vidores cache que permite que um processo recupere objetos existentes no cache de um outro processo sem a interveno deste ultimo, buscando reduzir o custo de colaborao ca ca entre servidores que estejam sendo executados em uma mesma mquina. a Nesta seo descrevemos os pontos principais da implementao deste mecanismo de ca ca colaborao. ca
22
4.4.1
Congurao e compartilhamento dos dados ca
Para permitir o compartilhamento de dados entre os servidores Squid atravs de mee mria compartilhada, adicionamos os seguintes parmentros ao arquivo de congurao: o a ca shm key key - Este um parmetro obrigatrio no SHMSquid. Ele determina que e a o key ser a chave utilizada para criao do segmento de memria compartilhada. Este a ca o valor ser usado pelos parceiros existentes na mesma mquina para acessar os dados a a compartilhados pelo servidor. O parmetro key deve ser um valor inteiro. a a o shm size size - Este parmetro determina o tamanho do segmento de memria compartilhada a ser utilizada pelo servidor. Este valor deve ser grande o suciente para todas as StoreEntrys que sero criadas durante o seu funcionamento. Este a parmetro pode ser omitido, sendo assumido o valor padro de 8 MB. a a shm peer key - Este parmetro utilizado para indicar a chave utilizada por outro a e servidor para alocar a sua memria compartilhada, permitindo ao Squid acessar os o dados que esse servidor colocou nessa rea. Deve haver uma entrada shm peer para a cada servidor com o qual queiramos colaborar via memria compartilhada e o valor o key deve ser igual ao valor especicado por shm key na congurao dos outros ca servidores. A estrutura de congurao Config foi modicada para incluir os novos dados de ca congurao sendo que o campo shm peers possui uma lista de parceiros contendo, para ca cada um deles, um apontador para a sua tabela de StoreEntrys, a sua congurao de ca diretrios de cache e o endereo onde se inicia a memria compartilhada daquele servidor. o c o Aps a leitura do arquivo de congurao, o Squid cria o segmento de memria comparo ca o c tilhada denido no arquivo de congurao (usando a funao shm init) e aloca espao no ca c in desse segmento para uma estrutura contendo dois apontadores: um para a cpia das cio o suas conguraes de diretrios cache colocada na memria compartilhada e outro para a co o o tabela hash contendo as suas StoreEntrys (que passam a ser todas alocadas atravs da e funo shm calloc). ca Para que um processo possa distinguir as suas prprias StoreEntrys das criadas por o outros processos, acrescentamos ` estrutura da StoreEntry o campo owner key onde o a criador da entrada armazena a chave denida por shm key no arquivo de congurao. ca Desta forma, o servidor capaz no s de saber que aquela entrada pertence a outro e a o processo como tambm identicar na sua congurao os dados necessrios para recuperar e ca a o objeto a que a entrada se refere.
4.4.2
Recuperao de um objeto em cache de outro servidor ca
Nesta seo iremos descrever o mecanismo de recuperao de objetos que se encontram ca ca no cache de servidores que esto congurados para colaborar atravs da utilizao de a e ca memria compartilhada. o
23
O servidor SHMSquid coloca todas as suas StoreEntrys na regio de memria coma o partilhada, de forma que um outro processo possa consultar o contedo do seu cache sem u que, para isso, seja necessrio interferir no seu processamento. Para evitar condies de a co corrida que poderiam surgir no caso de haver um compartilhamento total desses dados (com processos podendo modicar as StoreEntrys de outros processos), decidimos que um servidor acessaria a memria de outros em modo de somente leitura. o Como mencionado na Seo 4.1, a maior parte do atendimento feito utilizando dados ca obtidos via memria compartilhada semelhante ao atendimento de uma requisio usando o e ca dados do prprio servidor. Aqui iremos descrever os pontos em que estes atendimentos o diferem. Durante o atendimento normal, o Squid cria uma estrutura MemObject associando-a ` a StoreEntry encontrada. Esta estrutura contm dados como o tamanho do objeto sendo e transmitido, quanto est em memria (j foi lido do disco) e quanto j foi enviado, servindo a o a a para o Squid controlar o envio do objeto. Mas, para fazer o atendimento utilizando os dados de outro processo, no podemos modicar a StoreEntry e, por isso, no podemos fazer a a a associao do MemObject como o Squid faz normalmente. Desta maneira, precisamos ca criar uma nova estrutura chamada ShmHitCallbackData que utilizamos durante o atendimento. Essa estrutura contm apontadores para a StoreEntry encontrada, o MemObject, e a requisio sendo atendida e a congurao de diretrios do servidor que controla o objeto ca ca o desejado. Como a maior parte das rotinas utilizadas no atendimento de uma requisio recebe uma ca StoreEntry como parmetro e acessa os outros dados necessrios (MemObject, por exema a plo) atravs dela, precisamos implementar novas rotinas que recebem, como parmetro, e a ShmHitCallBackData e fazem acessos aos dados necessrios atravs dessa estrutura. Esa e tas rotinas, no entanto, foram implementadas seguindo a mesma losoa de atendimento utilizada no tratamento de um hit. Desta forma, apesar de o atendimento a um hit local e a um hit em memria compartilhada serem realizados por conjuntos diferentes de rotinas, o eles so feitos de maneira semelhante. a Como esta nova estratgia no traz custos adicionais devidos ` cooperao entre os e a a ca servidores cache, esperamos que ela venha a ser uma opo mais eciente na implementao ca ca de servidores cache escalveis, ou seja, servidores que possam ser utilizados para a formao a ca de grupos maiores sem haver degradao no seu desempenho. ca
24
Cap tulo 5 Anlise de desempenho do a SHMSquid

Neste cap tulo descrevemos os experimentos realizados a m de vericar a ecincia da e estratgia de cooperao proposta no ultimo cap e ca tulo e discutimos os resultados obtidos. Na prxima seo denimos as mtricas de desempenho que utilizamos para comparar os o ca e resultados dos experimentos. Em seguida denimos os critrios de anlise que utilizamos e a durante o trabalho e que serviram para denir os experimentos realizados. Finalmente, apresentamos os resultados obtidos e discutimos estes resultados, nas duas ultimas sees. co
5.1
Mtricas de desempenho e
A anlise de desempenho de servidores cache aqui apresentada se basear nas seguintes a a mtricas: e Latncia: o tempo necessrio para o servidor atender a uma requisio de um cliente. e e a ca Esta mtrica composta por trs medidas: e e e cliente - Esta medida a mdia do tempo de resposta aos clientes que acessam e e os servidores. O tempo de resposta de cada requisio calculado sob a persca e pectiva do cliente, sendo o tempo decorrido entre o pedido de conexo e o nal a do recebimento do objeto pedido. hit - Esta medida equivale ` mediana do tempo de servio para prover objetos a c constantes do cache local do servidor. Este tempo de servio calculado pelo c e servidor como o tempo decorrido entre o recebimento do pedido de conexo e a a concluso do envio do objeto pedido. a miss - Esta medida equivale ` mediana do tempo de servio para objetos que a c no foram encontrados no cache local do servidor. O clculo deste valor feito a a e pelo servidor da mesma forma que o clculo do valor hit. a
CAP TULO 5. ANALISE DE DESEMPENHO DO SHMSQUID
25
Ecincia: a parcela das requisies recebidas pelo servidor que resulta em um acerto e e co no cache (i.e., o objeto est no cache do servidor). Essa mtrica composta de duas a e e medidas: local - Esta medida equivale ` parcela das requisies recebidas que o servidor a co responde com objetos do seu prprio cache. o cooperao - Esta medida equivale ` parcela das requisies recebidas que ca a co o servidor responde com objetos encontrados no cache de seus parceiros (i.e., outros servidores cache com os quais ele coopera). Taxa de servio: Atravs desta mtrica, poderemos vericar a quantidade de trabac e e lho realizado por um servidor por unidade de tempo. Esta mtrica baseada nas e e seguintes medidas feitas pelo servidor Squid: requisies - Esta medida equivale ao nmero mdio de requisies HTTP co u e co atendidas pelo servidor por segundo. disco - Esta medida equivale ao nmero mdio de operaes de disco feitas pelo u e co servidor por segundo. rede - Esta medida equivale ao nmero mdio de operaes de rede feitas pelo u e co servidor por segundo. Utilizando essas mtricas, poss comparar o desempenho das vrias conguraes e e vel a co utilizadas, identicando os ganhos e perdas devidos `s estratgias utilizadas. a e
5.2
Critrios de anlise de desempenho e a
Nesta seo, descrevemos os quatro critrios em que nos baseamos para denir os exca e perimentos a serem realizados e discutimos os poss veis ganhos e perdas que a adoo ou ca no de cada um deles em uma congurao podem trazer. Nesta discusso consideraa ca a mos a utilizao de dois servidores Squid, apesar de esses critrios serem aplicveis para ca e a grupos maiores de servidores. Em [21] analisamos o comportamento do SHMSquid em conguraes com maior nmero de processadores. co u Cooperao - A utilizao de cooperao entre servidores pode trazer um ganho signica ca ca cativo em taxa de acerto no cache. Por outro lado, esta mesma cooperao pode ca causar um aumento no tempo de servio de requisio. Comparando experimentos c ca onde h cooperao entre os servidores com outros onde essa cooperao no existe, a ca ca a poderemos determinar os ganhos e perdas criados pela cooperao. ca Multiprocessamento - A utilizao de uma mesma mquina para executar os dois ca a servidores pode trazer o benef de uma comunicao mais eciente entre eles, micio ca nimizando, desta forma, o aumento no tempo de servio causado pela cooperao. c ca
26
Por outro lado, o compartilhamento dos recursos da mquina entre os dois servidoa res pode diminuir ou at anular os benef e cios de uma comunicao mais eciente. ca Comparando experimentos onde h multiprocessamento com experimentos nos quais a os servidores so executados em mquinas separadas, poderemos avaliar os custos e a a benef cios da adio do multiprocessamento. ca Conectividade - Ao utilizarmos uma mesma mquina para executar os dois servidores, a podemos congurar os dois para acessarem a rede atravs de uma mesma interface e ou, se dispusermos de mais de uma interface de rede, congur-los para acessarem a a rede atravs de interfaces diferentes. Ao compartilharem a mesma interface de e rede, os servidores podem ter o seu desempenho reduzido devido a disputa pelo uso ` simultneo desse recurso. Comparando experimentos em que os servidores compartia lham a mesma interface de rede com experimentos nos quais eles utilizam interfaces diferentes para acessar a rede, poderemos determinar o ganho de termos interfaces distintas para cada um dos servidores. Compartilhamento - O compartilhamento de memria entre os servidores Squid pode o proporcionar um aumento na ecincia da cooperao entre os servidores, j que, e ca a desta forma, a troca de dados entre os dois pode ser feita de uma forma mais rpida do a que a comunicao atravs de mensagens TCP/IP utilizadas normalmente. Compaca e rando conguraes que utilizam o compartilhamento de memria com conguraes co o co que no a utilizam, poderemos determinar o ganho advindo deste compartilhamento a e poss veis perdas relacionadas com a nova estratgia de cooperao. e ca Tomando como base os critrios descritos, denimos os experimentos a realizar a m e de vericar o desempenho do servidor Squid em diferentes ambientes e, principalmente, analisar o desempenho da nova estratgia de cooperao que desenvolvemos. A seguir, e ca descrevemos mais detalhadamente cada uma das conguraes utilizadas e a motivao co ca para elas. double - esta congurao corresponde ao modo mais usual de utilizao do servidor ca ca Squid na composio de grupos de servidores cache. Ela consiste de duas mquinas ca a executando, cada uma delas, um servidor Squid, esses servidores cooperam entre si atravs de ICP e Cache Digests. Esta congurao, por ser a forma mais comum de e ca composio de um grupo de servidores, servir como base de comparao. ca a ca dual - nesta congurao, utilizamos, como servidora de cache, uma mquina doca a tada de dois processadores e duas interfaces de rede. Essa mquina executa dois a servidores Squid, cada um deles fazendo acesso ` rede atravs de uma das interfaces. a e A comparao entre os resultados obtidos com esta congurao e os resultados da ca ca congurao double prov informaes sobre os ganhos de uma comunicao mais ca e co ca eciente entre os dois servidores (j que eles no precisam mais utilizar a rede para as a a suas comunicaes). Por outro lado, pode haver uma perda de desempenho por causa co
27
Co
p oo
a er
Se
co
op
er
ad
ad ss
o
Un ip
Un ip
ss
ce
ce
ro
ro
ip
ip
lt
lt
Mu
Mu
double 2 interfaces de rede
i dente rerfa de ce
fakedual dualnosibling
m Se
SH M
shm
Co
dual
Figura 5.1: Relao entre os critrios de anlise e as conguraes utilizadas. ca e a co
do compartilhamento de recursos do sistema, devido ao grande nmero de chamadas u de sistema. double-no-sibling - nesta congurao, utilizamos duas mquinas servidoras, cada ca a uma delas executando um servidor Squid sem utilizar cooperao entre eles. Comca parando os resultados dessa congurao com os resultados da congurao double, ca ca poderemos determinar os ganhos e preju zos advindos da cooperao entre os servica dores. dual-no-sibling - nesta congurao, utilizamos uma mquina com dois processaca a dores e duas interfaces de rede para executar dois servidores Squid sem que eles cooperem entre eles. Atravs da comparao dos resultados desta congurao com e ca ca os da congurao double-no-sibling, pretendemos descobrir qual a perda de deca sempenho devida ao fato de os dois servidores estarem compartilhando a mesma mquina. As perdas observadas nesta comparao devem ser originadas, principala ca mente, do fato de alguns segmentos de cdigo do kernel no poderem ser executados o a simultaneamente por dois processadores em modo kernel. fake-dual - nesta congurao, utilizamos uma mquina com dois processadores execa a cutando dois servidores Squid que no cooperam entre si. Os dois servidores, no ena tanto, atendem requisies utilizando uma mesma interface de rede. Atravs da comco e parao entre os resultados desta congurao e os resultados da dual-no-sibling, ca ca pretendemos determinar o ganho proporcionado pela utilizao de mais de uma inca
ro ce ss ad o
ro ce ss ad o
ces rfa e nte red 2 i de
doublenosibling
M SH
CAP TULO 5. ANALISE DE DESEMPENHO DO SHMSQUID terface de rede.
28
shm - nesta congurao, utilizamos uma mquina dotada de dois processadores ca a e duas interfaces de rede para executar dois servidores Squid cooperando atravs e do uso de memria compartilhada. Comparando os resultados dessa congurao o ca com os resultados das conguraes double e dual, poderemos determinar os ganhos co e perdas no desempenho do servidor devidos ` utilizao dessa nova estratgia de a ca e cooperao. ca Analisando os dados obtidos atravs destes experimentos, pretendemos vericar a ee cincia da cooperao atravs de memria compartilhada na implementao de servidores e ca e o ca cache escalveis. a
5.3
Ambiente experimental
Nos experimentos realizados durante este trabalho, utilizamos a metodologia para anlise de desempenho de hierarquias de servidores cache sugerida em [11]. a Utilizamos como servidores cache dois PCs multiprocessados, com processadores PentiumPro de 200MHz e 128Mb de memria cada um, executando o sistema operacional o Solaris 7. Essas mquinas se comunicam atravs de um cabo serial, com velocidade de a e 38.400bps. Em todos os experimentos, os servidores Squid foram congurados para utilizar 20Mb de memria e 50Mb de espao em disco. o c Como servidores HTTP, utilizamos 3 estaes SPARCstation SLC executando, cada co uma delas, um processo que faz o atendimento de requisies HTTP gerando um arquivo co baseado na URL pedida e introduzindo um atraso na resposta proporcional ao tamanho desse arquivo simulando, desta forma, os atrasos experimentados em acessos de longa distncia atravs da Internet. a e As requisies de objetos foram geradas por quatro estaes SPARCstation SLC (duas co co acessando cada servidor cache), utilizando uma carga de trabalho baseada em logs do servidor cache do POP-MG[13]. Analisamos um log que contm 4.235.511 requisies para e co 1.079.044 objetos diferentes totalizando aproximadamente 12 Gb de dados. Para os nossos experimentos, geramos um conjunto de 80,000 requisies, conservando as caracter co sticas de popularidade de documentos e distribuio das requisies no tempo obtidas atravs ca co e dessa anlise. Este conjunto de requisies dividido entre os clientes, de forma que cada a co e um deles gera uma seqncia de 20.000 requisies HTTP para os servidores cache. ue co Todas as estaes SPARCstation SLC esto ligadas aos servidores cache atravs de uma co a e rede Ethernet de 10Mbps chaveada.
29
5.4
Anlise dos resultados a
Nesta seo, faremos uma anlise dos resultados obtidos nos experimentos que realizaca a mos. As medidas so apresentadas nas Tabelas 5.1 (latncia), 5.2 (ecincia) e 5.3 (taxa a e e de servio). Analisaremos esses resultados nas prximas sees, tomando como base os c o co critrios apresentados na Seo 5.2. e ca Congurao Cliente ca Hit Miss double-no-sibling 7.3100 0.0028 3.2853 double 6.6830 0.0042 2.6625 dual-no-sibling 7.8090 0.0037 3.5638 dual 7.1829 0.0046 2.7939 fake-dual 7.8117 0.0037 3.5638 shm 6.3365 0.0028 2.5775 Tabela 5.1: Latncia do atendimento de clientes (segundos). e
Congurao ca double-no-sibling double dual-no-sibling dual fake-dual shm
Local Cooperao ca 0.3097 0.2750 0.1822 0.3127 0.2732 0.1927 0.3150 0.2432 0.1410
Total 0.3097 0.4567 0.3127 0.4662 0.3150 0.3842
Tabela 5.2: Taxa de acerto no cache.
Congurao Requisies ca co double-no-sibling 3.1475 double 3.8325 dual-no-sibling 3.1705 dual 3.9010 fake-dual 3.1644 shm 3.6044
Disco 22.8480 25.9467 22.6536 24.8328 22.6238 25.4615
Rede 53.2459 74.0923 52.1093 70.0355 51.8748 55.6723
Tabela 5.3: Taxa de servio do servidor (operaes por segundo). c co
5.4.1
Cooperao ca
Ao comparamos os dados de latncia das conguraes que utilizam cooperao com e co ca os dados das conguraes em que os servidores no cooperam (comparando double com co a double-no-sibling e dual com dual-no-sibling) podemos vericar que a cooperao ca proporciona um tempo mdio de resposta menor devido a uma maior taxa de acerto (aproe ximadamente 50% mais alta nas conguraes que utilizam cooperao). Podemos ver, co ca
30
Multipro cessamento double Cooperao dual
Compartilhamento de Memria shm

Co op
er
Multipro double cessamento no sibling
2 interfaces de rede fakedual
dualno sibling
Figura 5.2: Diferenas entre as vrias conguraes dos testes executados c a co
no entanto, que a latncia para os hits maior nas conguraes em que h cooperao, e e co a ca isso se deve ao fato de que a cooperao entre os servidores impe uma carga maior de ca o trabalho, aumentando o nmero de conexes abertas simultaneamente em cada um deles u o (podemos observar na Tabela 5.3 que os servidores que cooperam tm uma atividade de e rede aproximadamente 40% mais intensa do que os servidores que no cooperam) levando a a um tempo maior na execuo da maioria das operaes. Para as requisies que resulca co co tam em miss, no entanto, esse aumento compensado pelo fato de grande parte dessas e requisies passarem a ser resolvidas consultando um outro servidor cache (em lugar de co recorrer ao servidor HTTP que possui o objeto), resultando em um tempo menor de servio c para a maioria dessas conexes. o
5.4.2
Multiprocessamento
Ao compararmos os dados de tempo de servio das conguraes que utilizam multic co processamento com os dados das conguraes que utilizam mquinas separadas para cada co a servidor (comparando dual-no-sibling com double-no-sibling e dual com double) podemos ver que a utilizao de multiprocessamento causa um aumento no tempo mdio ca e de resposta dos servidores, apesar de as taxas de acerto permanecerem as mesmas. Como era esperado, esse menor desempenho dos servidores que utilizam multiprocessamento e devido ` serializao de operaes (principalmente execuo de trechos do kernel que no a ca co ca a podem ser paralelizados)[3]. Analisando a Tabela 5.3 podemos ver que as conguraes co multiprocessadas possuem atividade de disco e de rede ligeiramente menor que as conguraes sem multiprocessamento, indicando a serializaao das operaes de entrada e co c co sa de dados e comunicao como a causa do desempenho pior. da ca
31
5.4.3
Conectividade
Comparando os dados de tempo de servio da congurao que utiliza apenas uma c ca interface de rede da mquina multiprocessada (fake-dual) com os da congurao equia ca valente que utiliza as duas interfaces (dual-no-sibling) podemos ver que a utilizao de ca uma interface extra no proporcionou ganho de desempenho sob essa carga de trabalho. a Entretanto, quando comparamos estas conguraes trabalhando em situaes de comuco co nicao mais intensa (com a mesma carga de trabalho sem simular o atraso nos servidores ca Web), a congurao fake-dual apresentou um desempenho inferior ao da congurao ca ca dual-no-sibling (o tempo mdio de resposta na congurao fake-dual foi aproximadae ca mente 10% maior), mostrando que, mesmo que estejamos executando mais de um servidor na mesma mquina, o uso de mais de uma interface de rede traz benef a cios apenas quando a quantidade de comunicao feita pelo servidor aproxima-se da capacidade mxima da ca a interface.
5.4.4
Compartilhamento
Comparando os dados da congurao que utiliza compartilhamento de memria (shm) ca o com os dados das conguraes que no o fazem, podemos ver que o tempo mdio de co a e resposta desta congurao o mais baixo de todos e o seu tempo de servio de hit ca e c e igual ao tempo de servio de hit da congurao double-no-sibling. Isso se deve ao fato c ca de que a colaborao atravs de memria compartilhada no impe um processamento de ca e o a o conexes extras ao servidor. Pelo mesmo motivo, o tempo de servio de miss tambm o c e e mais baixo. Na Tabela 5.2, vemos que a taxa de acerto na congurao shm mais baixa do que a ca e das outras conguraes em que h cooperao entre os servidores. Como mencionamos no co a ca Cap tulo 4 isso se deve ao fato de que, como o servidor que possui o objeto no participa a no processo de resoluo de um hit atravs da memria compartilhada, a sua lista de ca e o objetos mais recentemente utilizados no atualizada como no caso de uma cooperao a e ca normal, resultanto na eliminao de objetos que so muito acessados e, por isso, deveriam ca a permanecer no cache. Podemos ver na Tabela 5.3 que a congurao shm, quando comparada com a conca gurao double, tem um nmero menor de requisies atendidas por segundo, e menor ca u co atividade de disco e de rede (sendo a atividade de rede aproximadamente 40% mais alta na congurao double), apesar de o seu tempo de resposta a requisies ser menor. Isso ca co se deve ao fato de que quase 20% das requisies recebidas de clientes (hits resolvidos pelo co parceiro) so resolvidas na congurao double atravs da criao de uma conexo HTTP a ca e ca a com outro servidor cache gerando, desta forma, um trfego extra na rede. a Durante a execuo de experimentos com o SHMSquid, uma vez encontrado o arquivo ca contendo o objeto desejado no cache do parceiro, pudemos detectar a ocorrncia de alguns e erros que obrigavam o servidor cache a ir buscar o objeto no servidor HTTP original. Os
CAP TULO 5. ANALISE DE DESEMPENHO DO SHMSQUID tipos de erros ocorridos so os seguintes: a
32
remoo do arquivo - como o servidor parceiro no sabe que um determinado objeto ca a do seu cache est sendo acessado por outro servidor, ele pode vir a remover esse a objeto enquanto o atendimento est sendo feito. Essa remoo pode ocorrer entre a a ca localizao do objeto na tabela de StoreEntrys e a tentativa de abertura do arquivo ca ou durante a leitura do arquivo. objeto invlido no cache - o objeto encontrado no cache do parceiro pode no ter sido a a validado recentemente e por isso o servidor cache no pode utiliz-lo no atendimento a a da requisio por correr o risco de ele ter sido modicado desde a ultima vez em que ca foi recuperado do servidor original. Vericamos, no entanto, que estes erros ocorrem com uma freqncia muito baixa (aproue ximadamente 1 vez para cada 4.000 requisies), tendo ocorrido 91 remoes de arquivo co co (63 durante a leitura e 28 antes da abertura do arquivo) e 13 acessos a objetos invlidos a durante a execuo de 400.000 requisies (5 execues completas do experimento). ca co co
5.5
Discusso a
Como esperado, constatamos que a cooperao entre servidores traz um ganho signica cativo na taxa de acertos e no tempo mdio de resposta. Por outro lado, pudemos observar e um aumento no tempo de servio para os hits (que so as requisies de menor tempo de c a co atendimento), o que sugere que um aumento no nmero de servidores cooperantes pode u levar a uma degradao do sistema como um todo. ca Observamos que, apesar de uma mquina multiprocessada oferecer um meio de comua nicao mais rpido entre os processos servidores, as vantagens que poderiam surgir da ca a utilizao deste meio de comunicao mais rpido so superadas pelas desvantagens geraca ca a a das pelo compartilhamento de recursos que no podem ser usados em paralelo, resultando a em uma pequena perda de desempenho. Pudemos perceber que a utilizao de mais de uma interface de rede proporciona um ca ganho de desempenho em uma congurao multiprocessada. Este, no entanto, s pode ser ca o observado quando os servidores esto sujeitos a uma carga de comunicao muito intensa. a ca Finalmente, vericamos que a nova estratgia proposta proporciona um tempo mdio e e de resposta melhor que o das outras conguraes sem que haja perda de ecincia no co e tratamento de hits (como acontece na cooperao normal entre servidores cache). Vimos ca que esse melhor desempenho devido ao fato de um servidor no interferir no funcionae a mento do outro. Esta estratgia, no entanto, teve uma taxa de acerto mais baixa que e as outras conguraes onde havia cooperao entre os servidores porque o servidor que co ca possui um objeto que recuperado em um hit atravs de memria compartilhada no tem e e o a a sua lista de objetos acessados mais recentemente atualizada, resultando na retirada de objetos populares do cache.
33
Cap tulo 6 Concluses e trabalhos futuros o

A taxa de crescimento da utilizao da World Wide Web tem sido muito grande nos ca ultimos anos, provocando um grande aumento no trfego de dados na Internet. Embora a o uso de servidores cache WWW tenha ajudado a reduzir esse trfego de dados, as esa tratgias de cooperao entre servidores cache utilizadas atualmente podem resultar em e ca uma degradao no seu desempenho, no sendo, portanto, escalveis o suciente para ca a a acompanhar o crescimento atual da WWW. Neste trabalho, apresentamos uma nova estratgia de cooperao (uso de memria come ca o partilhada) entre servidores cache projetada com o objetivo de permitir que os servidores cache de um grupo cooperem entre si sem que haja uma degradao no seu desempenho. ca Pudemos vericar que a nova estratgia apresentada permite que um servidor se utilize e de dados existentes no cache do seu parceiro sem interferir no desempenho deste ultimo, alcanando, dessa forma, um desempenho melhor que o conseguido atravs de outros meios c e de cooperao e mostrando ser uma boa opo na implementao de servidores cache ca ca ca escalveis. a Apesar de o uso de memria compartilhada ter proporcionado menores tempos de o resposta aos clientes, pudemos observar que a taxa de acerto conseguida no foi to boa a a quanto a que se consegue atravs das formas tradicionais de cooperao. Essa diferena e ca c observada devida ao fato de as listas de objetos utilizados mais recentemente, usadas e pelo servidor quando precisa decidir quais objetos retirar do seu cache, no so atualizadas a a quando um servidor acessa o cache do seu parceiro atravs de memria compartilhada, e o provocando uma distoro na pol ca tica de reposio de objetos do cache. ca Este problema de atualizao das listas de utilizao de objetos pode ser resolvido ca ca atravs da utilizao de mecanismos de sincronizao que permitam que um servidor ine ca ca forme ao seu parceiro quando zer uso dos dados do seu cache. Implementando estes mecanismos de sincronizao, esperamos obter taxas de acerto semelhantes `s obtidas atravs ca a e dos meios normais de cooperao sem que haja uma queda no desempenho do servidor. ca Apesar dos ganhos obtidos com a utilizao do SHMSquid, sabemos que uma das granca des barreiras para o desenvolvimento de servidores escalveis para a WWW o suporte a e
CAP TULO 6. CONCLUSOES E TRABALHOS FUTUROS
34
inadequado dos sistemas operacionais[3]. Por isso, deve-se investigar novos mecanismos para dar suporte ` execuo de servidores Web, no s criando novas interfaces de proa ca a o gramao que evitem os problemas j evidenciados, como tambm melhorando o suporte ca a e a multiprocessamento em sistemas correntes.
35
Bibliograa
[1] Apache. http://www.apache.org/. [2] M. J. Bach. The Design of the UNIX operating system. Prentice-Hall Software Series. P T R Prentice-Hall, Inc., 1986. [3] G. Banga, P. Druschel, and J. Mogul. Better operating system features for faster network servers. In Proceedings of the Workshop on Internet Server Performance, Madison, WI, June 1998. [4] T. Berners-Lee, R. Cailliau, A. Luotonen, H. Nielsen, and A. Secret. The World Wide Web. In Communications of the ACM, volume 37, August 1994. [5] T. Berners-Lee, R. Fielding, and H. Frystyk. Hypertext transfer protocol http/1.0. RFC 1945, May 1996. [6] R. Bianchini, L. Kontothanassis, R. Pinto, M. De Maria, M. Abud, and C. Amorim. Hiding communication latency and coherence overhead in software DSMs. In Proceedings of the 7th International Conference on Architectural Support for Programming Languages and Operating Systems, Boston,MA, October 1996. [7] N. J. Boden, D. Cohen, R. E. Felderman, A. E. Kulawik, C. L. Seitz, J. N. Seizovic, and W.-K. Su. Myrinet: A gigabit per second local area network. IEEE-Micro, 1995. [8] Cisco Systems. Cisco Cache Engine. http://www.cisco.com/univercd/cc/td/doc/ product/webscale/webcache/. [9] P. B. Danzig, R. S. Hall, and M. F. Shwartz. A Case for Caching File Objects Inside Internetworks. Technical Report CU-CS-642-93, University of Colorado at Boulder, March 1993. ftp://ftp.cs.colorado.edu/pub/cs/techreports /shwartz/FTP.CachingPS/Paper.ps.Z. [10] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, and T. Berners-Lee. Hypertext transfer protocol http/1.1. RFC 2068, January 1997. [11] E. Fonseca. Hierarquia de Servidores Proxy Cache WWW: Instrumentao e Anlise ca a de Desempenho. Masters thesis, Universidade Ferderal de Minas Gerais, 1999.
BIBLIOGRAFIA
36
[12] S. Gade, M. Rabinovich, and J. Chase. Reduce, Reuse, Recycle: An Approach to Building Large Internet Caches. http://www.cs.duke.edu/ari/cisi/crisp-recycle/. [13] W. Meira Jr., E. L. da Silva Fonseca, V. A. F. Almeida, and C. D. Murta. Performance Analysis of WWW Cache Proxy Hierarquies. Journal of the Brazilian Computer Society, 5(2), Novembro 1998. [14] W. Meira Jr., E. Fonseca, V. Almeida, and C. Murta. Analyzing performance of cache server hierarchies. In Proceedings of SCCC98, Antofagasta, Chile, November 1998. [15] W. Meira Jr., E. Fonseca, V. Almeida, and C. Murta. Evaluating and conguring WWW caches. In 3rd International WWW Caching Workshop, Manchester, UK, June 1998. [16] W. Meira Jr., T. J. LeBlanc, N. Hardavellas, and C. Amorim. Understanding the performance of DSM applications. In Proceedings of the Workshop on Communication and Architectural Support for Network-based Computing (CANPC), volume 1199 of Lecture Notes in Computer Science, pages 98211, San Antonio, TX, February 1997. IEEE, Springer-Verlag. [17] Microsoft Corporation. Cache Array Routing Protocol and Microsoft Proxy Server 2.0, 1998. http://www.microsoft.com/proxy/documents/CarpWP.exe. [18] J. Mogul. Speedier Squid: A case study of an Internet Server Performance Problem. ;login: The USENIX Association Magezine, February 1999. [19] National Laboratory for Applied Network Research. Squid Internet Object Cache. http://squid.nlanr.net/Squid/. [20] Netscape communications. http://www.netscape.com/company/. [21] G. Paixo, W. Meira Jr., and F. Sanches. Servidores cache www em arquiteturas a multiprocessadas. In Anais do XI SBAC-PAD, pages 319323, Natal,RN, Setembro 1999. Sociedade Brasileira de Computao. ca [22] G. Paixo, W. Meira Jr., and F. Sanches. Shmsquid: a scalable www cache server. In a Proceedings of the International Conference of the Chilean Computer Science Society, pages 187194, Talca, Chile, November 1999. Chilean Computer Science Society, IEEE Computer Science Press. [23] R. Rivest. The MD5 Message-Digest Algorithm. Network Working Group RFC 1321, April 1992. http://ds.internic.net/rfc/rfc1321.txt. [24] K. W. Ross. Distribution of Stored Information in the Web. http://www.eurecom.fr/ ~ross/CacheTutorial/DistTutorial.html, 1998.
BIBLIOGRAFIA
37
[25] A. Rousskov. On Performance of Caching Proxies. http://www.cs.ndsu.nodak.edu/ ~rousskov/research/cache/squid/profiling/papers/, 1997. [26] A. Rousskov and D. Wessels. Cache digests. http://ircache.nlanr.net/Papers/ cache-digests.ps.gz, April 1998. [27] W. R. Stevens. UNIX Network Programming. Prentice Hall, 1990. [28] D. Wessels and K. Clay. Internet Cache Protocol(ICP), version 2. Network Working Group RFC 2186, September 1997.

Escalabilidade em Servidores Cache WWW

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Escalabilidade em Servidores Cache WWW

Enviado por

Direitos autorais:

Formatos disponíveis

Goedson Teixeira Paixo a

Escalabilidade em servidores cache WWW

Cap tulo 1 Introduo ca

CAP TULO 1. INTRODUCAO

CAP TULO 1. INTRODUCAO

Cap tulo 2 Trabalhos relacionados

CAP TULO 2. TRABALHOS RELACIONADOS

Cliente Servidor 1 CONECTA 2 URL

Figura 2.1: Transao HTTP. ca

Cooperao entre servidores cache ca

CAP TULO 2. TRABALHOS RELACIONADOS

Proxy 1 CONECTA 2 URL 6 OBJETO

3 CONECTA 4 URL 5 OBJETO

Figura 2.2: Transao HTTP com proxy. ca

CAP TULO 2. TRABALHOS RELACIONADOS

Figura 2.3: Transao HTTP com consulta ICP. ca

CAP TULO 2. TRABALHOS RELACIONADOS

CAP TULO 2. TRABALHOS RELACIONADOS

Figura 2.4: Falso acerto em um Cache Digest.

CAP TULO 2. TRABALHOS RELACIONADOS

CAP TULO 2. TRABALHOS RELACIONADOS

Limitaes dos mtodos de cooperao existentes co e ca

Cap tulo 3 O servidor cache Squid

Viso geral do Squid a

CAP TULO 3. O SERVIDOR CACHE SQUID

Estruturas de dados do Squid

CAP TULO 3. O SERVIDOR CACHE SQUID

CAP TULO 3. O SERVIDOR CACHE SQUID

Recebimento e atendimento de uma conexo a

Recuperao de um objeto existente no cache ca

CAP TULO 3. O SERVIDOR CACHE SQUID

Recuperao de objeto em servidor parceiro ca

Cap tulo 4 SHMSquid

Cooperao entre caches usando memria comca o partilhada

CAP TULO 4. SHMSQUID

Comunicao atravs de memria compartilhada ca e o

CAP TULO 4. SHMSQUID

CAP TULO 4. SHMSQUID

CAP TULO 4. SHMSQUID

Implementao da cooperao usando memria ca ca o compartilhada no Squid

CAP TULO 4. SHMSQUID

Congurao e compartilhamento dos dados ca

Recuperao de um objeto em cache de outro servidor ca

CAP TULO 4. SHMSQUID

Cap tulo 5 Anlise de desempenho do a SHMSquid

CAP TULO 5. ANALISE DE DESEMPENHO DO SHMSQUID

Critrios de anlise de desempenho e a

CAP TULO 5. ANALISE DE DESEMPENHO DO SHMSQUID

CAP TULO 5. ANALISE DE DESEMPENHO DO SHMSQUID

double 2 interfaces de rede

Figura 5.1: Relao entre os critrios de anlise e as conguraes utilizadas. ca e a co

ces rfa e nte red 2 i de

CAP TULO 5. ANALISE DE DESEMPENHO DO SHMSQUID terface de rede.

CAP TULO 5. ANALISE DE DESEMPENHO DO SHMSQUID

Anlise dos resultados a

Congurao ca double-no-sibling double dual-no-sibling dual fake-dual shm

Total 0.3097 0.4567 0.3127 0.4662 0.3150 0.3842

Tabela 5.2: Taxa de acerto no cache.

Disco 22.8480 25.9467 22.6536 24.8328 22.6238 25.4615

Rede 53.2459 74.0923 52.1093 70.0355 51.8748 55.6723

Tabela 5.3: Taxa de servio do servidor (operaes por segundo). c co

CAP TULO 5. ANALISE DE DESEMPENHO DO SHMSQUID

Multipro cessamento double Cooperao dual