Você está na página 1de 30

Análise do Web Cache no

Gigabit G Rede de Pesquisa-Win

Resumo do Projeto
O enorme crescimento esperado no Mundial de tráfego Wide Web nos
próximos anos
exige um esforço enorme para garantir a escalabilidade ea aceitação do
usuário. cache de Web é uma ferramenta comum para reduzir o tráfego de
rede e garantindo resposta razoável
tempos. Para proporcionar melhores soluções de cache da Web, os
operadores de rede precisam indepth compreensão de como o desempenho
de um proxy cache é influenciado por
cargas de trabalho de características e tecnologia de rede. Isto requer uma
análise detalhada
e avaliação de diferentes organizações de uma web proxy caches
autônomo, bem
como a avaliação das diferentes formas de cooperação entre proxies de
cache
distribuídos por uma rede de área ampla.

Na primeira parte deste relatório, nós apresentamos um estudo do
desempenho global da
organizações diferentes de um web proxy cache autônomo sob as atuais e
futuras
características de carga de trabalho. Como característica inovadora do
nosso trabalho, caracterizar pedido riachos vistos em um cache de proxy da
Web em HTML, imagens e documentos multimédia visto em um proxy
cache. Com base nesta caracterização de carga de trabalho, obtemos
previsões de volume de trabalho institucional caches de proxy da Web e
proxies residentes num backbone da rede.

O objetivo do nosso estudo constitui a entender como essas lidar com
diferentes regimes de substituição de classes de documentos web. Este
entendimento é importante para o projeto efetivo de substituição de cache
da Web regimes em alterar as características de carga de trabalho. Apesar
de largura de banda para redes de backbone IP anterior implantado pelos
Internet Service Provedores normalmente tem sido limitada a 34 Mbps,
atuais e futuras redes IP fornecer largura de banda que varia de 155 Mbps
para 2,4 Gbps. Assim, é importante
investigar o impacto das tecnologias emergentes de rede sobre o

desempenho de
Web caching protocolos de cooperação. Na segunda parte deste projecto,
apresentamos
um estudo de desempenho global de quatro protocolos de cooperação
cache web.

O objetivo deste estudo de desempenho reside na compreensão do
comportamento e da limitação fatores dos protocolos considerados para
cache de Web sob medida cooperativa
condições de tráfego. Com base nesse entendimento, damos
recomendações para Internet Service Providers, os clientes da Web e
Application Service Providers.

Palavras-chave:
concepção orientada para o desempenho e estudos de avaliação de caches
para Web, Web cache
regimes de reposição, suporte ao protocolo de cooperação para o cache de
Web, a carga horária
caracterização e previsão, simulação trace-driven.

Conteúdo
1 Introdução ................................................ .................................................. ..................
5
Parte 1: Avaliando Hardware e Software Soluções Web Proxy Cache ...................... 7
2 Visão
geral ................................................ .................................................. ...................... 7
3 Produtos do Web
Cache .............................................. .................................................. .... 9
3,1 Hardware Solutions ............................................... .................................................. 9
Soluções de Software ............................................... 3,2 .................................................
12
4 Web Cache substituição Esquemas ............................................. ..................................
16
5 Caracterização de carga de trabalho de Traços e Previsão de Carga de
Trabalho ..................................... 20
5,1 Caracterização de Cargas de Trabalho Web Proxy
atual ........................................... .. 20
5,2 Previsão de Cargas de Trabalho Web Proxy
Futuro ........................................... ................. 23
5,3 Derivando as previsões de carga de trabalho do DEC e Traços DFN ......................
26

6 experimentos de
desempenho ............................................... .............................................. 27
6,1 Investigação da adaptabilidade dos Dual Greedy *......................................... ..... 27
6,2 de desempenho para cargas de trabalho
atual ............................................. ........................ 29
6,3 Desempenho para futuras cargas de
trabalho ............................................. ......................... 31
6,4 particionados Web Proxy Cache ............................................. ................................ 36
Parte 2: Avaliação da Web Cache Cooperativa para a Rede de Tecnologias
Emergentes ...... 38
7 Visão
geral ................................................ .................................................. ..................... 38
8 Protocolos para Web Cache Cooperativa ............................................ ..........................
40
9 Ambiente de Simulação ............................................... ................................................
45
9,1 Modelo de Rede ............................................... .................................................. 45 ....
9.2 Características das cargas de trabalho
Considerado ............................................ ........... 50
10 Estudo Comparativo de Desempenho de Protocolos
Considerado .......................................... 52
10,1 Medidas de Desempenho ............................................... ...........................................
52
10,2 consumo de banda e eficiência Protocolo ............................................ ... 53
11 Latência recuperação de
documento .............................................. .......................................... 58
11,1 Utilização Cache ............................................... .................................................. .61
12 Geral As conclusões extraídas dos Estudos da
Performance ........................................... ... 67
13 Recomendações para o DFN-
Verein ............................................ .................................. 69
Referências ................................................. .................................................. ....................
.....

1 Introdução

Aplicações da World Wide Web chegar navegando forma de informações e catálogos
on-line sobre soluções para negócios electrónicos, teleducaçâo e-learning até vídeo
conferências. A continuação crescimento exponencial do volume de tráfego e demanda
crescente por acesso a recursos web formulário em qualquer lugar a qualquer hora
coloca novos desafios aos operadores de rede, por exemplo, serviços de Internet
Prestadores e instituições acadêmicas. cache de Web é uma ferramenta comum para a
redução da rede tráfego e garantir os tempos de resposta razoável. proxy caches
Autônomo Web reduzir o tráfego entre a rede de área local e largura. Internet Service

Como entrada de simulação. aumento da disponibilidade de banda na rede backbone de uma nacionais Internet Service Provider. por exemplo. o ICP. Um estudo do desempenho global de amplamente utilizada. Assim.Providers amplamente utilizados agrupamentos hierárquicos de cache de proxy web. o comportamento de cooperar web caches tem que ser investigado com relação à mudança das características do subalterno infra-estrutura de rede. Como característica inovadora do nosso trabalho. por exemplo. Ele dá uma visão geral sobre os esquemas de substituição e protocolos suportados pelo comercial soluções de cache. G-WIN. empregando aparelhos cache desenvolvidos por fornecedores de hardware diferentes. Esse entendimento é importante para o projeto eficaz de regimes de substituição Web cache em alterar as características de carga de trabalho. Além disso. sem mesmo sabendo da sua existência. Fornecendo soluções de cache ideal requer conhecimento profundo de cache tecnologias. redes atuais e futuras IP fornecer largura de banda que varia de 155 Mbps para 2. Baseado sobre esta caracterização de carga de trabalho. Os resultados apresentados são calculadas com base rastreamento de simulação baseada. por exemplo o Protocolo de Internet Cache. Este relatório é composto de duas partes. Ambos os estudos devem ser realizados por meio de análise detalhada do características do trabalho visto por proxies de cache em locais diferentes. ou seja. Parte 1 centra-se na organização autônoma da web proxy caches. Estes protocolos tornam mais fácil construir heterogênea soluções de cache. institucional ou proxies backbone. Assim. Vários protocolos de cooperação foram desenvolvidos. é importante investigar o impacto das tecnologias emergentes de rede sobre o desempenho . Parte 2 centra-se na cooperação de cache de proxy da Web localizados na espinha dorsal de uma prestadores de serviços nacionais de Internet. bem como na espinha dorsal da pesquisa alemã rede G-WIN. técnicas transparentes permitem aos utilizadores beneficiarem forma as vantagens de cache da Web.4 Gbps. usamos os traços gravados por proxy caches localizadas em universidades e instituições comerciais. Estudos de sensibilidade ajuda a entender o comportamento de protocolos e algoritmos e suporta projetos de longo prazo soluções de cache escaláveis. as características de carga de trabalho bem como a sensibilidade a mudanças na tecnologia e usuário comportamento. estudos detalhados devem ser utilizados para explicar e otimizar o desempenho do proxy caches autônomo web. bem como regime de substituição proposto recentemente é fornecido. O objetivo do nosso estudo constitui a compreender como estes regimes de substituição lidar com diferentes classes de documentos web. Enquanto a banda para o backbone IP anterior redes implantadas pela Internet Service Providers normalmente tem sido limitada a 34 Mbps. caracterizar pedido fluxos atendidos em um Web proxy cache para o HTML. tiramos as previsões de carga de trabalho para o proxy da Web institucional caches e proxies residente em uma rede backbone. imagens e documentos multimédia visto em um proxy cache.

estudos recentes (ver. Consideramos que o cache da Internet protocolo ICP. todos os produtos comerciais disponíveis no mercado apenas confiar na regime de substituição menos utilizado recentemente. Tráfico de Inktomie Server. Somente o Squid como software de código aberto livremente disponível para instituições acadêmicas pode ser configurado para utilizar outros substituição cache regimes que têm sido propostos recentemente. a Cisco CacheEngine. documentos multimédia) é muito maior que o crescimento previsto da memória tamanhos para o futuro da Web caches [JB00]. o protocolo de matriz de cache de roteamento. Com base nesta entendimento. são menos recentemente usada (LRU). nós apresentamos uma abordagem global estudo do desempenho de quatro protocolos de cooperação cache web. WCCP. A otimização dos sistemas de troca de cache é importante porque a taxa de crescimento Conteúdo da Web (ou seja. os clientes da Web. O desempenho destes protocolos é avaliada usando tracedriven simulação com o tráfego medido a partir da Web e DFN NLANR. Além disso. menos frequentemente usada com . o CARP. Eles compararam o desempenho desta nova proposta de regime de substituição com esquemas tradicionais. dar recomendações para o Internet Service Providers. o NetCache Network Appliance.de protocolos de cooperação cache web. Eles mostraram que Greedy tamanho duplo é on-line ótima em relação a esta função de custo. por exemplo [BCF 99]) têm mostrado taxa de acerto e taxa de acerto byte crescer de forma log-como em função do tamanho da Web cache. e Application Service Providers. eo cache de Web protocolo de coordenação. DynaCache InforLibria. da Novell System Cache Internet. Estes produtos diferem no tamanho do cache. armazenamento em disco e throughput. Parte 1: Avaliando Hardware e Software Web Proxy Cache Soluções 2 Visão geral A continuidade do crescimento da World Wide Web eo surgimento de novos meios de comunicação multi aplicações requer a utilização de proxy caches para reduzir a latência do usuário final e de rede tráfego. Cache Digest. No entanto. O objetivo do presente estudo de desempenho consiste em compreender o comportamento e fatores limitantes da considerada protocolos de cooperação para o cache de Web em condições de tráfego medido. Neste relatório. Cao e Irani introduziu o regime de substituição Web Cache Size Greedy Dual [CI97] que leva em conta as dimensões do documento e um usuário função de custo definida. soluções de cache Comercial Web incluem Server Cache Flow do acelerador. Jin e Bestavros introduzido Web cache regime de substituição * Greedy dupla como uma melhoria para Greedy Dual Tamanho [JB00].

Nesta parte do o relatório. Esse entendimento é importante para o projeto eficaz de regimes de substituição Web cache em alterar as características de carga de trabalho. Mahanti e Williamson forneceu uma caracterização da carga de trabalho detalhado para proxy caches Web [MW99]. e Vernon desenvolvidos modelos analíticos para a determinação do teor ótimo proxy cache de apoio contínuo. A primeira parte deste projecto centra-se sobre a avaliação dos regimes de substituição de hardware e soluções de software de soluções web proxy cache [CMT01]. A segunda parte centra-se na avaliação dos protocolos de cooperação cache da Web (ou seja. Ansioso. Eles também observaram uma extrema não uniformidade na popularidade de pedidos de visto em Web proxy cache. Eles observaram que. o Cache Array Routing Protocol. Arlitt. e Size Dual Greedy [AFJ00]. Ansioso. nós apresentamos os estudos da performance global de LRU tradicionais como substituto esquemas. o ICP. e digere Cache). e com o regime de Greedy tamanho conhecimento Dual Size [JB00]. Greedy-Dual-Size e * Greedy-Dual sob as atuais e futuras características de carga de trabalho. carpa. A localidade temporal nas cargas de trabalho da Web têm sido objecto de dois artigos recentes. um documento de tamanho e popularidade documento) possuem alta variabilidade. A caracterização do trabalho apresentado na seção 5 indica que. em futuras cargas de trabalho . Uma caracterização detalhada de cargas de trabalho anterior da Web foi dada pelo Arlitt e Williamson [AW97]. em 1998 documentos HTML e imagens representam mais de 95% de todos os pedidos. o cache de internet Protocolo. Mahanti e Williamson investigou o impacto de localização temporal proxy cache desempenho [MEW00]. Todos esses precedentes estudos de desempenho de considerar um fluxo único pedido para analisar o desempenho de regimes de substituição. streaming media [EFV00]. Jin e Bestavros investigados localidade temporal no pedido de cache Web córregos [JB99]. e Jin forneceu uma Estudo comparativo do desempenho de seis sistemas de substituição Web cache entre os quais estão LRU. Um artigo recente levantamento sobre as características de desempenho da Web fornecidas pelo Crovella [Cro00] explica que muitas das características das cargas de trabalho na Web (Por exemplo. Friedrich. DA LFU. O objetivo do nosso estudo constitui a compreender como estes regimes de substituição lidar com diferentes classes de documentos web.Envelhecimento Dinâmico (LFU-DA). Ferris. em carga de trabalho várias medidas. bem como os regimes de nova proposta LFU-DA.

Esta parte do relatório está organizado da seguinte forma. Os regimes de substituição de empregado nestas cache da Web soluções são descritos na secção 4.porcentagem de pedidos de documentos multimédia será substancialmente maior do que no atual solicitação da Web riachos vistos em um proxy cache. O simulador para a substituição de cache da Web estratégias tem sido implementado usando a biblioteca de simulação CSIM [Sch95]. Além disso. usando regressão linear obtemos as previsões de carga de trabalho institucional. tanto para cache de proxy da Web e para caches proxy localizados em redes de backbone. A Seção 3 introduz cache de Web comerciais produtos atualmente no mercado. Esta repartição das taxas de sucesso e as taxas de acerto byte por classe de documento mostra que a taxa de acerto global é principalmente influenciada pela taxa de acerto nas imagens. apresentamos duas cargas de trabalho previsões. em uma avaliação global considerando tanto as taxas de sucesso e byte taxas de sucesso do software Squid solução de cache de Web com o regime de substituição * GD (1) deve ser a escolha para cargas de trabalho atual enquanto Squid com o regime de substituição GDS (1) deve ser a escolha para cargas de trabalho futuro. Com base nessas tendências. Além disso. e documentos multimédia.1 Hardware Solutions . 1998 e 2000. O desempenho resultados são obtidos por simulação trace-driven. tendo em conta a popularidade crescente de aplicações multimédia. Em Seções 6. apresentamos as curvas de desempenho para a substituição cache considerados Web regimes de derivados de rastreamento de dados e previsões de carga de trabalho. As curvas apresentadas indicam que. Além disso. Nós apresentamos curvas que representam a taxa de acerto e taxa de acerto byte discriminados para a imagem do HTML. A Secção 5 apresenta uma caracterização da as cargas provenientes de traços considerados. observou- se que a popularidade do alguns documentos multi mídia aumenta rapidamente. Estas tendências são derivadas de cinco traços medidos em 1996. A taxa de acerto total de bytes é influenciado principalmente pelo byte taxa de acertos em documentos multimédia. o tempo entre dois sucessivos referências ao mesmo documento Web denotada como uma diminuição de correlação temporal. 3 Produtos do Web Cache 3.

Rede apoio à gestão é fornecida através de compatibilidade com o Simple Network Management Protocol (SNMP). que pode ser colocado nas redes existentes. aceleradores Cache Flow apoiar o Hypertext Transfer Protocol (HTTP) 1. Eles reduzem tempos de resposta e os requisitos de largura de banda. Cache Flow linha de produtos de aceleradores difere em tamanho do cache.Cache Flow Cache Flow [CF01] oferece duas linhas de produtos Web cache chamado Client Aceleradores e Aceleradores Server. rendimento e preço. Eles são colocados na frente de um servidor da Web para serviço de solicitação de documentos localizados em o servidor web. O WCCP protocolo é fornecido com roteadores Cisco e oferece caching Web transparente. A CA família 600 é projetado para pequenas Internet Service Providers (ISPs) e das empresas. o Network News Transfer Protocol (NNTP) e sistema de nome de domínio (DNS) de cache.0 e v2. movendo Web e streaming de conteúdo para mais perto o usuário e acelerar os pedidos do cliente. CacheOS é um sistema operacional projetado especialmente para oferecer escalabilidade e confiabilidade para cache de aplicações web. Aceleradores Server são substitutos também conhecida como cache de proxy reverso. ISPs e outras organizações em todo o mundo para gerenciar e controlar o tráfego da Web crescimento. Cliente Aceleradores (CA) são caches da Web.0 para o cache Web cooperativa. bem como o cache de Web Coordenação Protocol (WCCP) v1. O CA-600 da série de aceleradores de cliente são utilizados por empresas. Assim. Todos os aceleradores de Cache Flow pode ser atualizado por software addons para habilitar a funcionalidade de firewall e filtragem de conteúdo. Aceleradores Server estão fora do escopo deste relatório. eles se alcançar a escalabilidade das redes existentes. Sua funcionalidade acrescenta disponibilidade para popular os lados da Web recebe uma carga de formar o servidor de origem. O acelerador cliente Cache Flow . O CA 600 A família também suporta o Internet Cache Protocol (ICP). Os produtos Cache Flow atualmente disponíveis não oferecem suporte ao protocolo para aplicações de streaming de áudio com qualidade digital e transmissão de vídeo através da Internet. Todos os aceleradores de Cache Flow são executados pelo CacheOS patente pendente do sistema operacional. enquanto CA 3000 e 5000 famílias são projetados para grandes provedores que visam economia substancial largura de banda na rede de área ampla.1.0 e 1. o File Transfer Protocol (FTP). enquanto acelera a entrega de conteúdos para os usuários.

Segundo a Cisco.é implantado entre os usuários ea Internet ou em locais remotos.0. Apoio ICP fornece compatibilidade para ambientes existentes para o cache Web cooperativa. Em 1997. Os dados técnicos de aceleradores cliente Cache Flow está resumida na A Tabela 1. WCCP é um protocolo de cache do roteador que localiza tráfego de rede e prevê a distribuição de carga de rede inteligente em toda a rede múltiplos caches para o desempenho de download maximizada e disponibilidade de conteúdo. NNTP.0 está disponível e amplamente utilizado. De acordo com o seu fornecedor. o protocolo WCCP v2.1. Cache Flow 3000 capacidade da rede de escala. O Cache Flow 3000 é um aparelho de alto desempenho de cache Internet. soluções de cache a Cisco podem ser custo-efetivo em implantar uma base larga escala e obter os benefícios do cache em toda a sua rede inteira. e cache DNS. Cisco solução da Cisco inclui caching Web Cache do motor da série 500 [CS01]. resultando em relativamente aumento dos custos de propriedade e torná-las menos desejáveis para a implantação em larga escala. Suporte de cargas do tráfego de entrada 10-45 Mbps. Tradicionais baseadas em proxy ou caches independentes não são intrinsecamente concebidos para serem rede integrada. motores cache Cisco são integradas na rede infra-estrutura.0 e 1. FTP. A Cisco Cache motor de 500 produtos da série acelerar a entrega de conteúdo. a Cisco foi pioneira na tecnologia da indústria de conteúdo do primeiro encaminhamento. com investimentos em infra-estrutura mínima. Desde a Primavera de 2000. Todos os produtos da Cisco suportam HTTP 1. Contrapondo-se ao cache de sistema operacional com base solução fornecida pela Cache Flow. O Cache Flow 5000 é o high-end produto de Cache Flow suporte de cargas do tráfego de entrada de até 135 Mbps com 126 GB de armazenamento em disco. o cache de Web Coordenação Protocol (WCCP) versão 1. e gere de forma inteligente solicitações por conteúdo. otimização de largura de banda de rede utilização e controle de acesso para o conteúdo. eles vão continuar a liderar as inovações e melhorias para este protocolo e outros conteúdos de . a Série 3000 é um mid-range Web solução de cache para os ISPs e empresas.

ISPs sem fio. Por automaticamente armazenar objetos comumente solicitada Web na ponta da rede local.5 Mbps. A tecnologia é DynaCache aplicados em Prestadores de Serviços ISPs e aplicativos (ASPs).7 Mbps. produtos DynaCache vem em configurações para atender às diversas redes e necessidades empresariais. Cache motor 590 é uma solução de cache de alta projetada para os prestadores de serviços e grandes empresas com o tráfego de entrada de até 44. Os dados técnicos da Cisco Cache Engine Os produtos da série está resumido na Tabela 1. InfoLibria A solução de cache Web oferecido pela InfoLibria compreende do DynaCache [Inf01] produtos.roteamento tecnologias. a Cisco fornece suporte de gerenciamento de rede pela compatibilidade com SNMP e Cisco produtos atualmente disponíveis não oferecem suporte ao protocolo para aplicações de streaming. Expansão de armazenamento está disponível através do Cisco Storage Array. O resultado é o aumento da rede confiabilidade. produtos Aos DynaCache são executados por um propósito especial sistema operacional projetado especialmente para oferecer escalabilidade e confiabilidade para o cache da Web aplicações. Motor da Cisco Cache 570 é uma solução de cache Web para POPs pequeno serviço de provedor e médias empresas com tráfego de entrada de até 22 Mbps. Como aceleradores Cache Flow InfoLibria. com conexão banda larga de rede de até 11 Mbps. desempenho mais rápido e menor latência do usuário final. Cisco Cache Motor 505 é um motor de cache de nível de entrada para pequenas filiais da empresa com entrada tráfego de até 1. Quanto aos produtos Cache Flow. Cache Cisco 550 é um motor de médio porte uma solução de cache Web para escritórios regionais. DynaCache permite o acesso de alta velocidade à Internet de conteúdos mais frescos minimizando a demanda por banda larga popular sites. e Serviço de Satélite Providers. . Cache produtos Cisco motor da série diferem na capacidade de armazenamento e processamento. DynaCache oferece caching carrier-grade e inteligente gerenciamento de conteúdo. De acordo com InfoLibria. DynaCache contém software para a funcionalidade de firewall e filtragem de conteúdo.

a linha de produtos oferece suporte a streaming NetCache aplicações. ISPs e ASPs.1. A solução constitui a entrada DynaCache 10. gerenciamento de rede apoio é prestado através de compatibilidade com SNMP. redes de distribuição de conteúdo. Para cache de Web de cooperação. tais como serviços de grande escala video-on-demand. Estes aparelhos podem ser usados em toda a rede. produtos Aos atualmente disponíveis não oferecem suporte ao protocolo de streaming aplicações como áudio digital e transmissão de vídeo através da Internet. NNTP. Contrapondo-se aos produtos apresentados acima. Sua capacidade máxima é de 34 Mbps. InfoLibria. com um armazenamento em disco rígido capacidade de 36 GB e uma taxa de transferência máxima de 12 Mbps. FTP. Seus discos rígidos oferecem até 144 GB de fazer cache de armazenamento. AOS DynaCache oferecer produtos da série com capacidade de armazenamento diferentes e throughput.DynaCache suporta os protocolos HTTP v1.0. os produtos são executados por NetCache um sistema operacional de propósito especial especialmente concebidos para oferecer escalabilidade e confiabilidade para Web caching de mídia e aplicações de streaming. Para Web caching cooperativo. NetCache também inclui suporte para as principais tecnologias de transmissão de mídia através de . a partir da sede central para pontos remotos de presença e de escritórios locais.0 e v1. e cache DNS.0 e v1.0. Quanto aos produtos Cache Flow e Cisco. Assim. AOS DynaCache.1. linha de produtos Aos é o DynaCache 40. InfoLibria. NetCache suporta os protocolos HTTP v1. DynaCache suporta ICP e WCCP v2. NetCache também pode entregar áudio e vídeo digital permitindo nextgeneration aplicações de rede. NNTP. FTP. Como aceleradores Cache Flow e InfoLibria. produtos NetCache resolver os problemas enfrentados pela entrega de conteúdo empresas. e cache DNS. Os dados técnicos do InfoLibria. Rede de apoio à gestão é fornecida através de compatibilidade com SNMP. AOS produtos DynaCache está resumida na Tabela 1. DynaCache suporta ICP e WCCP v2. O cache mais poderosos Web dispositivo de InfoLibria. Network Appliance O hardware da solução de cache Web oferecido pela Network Appliance [NA01] compreende o linhas de produto NetCache.

2 Soluções de Software Inktomi Inktomi [Inc01] oferece um software de solução de cache Web Server chamado Traffic. Traffic Server está disponível em três versões: Traffic Server Classe C para as transportadoras e Vendedor disco do produto em GB RAM em MB Throughput em Mbps Substituição Regime Cache Flow 600 36 768 10 LRU Cache Flow 3000 63 1024 45 LRU Cache Flow .compatibilidade com o Real Time Streaming Protocol (RTSP) e ao conteúdo da Internet Adaptation Protocol (ICAP). enquanto todos os produtos empregar Least Recently Used (LRU). NetCache C1100 Series são a entrada de produtos NetCache projetado para escritórios remotos ou filiais da empresa. As soluções C6100 suporte 155 Mbps e mais para ambientes de HTTP e 622 Mbps e mais para aplicações de streaming. A Tabela 1 resume os dados técnicos das soluções de hardware para armazenamento em cache web. hardware redundante. As opções de expansão tornam o NetCache série C700 soluções ideais para ambientes de rápido crescimento. Nota que os produtos comerciais que diferem em tamanho de armazenamento em disco e memória RAM. A série C1100 suporta múltiplas conexões HTTP para ambientes com 1. otimiza uso de banda e fornece uma fundação para a prestação de novos serviços na borda do rede. Inktomi Traffic Server é uma plataforma robusta rede de cache que melhora a qualidade do serviço. 3. Confiabilidade e disponibilidade de dados de missão crítica é assegurada com recursos como RAID.5 Mbps largura de banda e conexões com 155 Mbps para aplicações de streaming. desempenho e Os recursos de confiabilidade. como regime de substituição de documentos web. Grande conteúdo bibliotecas com até 2 TB de armazenamento podem ser armazenados e acessados de forma confiável. O mid-range NetCache produtos da Série C700 apoio a uma vasta gama de capacidade. e drives hot-swap. NetCache C700 e C6100 NetCache. O highend produtos NetCache C6100 Series oferecem alto desempenho e confiabilidade para os dados centro e outros locais de banda larga. bem como pequenas e médias empresas. A família NetCache inclui três linhas de produtos distintas: NetCache C1100.

Técnicas de resumo de soluções de cache de hardware prestadores de serviços. ICP é utilizado para a coordenação de cache e oferece compatibilidade com rede existente caches. os produtos Traffic Server suporta os protocolos ICP e WCCP v2. SGI.0 e v1. a Traffic Server permite facilmente a integração de serviços como on-demand streaming media. HP. Os dois primeiros produtos são soluções de software de verdade. a Traffic Server Mecanismo de cache soluções aparelho.024 34 DC NetCache C1100 9 256 1. De acordo com Inktomie. Rede de apoio à gestão é fornecido através da compatibilidade com SNMP.7 LRU DynaCache LRU 10 36 512 12 DC DynaCache LRU 20 40 512 21 DC DynaCache LRU 30 72 512 27 DC InfoLibria DynaCache LRU 40 144 1. Traffic Server E-Class para redes corporativas.Cache Flow 5000 126 N / A 135 LRU Cache Engine 505 18 128 1. Traffic Server é a única rede que o cache também funciona como uma plataforma para prestação de serviços na borda da rede. Para cache de Web de cooperação. e cache DNS. . Como os produtos NetCache da Network Appliance.5 LRU Cache Engine 550 18 256 11 LRU Cache Engine 570 144 384 22 LRU Cisco Sistemas Cache Engine 590 144 384 44. Como uma solução de software. FTP. Estes OEMs associados incluem Inktomie Sun. Como todas as soluções de hardware cache introduzida na seção anterior. o tráfego Inktomi Server suporta os protocolos HTTP v1.5 LRU NetCache C1105 72 512 1.0. NNTP. Traffic Server permite que o integração de aplicações diretamente na rede para desempenhar funções importantes como filtragem de conteúdo impróprio ou ofensivo Web ou transformar o conteúdo da Internet para que ele podem ser vistos em celulares ou computadores de mão.1. Transparente cache utilizando o protocolo WCCP permite a interoperabilidade entre Tráfego Inktomi Server e roteadores baseados em Cisco. o último constitui um pacote integrado de hardware e software através de parceiros Inktomi é chamado fabricantes de equipamentos originais (OEM).5 LRU NetCache N C720 1024 512 / A LRU Rede Appliance NetCache C6100 2048 3096 155 LRU A Tabela 1. filtragem e transformação na borda do rede.

6 e Solaris 7 em um Sun Ultra SPARC com pelo menos 256 MB de RAM.1 e Windows NT 4. AOS Traffic Server. linha de produtos. a Novell anunciou para adicionar suporte nativo para formatos comuns de mídia. bem como o FreeBSD 3. o ICP não suporta O cache de DNS. De acordo com a Novell. Novell O software solução de cache Web oferecido pela Novell [Nov01] compreende da Internet Caching System (ICS). Server Inktomie de tráfego pode ser executado nas plataformas de sistema operacional Sun Solaris 2. bem como os ISPs para aumentar a eficiência da sua rede de infra-estruturas. No entanto. aparelhos ICS podem ser configurados em clusters de balanceamento de carga e tolerância a falhas. FTP e NNTP. True64 UNIX em um Digital Alpha / servidor OSF com pelo menos 256 MB de RAM. aparelhos ICS tipicamente servem 40% para 70% dos pedidos diretamente do cache.5 em sistemas SGI MIPS com a pelo menos 256 MB de RAM. o ICS também sustenta a atividade madeireira e proxy transparente. assim. o tráfego de plataformas de software de servidor de apoio de seis a oito discos para armazenamento em cache web. Novell. Nesses sistemas. Aos parceiros incluem grandes fabricantes de PC como a Compaq.0 e 1. Empregando os maiores discos SCSI actualmente disponíveis. Novamente como Inktomi. reduzindo seus custos associados agindo como proxy de encaminhamento para acelerar o acesso das organizações à Internet. SGI IRIX 6.0 em qualquer Pentium sistema ou equivalente. ao contrário da linha de produtos de servidor de tráfego. Além disso.Server Inktomi Traffic inclui suporte para as principais tecnologias de transmissão de mídia através de compatibilidade com o Real Time Streaming Protocol (RTSP) e ao conteúdo da Internet Adaptation Protocol (ICAP). Traffic Aos Server. ICS prevê a entrega de alta velocidade de qualquer multimídia estática objeto por meio de encapsulamento HTTP. Dell e IBM. Throughput valores obtidos por Inktomie produtos de servidor de trânsito não pode ser especificado uma vez que depende da base hardware e sistema operacional. Como Inktomi. o highend Tráfego produto Server pode gerenciar o tamanho do cache de 400 GB. produtos ICS apoiar o ICP protocolos e . reduzindo a latência pedido e tremendamente melhorar a eficiência da rede. O ICS permite que pequenas e médias empresas.1. AOS ICS suporta os protocolos HTTP 1. Para dezembro de 2000. fornecendo controle de viver e ondemand fluxos de mídia. Estes fabricantes de equipamentos originais (OEM) ter licenciado o ICS e integrar esta solução de cache de software em seus dispositivos de Internet. Novell.

Devido ao seu código-fonte aberto filosofia. Ao contrário dos tradicionais software de cache. O Squid projeto foi liderado por Duane Wessels. o Squid suporta o protocolo ICP e WCCP v2. alguns programas opcional para reescrever as solicitações e . full-featured software Web proxy cache. Quanto à Inktomie. sem bloqueio. Squid Contrapondo-se ao hardware comercial e soluções de cache de software apresentada acima. Squid suporta protocolos HTTP v1. Squid consiste em um programa do servidor principal. Lula constitui a plataforma ideal para a implementação de protótipos acadêmicos de esquemas de cache da Web e protocolos.WCCP v2. Squid suporta o Secure Sockets Layer (SSL). não apóia pesquisas de bloqueio de DNS e implementa cache negativo de pedidos falhados.0 para o cache de Web de cooperação e apoio à gestão de rede é fornecida através da compatibilidade com SNMP. Aos solução de software. Squid v2. controles de acesso extensa. O Squid é software open-source disponível gratuitamente para instituições acadêmicas. O Squid mantém meta dados e especialmente objetos quentes em cache na memória RAM. Novell. Como as soluções de hardware Cache Flow. A versão atual do Squid. produto ICS pode gerenciar o tamanho do cache entre 9 e 27 GB.1. oposição a todos os outros solução de cache introduzido acima Squid também suporta cooperativa cache utilizando o Cache Array Routing Protocol (CARP) e Cache Digest. NNTP. e pedido integral madeireira. Squid não oferece suporte ao protocolo para aplicações de streaming como o digital transmissão de áudio e vídeo através da Internet. eu processo de E / S-driven. O Squid é um servidor de alto desempenho de proxy cache para clientes web. FTP. O Squid foi projetado para executado em sistemas Unix. o Squid processa todas as solicitações em um único. os produtos ICS executado sob o sistema operacional para fins especiais Proxy-OS fornecido pela Novell. Dependendo da plataforma de hardware. Cisco e Novell. Para Web caching cooperativo. produtos Aos ICS rodar em PCs Intel Pentium base com pelo menos 256 MB de RAM. Como sistema operacional. e cache DNS. é o resultado de esforços de inúmeras pessoas da comunidade da Internet. O software Squid foi originalmente desenvolvido no Laboratório Nacional de Redes Aplicada Investigação (NLANR) em um projeto financiado pela National Science Foundation. pesquisas de DNS caches. Além disso. valores rendimento alcançado pelo Novell. Como a Novell. um DNS lookup dnsserver programa chamado.0 e v1.0. chamado squid. produtos Aos ICS não pode ser especificado uma vez que depende do hardware subjacente plataforma. AOS Server Traffic. Ao utilizar o ICP leve. Aos produtos atualmente disponíveis não oferecem suporte ao protocolo para aplicações de streaming como áudio digital e transmissão de vídeo através da Internet. caches Squid podem ser organizadas em uma hierarquia ou malha de poupança de largura de banda adicional.3. o Squid [Squ01] é um não-comercial.

cache de Web de cooperação. LFU-DA. EFP segmentada e Greedy Dual Tamanho (GDS). Produto Vendedor substituição Fabricante Original Equipement Inktomi Server Traffic E-Class Traffic Server Classe C Tráfego Engine Server LRU NetStructure Intel 3Com Novell Internet Caching System LRU TaskSmart Compaq Dell PowerAppliance IBM Netfinity NLANR Squid LRU. SLRU. Dependendo da plataforma de hardware. GDS As estações de trabalho Unix Tabela 2. AIX. A Tabela 2 resume os dados do produto das soluções de software para armazenamento em cache web. Nota que Lula não só pode ser configurado para usar o cache de regimes de substituição LRU. Note-se que novamente todos os produtos comerciais empregam LRU como regime de substituição de documentos web. NetBSD. A Tabela 3 fornece um resumo dos protocolos de transporte de dados. e OS / 2. ele gera um número configurável de processos dnsserver. Unix e OSF Digital. Squid funciona em qualquer plataforma Unix modernos. IRIX. e algumas ferramentas de gestão e cliente. Como no caso das soluções de software de outros valores rendimento alcançado por Squid não pode ser especificado. Neste relatório. uma linha de cache ou de uma página de memória) e perder penalidades (demora para colocar um objeto em cache) são constantes. HP-UX. Em particular. cada uma das quais pode executar um único DNS bloqueio de pesquisa. streaming e adaptação de conteúdos suportados pelo hardware e soluções de software considerados para cache de Web. FreeBSD. mas também Menos freqüentemente usado com Dynamic Envelhecimento (LFU-DA). . Solaris. Técnicas de resumo de soluções de cache de software 4 Web substituição Esquemas Cache Nos sistemas tradicionais de memória de tamanhos de objeto (ou seja. Quando o squid é iniciado. A característica saliente da Web cache encontra-se na alta variabilidade tanto o custo para trazer novos documentos da Web e o tamanho de tais documentos. o Squid pode controlar o tamanho do cache de até 512 GB. nós apresentamos os resultados para menos usado recentemente.executar autenticação. o Squid roda em Linux. A requisitos mínimos de hardware são compostos por um computador de processador único ou estação de trabalho com 128 MB de RAM.

O modelo de custo constante é o modelo de escolha para o proxy caches institucionais. e dois de tamanho conhecimento substituição regimes Tamanho Greedy dupla e Greedy * A dupla. dois modelos de custos para os regimes de substituição Web cache foram introduzidas. quando chegar ao fim LRU. definir o tamanho da . Ela exige um parâmetro especificando o fp fração de memória cache utilizada para o segmento protegido. o documento solicitado está localizado no pilhas e colocadas no final do MRU protegidos segmento que é empurrado para baixo passo a passo para o fim do LRU segmento. que foram recentemente propostas. Em [JB00]. Estudos anteriores demonstraram que um fp = 0. O modelo de custo do pacote é apropriado para caches backbone proxy visando reduzir o tráfego de rede. o documento solicitado é buscado e colocado à MRU final do segmento desprotegido. o documento solicitado é colocado na mais recente utilizados final (MRU) um temporizadores. A funcionalidade do SLRU é ilustrada na Figura 2. ele é colocado no final MRU dos desprotegidos segmento e tratados como depois de um cache miss. Em um acerto de cache. Em o modelo de custos constantes. Se um objeto atingir o final LRU. ele é removido do cache de formulário. o que não foi referenciada durante o maior período de tempo. Portanto. que são principalmente visam reduzir a latência do usuário final por meio da otimização da taxa de acerto.Segmentado Least Recently Used. o custo de recuperação de documentos é fixo. Segmentado LRU resolve o problema de uma temporizadores dividindo a pilha em duas segmentos. um algoritmo baseado frequência menos utilizada com Dinâmica de envelhecimento. Depois de um cache miss. LRU utiliza uma LRU-Stack.6 produz melhores resultados [AFJ00]. Least Recently Used (LRU [AW97]) é uma política baseada em recência. Em um cache miss. Se o documento nunca é mencionado novamente. Ambos os segmentos são implementadas por pilhas LRU. Portanto. um segmento protegido e um segmento desprotegido. A funcionalidade do LRU é ilustrada na Figura 1. otimizando o taxa de acerto de bytes. ele é empurrado para baixo no final LRU. De lá. É com base na pressuposto de que um documento recentemente referenciado será referenciado novamente no futuro próximo. em substituição LRU remove os documentos do cache. em estudos de desempenho. SLRU é um regime de substituição parâmetros. O modelo de custo do pacote assume que o número de pacotes transmitidos determina o custo de recuperação de documentos.

Menos freqüentemente usado com Dynamic Envelhecimento (LFU-DA [AFJ00]) é uma frequência de base política que também leva em conta as informações de recência com um custo fixo e de tamanho fixo suposição. A implementação básica de LRU-DA mostrado na Figura 3. Aqui s (p) é o tamanho do documento e C (p) é uma função de custo descrevendo o custo de trazer p para o cache. o Ap valor do documento solicitado é atualizado. H (p) é definido como C (p) (p). Como LFU-DA. os valores de H são reduzidos por Hmin [CI97]. Posteriormente. LFU-DA LFU se estende por uma dinâmica algoritmo de envelhecimento. Greedy * Dual (GD * [JB99]. Em cada solicitação. o valor V (p) de um documento p é definido como H (p). Em LFU. A idade cache é denotado por L. Greedy Tamanho Dual (GDS [CI97]) proposto por Cao e Irani considera variações de custo e tamanho dos documentos na Web. Ele foi mostraram que LFU-DA atinge elevadas taxas de acerto de bytes. [JB00]) proposto por Jin e Bestavros capta tanto popularidade e correlação temporal em um córrego da Web documento de referência. Aqui. No entanto. L é definido como o valor de P o documento despejados. a desvantagem de GDS encontra-se em não levar em conta informações de freqüência no fluxo de solicitação. a decisão de expulsar um documento a partir do cache é feita pelo número de as referências feitas a esse documento. Quando p documento é apresentado inicialmente no cache ou quando já está referenciado em cache. Ao colocar um novo documento em cache ou referenciando um velho. LFU-DA mantém um cache de idade que é definido como a contagem de referência do último documento despejados. A . escolhendo a vítima com base na relação entre o custo eo tamanho dos documentos. associados GDS um valor de Hp a cada p documento da Web no cache. a fim de evitar a poluição de cache. Quando um documento tem de ser substituído. a vítima? com p? : Min {()} H min Hp p ? é escolhido entre todos os residentes documentos no cache.protegidos segmento para 60% do tamanho do cache. como EFP. a idade cache é adicionado à contagem de referência de documentos. A contagem de referência para todos os documentos em cache é mantida e o documento com menor contagem de referência é despejado. enquanto o valor de um documento V (p) é definida como a contagem de referência. Um implementação eficiente das funcionalidades GDS é fornecido na Figura 3. Em cada despejo. Um Ap valor é associado a cada documento em cache.

GDS (pacotes). A simulação corre apresentados na Seção 5 são executadas em um processador dual Sun Enterprise 450 estação de trabalho. LFA-DA. Este simulador consiste de 15. O primeiro aplica-se a modelo de custos constantes. O parâmetro E é caracterizar a correlação temporal entre sucessivas referências a uma determinado documento observadas na carga de trabalho.1 Caracterização de cargas de trabalho atual da Web Proxy Para caracterizar a carga de trabalho de cache de proxy da Web. consideramos cinco traços diferentes. que. Estes regimes de substituição são denotados GDS (pacotes) e GD * (pacotes). [CF01]. * GDS e GD caracterizar as famílias de algoritmos. c (p) 2? (p) 536. correlação temporal é tida em conta pela taxa de envelhecimento controlado pelo parâmetro?. analisamos duas variantes do GDS e GD *. SLRU. considere vestígios . 5 Caracterização de carga de trabalho de Traços e Previsão de Carga de Trabalho 5. Para mais informações sobre o ambiente de simulação ver apêndice A e B.freqüência em a fórmula para o valor de base L captura popularidade a longo prazo. O mais recente traço foi gravado em Julho de 2000. A medida de desempenho otimizado (ou seja. Para previsão de carga de trabalho. GDS (1). [JB00]. A mais antigos vestígios foram recolhidos em 1996 pelo DEC [Mog96] e já utilizado em versões anteriores estudos de desempenho dos regimes de substituição [BCF 99]. Referimo-nos aos algoritmos resultantes como GDS (1) e GD * (1). * GD pode ser implementado através da criação V (p) = H '(p) na implementação do código pseudo mostrado na Figura 3.000 linhas de código C. definindo a função de custo (p) c 1. respectivamente. Um simulador de eventos discretos foi aplicada para os regimes de substituição de LRU. conforme descrito na Seção 5. e * GD (pacotes) a utilização da simulação biblioteca CSIM [JB00]. * GD (1). * GD define os valores de H para um p documento? ? ? ? H (p)? c f (p) (p) (p)? E onde f (p) é a contagem do documento de referência. ou seja. A segunda variante se aplica o modelo de custo por pacote a definição da função custo para o número de pacotes TCP necessárias para transmitir p documento. taxa de batida ou taxa de acerto de bytes) de uma aplicação específica depende de definição do custo função c (p). respectivamente. adicionalmente. Neste relatório. A característica marcante da * GD é que f (p) e E podem ser calculados de forma on-line que faz o algoritmo adaptáveis a essas características de carga de trabalho. a rede de investigação alemã por DFN [GPV01].

representam cerca de 95% dos documentos do visto e dos pedidos recebidos. conforme especificado no cabeçalho HTTP. A traços CANARIE e DFN foram coletados no proxy cache de primeiro nível no núcleo do Canadense CA * net II e do alemão Research Network. E Univ. java) são adicionados à classe dos documentos HTML. DO. [CI97]. tex. 300 (Múltipla escolha). Univ.. O DEC e traços DFN são utilizados para avaliar a desempenho dos regimes de substituição proxy cache sob as atuais condições de trabalho.recolhidos no CA * net II canadense [MW99]. Os arquivos de texto (por exemplo. Sask.. ps e. CANARIE. documentos de imagem (por exemplo. Htm). considerou-se respostas a códigos de status HTTP 200 (OK). bem como um pequeno número de documentos de aplicativo (. Se nenhuma entrada tipo de conteúdo é especificado. Mp3. foram excluídos os documentos uncachable pela generalidade heurísticas conhecidas. respectivamente. A Universidade.. e na Universidade de Dortmund de julho de 2000. pdf) contida nos traços também são classificados como documentos multimédia. Nós omitir documentos que não poderiam ser classificados desta forma. Pré-processamento do DEC e traços DFN.. A Tabela 4 resume as propriedades de o DEC e DFN rastreamento.. Esta observação também foi observado em [MW99].. Respectivamente. Estes cinco traços são referidos como DEC. da Universidade de [MW99] Saskatchewan ambos de 1998. zip). procurando por "cgi" ou "?" na URL solicitada. supomos a classe do documento utilizando a extensão do arquivo. 301 (Movido Permanente). dezembro Sask. Mpeg. A características dos vestígios remanescentes são utilizados para derivar previsões de carga de trabalho. 302 (encontrado). . vestígios foram coletados no nível institucional proxy caches Web funcionando como de nível secundário caches Web Proxy. e 304 (Not Modified) como cacheable [AFJ00]. Tabela 4 indica que é propriedades dos traços dezembro e DFN. Detalhes sobre o rastreamento de pré-processamento são apresentados no Apêndice B. Carneiro. Podemos distinguir entre três classes principais de documentos na Web: documentos HTML (Por exemplo. Observamos que na atual carga de trabalho e HTML documentos de imagem em conjunto... 206 de conteúdo (parcial). E Univ. A partir da solicitações restantes. 203 (não Informações confiáveis). para uma série de vestígios outro proxy . Jpeg) e documentos multimídia (por exemplo. Gif. Nós derrubou o fluxo de solicitação de documentos de acordo com suas tipo de conteúdo. [JB99]. Html. por exemplo. Alguns comprimidos binário Download (. DFN. documentos típicos de áudio de multimídia são estáticas e os arquivos de vídeo. gz. Do.. Mov).

popular documentos são referenciados mais vezes em um curto intervalo de tempo de menos documentos popular. isto é:? P ~ E n?. Um documento quente Web é pedida várias vezes em curtos intervalos de tempo enquanto o documento média é referenciado apenas algumas vezes. Para os traços dezembro e DFN. localidade temporal no fluxo de pedido é causada por dois fontes diferentes: A popularidade de documentos da Web e da correlação temporal na pedido fluxo. Esse é o número de pedidos de visto no fluxo de solicitação de acesso entre sucessivas para um determinado documento. por exemplo. A propriedade chave para o desempenho de cache de Web constitui localidade temporal na pedido fluxo. isto é: N ~? D? . Sask. Temporal correlação entre acessos sucessivos com o mesmo documento pode ser medido pelo plotagem a contagem de referência em função do Tempo entre chegadas de referência. Estes valores indicam que há algumas imagens extremamente popular Considerando a popularidade é propagação mais ampla de documentos de texto e documentos multimédia. Para eliminar a influência da popularidade de tal conspiração (ou seja. correlação temporal levar em conta o tempo entre duas referências sucessivas ao mesmo documento. O segundo parâmetro. O número de pedidos de N para a documento Web é proporcional ao seu grau de popularidade? ? Ao poder. A probabilidade P de que um documento é solicitou novamente após pedidos n é proporcional ao n o poder de. os valores calculados para? e? são mostrados nas Tabelas 5 e 6. Figuras 4 e 5 parcelas para o traços dezembro e DFN os tempos interreference discriminado para cada classe do .entre os quais estão CANARIE e Univ. por entre chegadas de referência após a plotagem de um documento foi acessada k vezes. o enredo é feito por documento igualmente populares. documentos mais populares são susceptíveis de ser acessada após curtos períodos de tempo). localidade temporal pode ser caracterizada por dois parâmetros. denominado? mede a correlação temporal entre dois sucessivas referências ao mesmo documento web. Portanto. localidade temporal pode ser quantificada pela relação entre a probabilidade de um acesso a um documento da Web e do tempo decorrido desde o último acesso a esta documento. Como discutido em [JB00]. O primeiro parâmetro. O índice de popularidade? pode ser determinada a inclinação da log / log parcela escala para o número de referências a um documento da Web em função de seu grau de popularidade. Um documento popular da Web é visto frequentemente em um fluxo de solicitação. indicado como o índice de popularidade? descreve o distribuição de popularidade entre os documentos individuais.

que é o parâmetro? das reduções de distribuição Zipf-like. rastreamento são derivados da Tabela 5 e Figura 5 º [MW99].documento. A popularidade de documentos multimédia aumenta. Devido às tendências nitidamente observáveis. Como em todas as três classes de documentos Web sem tendências podem ser observado. com base nessas características. Posteriormente. Conforme mostrado na Figura 4 e 5.2 Previsão de Cargas de Trabalho Futuro da Web Proxy Para prever o volume de trabalho institucional proxy caches Web. que é y3 = ½ (y1 + y2). aumenta a correlação temporal e. podemos derivar com o mesmos métodos de regressão uma previsão de carga de trabalho para proxy caches localizados em redes de backbone. A previsão percentagens dos pedidos é feito utilizando uma regressão linear logarítmica para representar crescimento exponencial de usuários da web. A interreference tempo é dada pelo tempo decorrido entre dois acessos consecutivos a uma documento da Web em particular. Sask. de modo que eles somam 100%. portanto. os valores percentuais previstos são normalizados. o parâmetro? aumenta. imagem . o grau de localidade temporal na solicitação da Web córregos é diferente para os três considerados documentos classes. observamos as seguintes tendências: Os percentuais dos pedidos de documentos multimédia aumenta mais do que linear. a regressão linear é empregada para determinar a previsão para o índice de popularidade e de correlação temporal para cada classe do documento. A Tabela 6 apresenta as características correspondentes de HTML. o fluxo de referência de dezembro de rastreamento é alterada e os desvios correspondentes são determinados com base nos dados modificados rastreamento. Figura 6 parcelas os tempos interreference para cada classes de documentos para a previsão de carga de trabalho derivado desta forma. A Tabela 4 apresenta as características de cada classe do documento. As pistas diferentes descrevem como a localidade temporal no pedido de córregos foram modificados. além de dezembro de rastreamento que adicionalmente. e Univ. Usando o mesmo tipo de dados do CANARIE e traços DFN. Além disso. Essa é a previsão y3 valor é derivado dos valores observados y1 e y2 por aaaa 3? 2? (2? 1). As porcentagens de pedidos de documentos HTML também aumenta mais do que linear. Note que a distribuição dos tempos interreference reflete tanto popularidade e correlação temporal [JB99]. vestígios. Do. Sask. 5. Da Tabela 5. Os valores da Univ. Esse é o percentual previsto valores y3 é derivado ln y ln y (ln y ln y) 3? 2? 2? 1. considere Univ. as previsões para os tamanhos de documento média são determinados utilizando o método de média móvel. Posteriormente.

5. R é o número de referências para as mais populares documento dimensionados de acordo com a contagem global de referência para a classe de documento no Previsão do volume de trabalho. Número de pedidos de cada classe pode ser obtido pela seleção aleatória de a classe do documento para uma solicitação pendente de acordo com a distribuição de probabilidade especificados pela fração de pedidos para esta classe. O registro de lote / log das vezes interreference para aulas individuais é documento mostrado na Figura 7. Isso é N (d) U R D? ? . Os documentos estão divididos em (possivelmente . Nós calcular a freqüência relativa N (d) U de acordo com a distribuição especificada pela popularidade índice?. foi utilizado o método descrito abaixo. Para obter as características especificadas no Tabelas 5 e 6. Para manter a correlação entre o tamanho do documento e da contagem de solicitação [MW99]. evitando a necessidade de um modelo razoável de tempos entre.3 Derivando as previsões de carga de trabalho do DEC e Traços DFN Para analisar o desempenho dos regimes de substituição da Web para as previsões de carga de trabalho introduzido na Seção 5. [JB99] considera apenas uma fonte de localidade temporal. Para gerar uma solicitação fluxo. O modelo de referência independente escolhe um documento com o grau de popularidade? com probabilidade P ~? D? Como afirmado em [MEW00]. Estes traços sintéticos são baseados em traços atual: Previsão 1 baseia-se Dezembro de rastreamento. eo documento de popularidade e de correlação temporal na o fluxo de referência. Ela continua a mostrar como os documentos dentro de uma classe pode ser referenciada de acordo com a distribuições das duas fontes de localidade temporal especificado? uma?. O independente modelo de referência [BCF 99]. para o DEC e DFN traços que o número de todos os documentos dU uma classe de documentos pelo seu grau de popularidade?. considerando ambas as fontes de localidade temporal. Aqui. as cargas de trabalho de síntese ao invés de dados medidos são necessários como entrada para o nosso simulador. a distribuição dos tamanhos de documento. localidade temporal resultante de curto prazo correlação temporal é importante para o desempenho de caches pequenos. A média de tamanho dos documentos especificados no Tabela 5 e 6 podem ser alcançados por tamanhos de documento individual de escala para cada classe de documento por um fator constante. respectivamente. o popularidade.2. ou seja. precisamos modificar o número de pedidos para as classes diferentes de documentos.e multimídia documentos. Timestamps de solicitações de entrada são mantidos a partir de traços originais. Previsão de 2 em DFN rastreamento.

o caso ideal constitui. Entre os documentos d C U? . as imagens de 82% e 2. . vamos escolher um C popularidade classe com (?) Probabilidade PCCC jjj? ? D.1%. Resultados semelhantes foram foram observados para o DFN rastreamento. 50%). C d Nd j j? ? U U? | ()?. Figuras 7 e 8 parcelas a fração de imagem em cache e documentos multimédia para GD * (1) e EFP. ou seja. podemos avaliar a capacidade do regime de substituição GD * para se adaptar ao carga de trabalho real visto no cache do proxy. Escolhemos um documento com d P t d d d ci (?) ~ ()? UU E. HTML. Para gerar uma solicitação. Sob o modelo de custos constantes. O tamanho do cache é assumido como sendo 1 GByte. a fração de uma vez só como relatado em [MW99]. a fracção de documentos em cache é igual à fração de solicitações para esta classe de documentos no pedido córrego.1 Investigação da adaptabilidade * Dual Greedy Em um primeiro experimento. multimédia). Figura 4 e 5 mostram que para cada documento de classe * GD (1) atinge rapidamente o ideal fração de documentos em cache especificado na Tabela 4 (ou seja. por exemplo. Aqui Cj denota a cardinalidade do popularidade. Contrapondo-se a que. Estas observações explicam porque GD * (1) atinge hit alta Preço: GD * (1) não desperdiçar espaço do cache de Web. Testes empíricos mostram que o fluxo de solicitação resultante produz as mesmas características gerais. mantendo grande multimédia documentos que não serão solicitados novamente no futuro próximo. para cada classe de documentos (isto é. A correção desse algoritmo pode ser verificada através da plotagem do funções de distribuição de popularidade e correlação temporal de um log / escala logarítmica e adequando os Pistas? e? por um ajuste dos mínimos quadrados. imagens e multimédia).vazio) classes de popularidade do Cj documentos igualmente popular. Aqui. 40%) e a fração de documentos multimédia é substancialmente maior (ou seja. t d ci () U é o número de referências a documentos em Ci classe desde a última referência ao urânio empobrecido. em LRU fração dos documentos de imagem em cache é menor (ou seja. Como a carga de trabalho dezembro de rastreamento é considerado. 6 experimentos de desempenho 6. categoria Cj.

Para entender como cache de Web lidar com diferentes regimes de substituição de classes de documentos web. LFU-DA. Greedy-Size duplo (GDS) e * Greedy-duplo (GD *). nós apresentamos curvas que representam taxa de acerto e as taxas de sucesso byte discriminados para HTML. Os resultados podem ser transferidos diretamente para as recomendações para os operadores de redes de área local. nós introduziu um método eficaz para modificar dado dados de rastreamento para que o pedido modificado fluxo representa as características de carga de trabalho da previsão. A desagregação das taxas de . Embora todos os comercial soluções de cache Web depender apenas de EFP. e * GD pode ser usado no cache do Squid software web. MPEG) documentos na web. Para derivar cargas sintéticas para a previsão de carga de trabalho. GDS. que mostram o comportamento do state-of-the-art algoritmos e protocolos no âmbito mudança de comportamento do usuário.1. os regimes de nova proposta LFU-DA. mostra * que o GD (1) não desperdiça espaço de cache. O inquérito sobre a adaptabilidade dos * GD (1) apresentada na Seção 6. Contrapondo-se a anterior estudos. MP3) e vídeo (ou seja. apresentamos estudos de sensibilidade. características de carga de trabalho e tecnologia de rede. mas também dois previsões para futuras cargas de trabalho atendidos em caches Web Proxy. apresentamos os estudos da performance global de substituição de cache da Web regimes de LRU. nós fornecemos uma análise aprofundada do comportamento e problemas de design de autônomo e cooperativo ambientes Web cache. Internet prestador de serviços e fornecedor de serviços de aplicação. evidentemente. Para ativar o projeto de longo prazo. Esta observação explica por GD * (1) quase sempre atinge a maior taxa de sucesso. Foram apresentados vários estudos de desempenho com base sobre as actuais e futuras características de carga de trabalho. não podemos considerar apenas as cargas de trabalho atual com base em dados de rastreio. mantendo grandes documentos multimédia que são probabilidade de não ser relacionado no futuro próximo. imagens e documentos multimédia. Na Parte 1.12 Geral As conclusões extraídas dos Estudos da Performance Neste projeto. Esta previsão de carga de trabalho é motivado pelo número crescente de áudio digital (ou seja.

1998 e 2000. Lembre-se que os provedores estão mais interessados na quantidade de tráfego e salvos no protocolo eficiência. Lembre-se que as nossas previsões de carga de trabalho baseiam-se na pressuposto de que a fração de documentos multimédia aumenta significativamente. A taxa de acerto total de bytes é influenciado principalmente pelo índice de acertos de bytes em documentos multimédia. Para cargas de trabalho futuro. Nós investigamos o desempenho de cada um protocolos de pontos de vista dos Internet Service Providers (ISPs). latência do usuário. a popularidade de alguns documentos multimédia e que também aumenta o tempo entre dois sucessivos referências ao mesmo documento da Web diminui. As curvas apresentadas nas Figuras 24-29 indicam claramente que os ISPs . CARP. a GD * (1) realiza significativamente melhor que os outros regimes de termos de taxa de acerto. Para proxy caches pequenos. GDS (1) atinge o mesmo desempenho que o GD * (1) em termos de taxa de acerto. em termos de taxa de acerto byte claramente se tornaram importantes. cache digere. o desempenho como medidas que considerar o consumo de banda.sucesso e as taxas de acerto por byte classe do documento mostra que a taxa de acerto global é influenciada principalmente pela taxa de acerto nas imagens. o diferença na taxa de acerto alcançada por GD * (1) sobre LRU e-LFU DA tornou-se consideravelmente menores. foi apresentado um estudo do desempenho global da cooperativa de cache Web protocolos ICP. clientes e Internet empresas como Application Service Providers (ASPs). Numa avaliação global. Consequentemente. a desvantagem do GD * (1) sobre LRU e-LFU DA. Por outro lado. Na Parte 2. WCCP. Esses pressupostos são motivadas pela tendências derivadas de cinco traços medidos em 1996. GD * (1) também permanece competitivo com LRU e LFUDA em termos de taxa de acerto de bytes. Numa avaliação global. considerando tanto as taxas de sucesso e atingiu byte taxas. o software solução Web Cache Squid com o regime de substituição GD * (1) deve ser a escolha para cargas de trabalho atual. considerando tanto as taxas de sucesso e byte taxas de sucesso do software Squid solução de cache de Web com o GDS regime de substituição (1) deve ser a escolha para cargas de trabalho futuro. Como conseqüência. Além disso. Lembre-se que as cargas de trabalho atual consiste em cerca de 70% e imagens apenas cerca de 2% multimédia documentos. e utilização de cache.

Para o futuro Tendo em redes de backbone de banda de 2. ASPs beneficiar Web caching cooperativo no caso de redes backbone futuro fornecer largura de banda de 622 Mbps ou 2. Observa-se apenas pequenas diferenças no documento latências de recuperação realizados pelos protocolos individuais. Assim.4 Gbps. Lembre-se que ASPs estão mais interessados na utilização da cache baixo porque isso implica boa relação custo / desempenho trade-offs. proporcionando maior largura de banda em ligações às redes de backbone remoto ou implantar uma rede de distribuição de conteúdo são consideravelmente abordagens mais eficazes para reduzir a latência de recuperação de documentos de Web cooperativa cache. Como ilustrado nas Figuras 39-40. Para atualmente operando redes de backbone com uma largura de banda 155 Mbps.beneficiar Web caching cooperativo. o ICP é o protocolo de escolha devido à sua eficiência protocolo alta. o cache de Web de cooperação é mais benéfica entre institucional proxies de cache. estas curvas estão em latência o bairro da curva de latência para nenhum cache Web cooperativa. Assim. Neste caso.4 Gbps. foi constatado que o desempenho dos protocolos de cooperação cache da Web fortemente benefícios da localidade temporal. Como ilustrada em um estudo de sensibilidade. as curvas correspondentes NLANR apresentam melhor . WCCP é superior à ICP porque WCCP rendimentos mais elevados do que o tráfego salvo ICP enquanto que a eficiência do protocolo de baixa WCCP não matéria. Em todos os experimentos. os clientes não têm beneficiar muito com o cache de Web cooperativa independente de qual protocolo é utilizado. Lembre-se que os clientes estão mais interessados em baixa latência recuperação de documentos. os clientes irão beneficiar da redução do rácio entre tempo de transmissão eo tempo de download do documento. WCCP produz a mais baixa utilização de cache de todos os protocolos e utilização de cache também inferiores nenhum cache Web cooperativa. Portanto. Além disso. Desde localidade temporal é mais provável de ocorrer em um nível mais baixo de uma hierarquia de cache.

tanto o traço e DFN NLANR indicar um traço bastante baixa participação de cache de Web de cooperação entre seus assinantes. a razão para . Nós mostramos que o uso de um estado-da-arte do regime de substituição. Recomendações para o DFN-Verein como Internet Service Provider Os estudos da performance apresentada na Parte 2 mostram que. Como investigado por soluções de cache local. Nós resumir a forma como os clientes da DFN-Verein. recomendamos que os operadores de caches locais a tomar medidas para garantir a utilização de serviços de sua cache. investigamos o desempenho da localidade Web caches.desempenho do que para DFN. Recomendações para operadores de caches locais nas instalações dos clientes DFN Nos estudos de desempenho apresentado na parte 1. dado o padrão de uso corrente. No entanto. Além disso. se o cache é utilizado apenas por um subconjunto de todos os potenciais clientes. o poupança maior largura de banda alcançável por caching web cooperativa no Backbone G-WIN é cerca de 22%. tal como consta no rastreamento dezembro. verificou-se que o impacto da utilização de cache baixa devido à baixa participação na cooperativa Web caching fazer consideravelmente o impacto para o desempenho de protocolos individuais. Além disso. Como resultado de nosso estudo. A diferença de desempenho de cache causados por uso diferente padrões é muito maior do que o vazio causado pela aplicação de cache diferentes tecnologias e algoritmos. Alta aceitação cache eo uso são os blocos de construção para uma desempenho suficiente de soluções de cache al apresentado. a quantidade de salva tráfego reduz para menos de 20%. uma medida adequada é a instalação de soluções de cache transparente web. pelo emprego de Cache Web Coordenação WCCP protocolo. por exemplo. como é normalmente em todas as universidades alemãs até agora. Este estudo parte do princípio que todos os clientes dentro de uma instituição fazer uso da Web serviço de cache. Greedy Tamanho Dual * Greedy ou dupla podem economizar até 40% do volume de tráfego WWW para atuais e futuros cargas de trabalho. por exemplo. 13 Recomendações para o DFN-Verein Neste capítulo final. bem como a DFN em sua função como um ISP pode tirar vantagens das lições aprendidas neste projeto. Por exemplo. dar recomendações gerais retiradas de estudos o nosso desempenho.

como mostrado na parte 2. cache de cada pedido WWW emitidos de dentro do G-Vitória coloca enormes desafios para caches WWW e protocolos. medições e previsões. Por exemplo. No entanto. a NLANR-trace mostra melhor desempenho devido à alta aceitação e utilização da hierarquia de cache NLANR. teria problemas para obter um número suficiente de custo-desempenho razão. se disponível. pode-se argumentar que o DFN-Verein devem tomar medidas para garantir o uso de cache suficiente pelos clientes. porque eles podem. Conclui-se que os estudos da performance em profundidade deve ser usado antes da instalação de novas soluções tecnológicas. os clientes podem ser forçadas a fazer uso do serviço de cache de soluções de cache transparente em instituições locais. a priori. recomendamos que o DFN-Verein concentrar os esforços futuros transparentes sobre técnicas de replicação e de conteúdo WWW soluções de roteamento. que estavam disponíveis. que prevê avaliações econômicas de diferentes soluções de cache . Nossos estudos mostraram que o cache da web só é eficaz. bem como a carga de trabalho caracterização e modelagem. Propostas para projectos futuros A maioria dos trabalhos realizados neste projeto constitui o desenvolvimento da simulação ambiente para o local e distribuído soluções de cache Web.esta má performance é baixa utilização do serviço de cache pelos clientes. Uma razão para a utilização de cache de baixo é o pouco impacto do cache de Web de cooperação no fim latência do usuário. Os componentes desenvolvidos poderiam ser reutilizados em um curto prazo projeto. se utilizado pelos clientes. Contrapondo-se a investigar os resultados para o DFN-traço. Para desenvolver uma solução escalável um O custo do serviço de cache eficiente da Web. nem dentro do Gwin backbone. Como resultado de nosso estudo. nem em instituições locais. Os resultados dos estudos foram obtidos com base na carga de trabalho. descartar várias design alternativas e identificar o quadro para a utilização eficiente de uma abordagem tecnológica. a fim de obter ampla aceitação pelos clientes. por exemplo. sem construção de uma infra-estrutura de cache Web complexa. Recomendações gerais Os resultados apresentados na Parte 1 e 2 mostram como os estudos da performance pode ser empregada para avaliar o benefício da instalação de novas abordagens tecnológicas. Cache de hardware capaz de gerenciar cargas de trabalho deste dimensão. O principal objetivo de uma solução de cache deve ser para otimizar este medir o desempenho. como empregado Redes de Entrega de Conteúdo.

ração batida de bytes e latência do usuário final) para medidas de desempenho econômico (ou seja. Uma óptima do ponto de entrega ao cliente de vista é o mais rápido possível a entrega de um solicitado documento web. Usando o componentes existentes. retorno do investimento). que pode servir de ótimo conteúdo solicitado a partir de dois diferentes pontos de vista. Tal entendimento é fornecido pelos resultados o projeto atual. a latência do usuário final tem que ser substancialmente reduzido.web. Solicitação deverá ser dirigida para o servidor. Em segundo lugar. Do ponto de vista de um fornecedor de serviços Internet. uma ótima entrega economiza mais largura de banda externa (ou seja caro) links. considerando o investimento em hardware e de trabalho. Em um projeto de longo prazo. Para responder a estes conflitos metas de compreensão. . Isto pode ser conseguido através da redução atrasos servidor web. Para aumentar a cliente aceitação de soluções de entrega de conteúdo na investigação de Rede Gigabit G-ganha. Por fornecer essa combinação de software de simulação e cálculo econômico. a economia de banda esperada para uma configuração de cache arbitrária pode ser calculado com base em uma determinada carga de trabalho de rastreamento. métodos transparentes de redirecionamento de solicitações de usuários para servidores de cache tem que ser empregado. Conforme mostrado na Parte 2. Os resultados da simulação podem ser usados para executar um custo detalhada / benefício. o projeto resultados podem ser facilmente transferidos de medidas de desempenho de rede (ou seja. em profundidade de cooperação cache e da sensibilidade do cache distribuído sistemas de trabalho características é necessário. os resultados do projeto atual pode construir uma base teórica para a desenvolvimento de uma solução eficiente entrega ISP centrada conteúdo. a questões devem ser abordados: primeiro.