Controle de Tráfego em Provedores de Serviço de Internet

Transcrição

1 Controle de Tráfego em Provedores de Serviço de Internet Carlos Alexandre Zimmermann Escola Politécnica da Universidade de São Paulo Tereza Cristina M. B. Carvalho Lab. Arquitetura e Redes de Computadores Escola Politécnica da Universidade de São Paulo carvalho@larc.usp.br Resumo Os Provedores de Serviço de Internet estão sujeitos a volatilidade da demanda e a incerteza da capacidade de resposta. Estas características da carga e do sistema tornam difícil a manutenção da qualidade de serviço em sistemas de alta demanda. Este trabalho apresenta uma proposta de controle automático do fluxo de dados para aumento da eficiência, diminuição dos tempos de resposta e economia de recursos em sites com resposta dinâmica. 1. Introdução A manutenção de qualidade de serviço em Provedores de Serviço de Internet (ISP - Internet Service Provider) é um desafio aos profissionais da área de infraestrutura de tecnologia. Com o aumento da demanda é importante que os sistemas sejam cada vez mais eficientes possibilitando qualidade de serviço a baixo custo. Este estudo foi motivado pela dificuldade encontrada na análise e controle de desempenho de ISP s. Em especial para os sistemas que possuem necessidades críticas de desempenho. O trabalho está organizado da seguinte forma. No próximo capítulo caracterizamos o problema de desempenho em ISP s. No capítulo 3, são apresentados os fundamentos para a solução do problema descrito no capítulo anterior. No capítulo 4 descrevemos a solução baseada no controle tráfego. O capítulo 5 é dedicado à experimentos e a discussão dos resultados. 2. Desempenho em Provedores de Serviço 2.1. Contexto Apesar da evolução continua da tecnologia dos sistemas computacionais distribuídos, muitos dos protocolos utilizados na internet continuam os mesmos do seu início, basicamente HTTP sobre TCP/IP. O protocolo HTTP, utilizado na comunicação entre browser e ISP, inicialmente transportava páginas HTML estáticas. Mas com o aumento da demanda e surgimento de novas necessidades acabou sendo empregado na distribuição não apenas de documentos, mas também de aplicações. Percebe-se que a construção de páginas dinâmicas aumentou a complexidade do ISP. E, portanto, aumentou a complexidade da análise e do controle de desempenho do sistema. Existem algumas tentativas de análise e controle com elementos entre os servidores da rede interna. No entanto, essas soluções não são genéricas, uma vez que os servidores de aplicações e as bases de dados não possuem padrão definido. Cada sistema propõe a sua solução, que pode ser uma mistura de tecnologias, inviabilizando a análise de forma genérica. Este estudo propõe uma solução genérica, para análise e controle das métricas de desempenho do ISP, através dos Servidores HTTP. Estes servidores estão presentes em qualquer site, os mais comuns: Apache Server (67% do mercado [18]), Microsoft IIS (21%) e Netscape Enterprise (3%). Estes servidores possuem funcionalidades e interface similar além de comunicação padronizada. Nestes sistemas verifica-se alternância de momentos de sobrecarga e de abundância de recursos. Portanto, existe campo para a otimização dos processos envolvidos. O desafio está em analisar e controlar sistemas com variação abruptas na oferta e demanda de serviço. Estas variações ocorrem devido a diversos fatores do sistema e da carga que são de difícil modelagem Servidores HTTP O Servidor HTTP (SH) é a porta de entrada de um ISP. As requisições são tratadas de acordo com o tipo de documento. Documentos estáticos, como páginas HTML e imagens, são simplesmente recuperados do disco rígido e enviados ao requisitante. Caso seja uma chamada a um serviço a página deverá ser construída de forma dinâmica. Existem inúmeras formas de tratamento do conteúdo dinâmico. Em sistemas de alto desempenho, esta tarefa é repassada a servidores de aplicações e bases de dados dedicados. Independentemente de como estes servidores são requisitados, há uma latência. Este tempo de reposta é a

2 métrica que utilizaremos para determina a qualidade de serviço do ISP. Um dos problemas em relação à análise de desempenho deste tipo de sistema é a dificuldade em se determinar, quantitativamente e qualitativamente, os parâmetros que afetam o desempenho do sistema. Sem esta análise fica difícil determinar de forma criteriosa a quantidade de recursos necessários para a obtenção de um determinado tempo de resposta. Observa-se, no entanto, que a definição do parâmetro a ser controlado é outro problema. Nos trabalhos estudados os parâmetros de controle e as técnicas de monitoração e atuação não são genéricos. Resolvendose o problema de apenas um determinado tipo de SH em determinas plataformas. Os sistemas também carecem de controles globais. Ao invés disso o que existe são controles atuando individualmente em cada camada de rede. O protocolo TCP, por exemplo, apesar de possuir controle de fluxo e congestionamento não possui inteligência global. Ou seja, um controle que a partir do conhecimento do comportamento do sistema tente evitar o congestionamento. Desta forma os roteadores precisam de mais memória para seus buffers e os enlaces físicos sofrem sobrecargas que poderiam ser minimizadas. Há, portanto, um desbalanceamento entre a capacidade de oferta do sistema e da rede com a demanda gerada pelos usuários. Em sistemas de alta demanda esta falta de equilíbrio causa significativo desperdício de recursos. O ponto de equilíbrio dificilmente será alcançado, mas pode ser perseguido se o sistema for controlado com inteligência global Trabalhos Relacionados A teoria de filas desenvolveu um ferramental matemático muito poderoso para a análise de processos distribuídos [1]. Contudo a maioria dos conceitos parte do principio que os processos e a carga são Markovianos. Ou seja, tempos de chegada com distribuição Poisson e tempos de serviço com distribuição Exponencial. Estas características de filas M/M/1 não ocorrem em sistemas de internet. Estes são mais parecidos com sistemas G/G/n, sem distribuição específica, que limitam o estudo de forma analítica e forçam a simulação e a prototipação [2-4]. Alguns trabalhos recentes fixam o tempo de resposta e controlam a alocação de recursos para o SH. Em [6,7] são propostos modelos preditores com malha de controle feedfoward. Nestes trabalhos, foram encontradas dificuldades na determinação das taxas de chegada e de serviço que podem variar abruptamente. Mas a principal limitação é a forma de controle dos recursos de um servidor. No caso deles, o teste foi realizado em um servidor Apache, controlando-se a quota de processamento. Mas esse é um caso específico, em outros SH s e plataformas não é possível controlar a quota de processamento de forma determinística. Uma técnica interessante e que foi o caminho adotado neste trabalho é o controle da outra ponta, ou seja, da taxa de chegada de requisições e da disciplina de serviço através de algoritmos de agendamento. O EDF (Earliest Deadline First) apresentado em [5] propõe um algoritmo para o regime de fila em que o elemento mais próximo do limite de tempo de resposta teórico é disparado. Em [8] a variante PSCED (Packet Scheduled Control Earliest Deadline First) discute a discretização do EDF. 3. Fundamentos Teóricos Nesta seção são abordados tópicos que são os fundamentos matemáticos e conceituais para a proposta de controle de tráfego. A abordagem foca o que é utilizado nos próximos capítulos. Não há a intensão de se aprofundar nestes temas. As provas matemáticas podem ser encontradas em [8] e [9] Álgebra MIN-PLUS e Cálculo de Rede Nos ISP s tratamos parâmetros que variam abruptamente. Um valor pontual, como uma amostra do parâmetro é pouco representativa. Precisamos análisar um conjunto de amostras. Então estes parâmetros podem ser melhor análisados quando tratados como curvas. Ou seja, funções acumulativas dos parâmetros. A álgebra MIN-PLUS é um ferramental matemático para tratamento de curvas. Entenda-se por curvas as funções no tempo para as quais dados quaisquer t2 > t1 temos f(t2) f(t1). Ou seja, funções que nunca decrescem. Por exemplo, dado o parâmetro número de requisições por segundo. Uma amostragem em um minuto não é representativa. Podemos então análisar a curva do número de requisições até um determinado ante. O Cálculo de Rede [9] estuda a relação entre as curvas de parâmetros dos sistemas em rede. No capítulo 4 faremos uso destas relações. Para miaores detalhes e formalização veja as referências [8-13] Protocolo TCP Nesta seção são descritos alguns detalhes do protocolo TCP ([14] e [16]) e dos algoritmos de controle padronizados (RFC 2581 [15]) necessários para o entendimento da solução proposta. O segmento TCP possui a estrutura mostrada na Figura 1. Pode ter tamanho variado, limitado de acordo com as características da rede. PORTA ORIGEM PORTA DESTINO NÚMERO DE SEQUÊNCIA NÚMERO DE RECONHECIMENTO OFFSET - FLAGS JANELA DE RECEPÇÃO CHECKSUM DADOS URGENTES OPÇÕES (TAM VARIÁVEL) DADOS DE APLICAÇÃO (TAM VARIÁVEL) 0 32 Figura 1. Estrutura do segmento TCP. O campo JANELA DE RECEPÇÃO (rwnd) informa ao emissor a capacidade do buffer receptor. O emissor

3 deve assegurar que a quantidade de dados em transito (dt) não seja superior a janela rwnd. São considerados dados em transito os segmentos para os quais ainda não houve reconhecimento (ACK) por parte do receptor. Esta janela, no entanto, não é suficiente para garantir que não haja saturação dos enlaces de rede e dos buffers nos equipamentos intermediários. Por isso foram criados os controles de fluxo e congestionamento. Estes controles determinam a janela de ou janela de congestionamento (cwnd), que é uma variável de sessão do emissor. A janela de transmissão utilizada é a menor entre a janela de recepção rwnd e a janela de congestionamento cwnd. Em condições normais, sem erro e perda de dados, a velocidade de transmissão é controlada pelos algoritmos Slow Start e Congestion Avoidance. Eles trabalham juntos para determinar o tamanho da janela de congestionamento Modelagem de latência. Posteriormente, neste trabalho, será determinada a curva de serviço β u, que representa a resposta da conexão de um determinado usuário através da internet. Nesta sessão será feita a modelagem de latência, ou tempo de transmissão para determinarmos a curva de serviço. Dada a curva de serviço βu= r u.[t d u ]+, podemos aferir os parâmetros taxa de transmissão r u e retardo d u, através da análise da seqüência de segmentos TCP. A transmissão de dados começa com o estabelecimento da conexão. Nesta fase são enviados segmentos de controle (sem dados) e pode-se amostrar o RTT (Round Trip Time), ou tempo entre o de um segmento e a recepção do ACK. Devido a variação rápida dos valores amostrados do RTT o protocolo TCP utiliza estimativa por média móvel exponencial (EWMA - Exponential Weighted Moving Average). Por este método a cada amostra atualiza-se a estimativa de média e desvio padrão, conforme segue: Esta estimativa é eficiente, pois diminui o peso das amostras mais antigas. Quanto maior o fator p (tipicamente igual a 0,1) mais rápido as estimas antigas são descartadas. A média EWMA também é utilizada nos controles de fluxo e congestionamento para estimar o tempo ótimo de retransmissão de segmentos. Na Figura 2 temos a seqüência simplificada de conexão e requisição. Neste exemplo temos a fase de conexão, onde são passados segmentos de controle. E a fase de requisição com passagem de segmentos de dados completos (MSS bytes). Na fase de conexão, o tempo entre o do segmento de controle e o recebimento do ACK é 1 RTT. O retardo de transmissão d u é determinado como a metade do valor estimado RTT. Enquanto que nos períodos de de dados o tempo transcorrido entre o do segmento e a recepção do ACK é igual a RTT + MTU/r. Ou seja, temos os parâmetros de βu conforme segue: Tem-se então a taxa de r u (em bytes/s) e a latência d u (em segundos). Está definida, portanto, a curva de serviço β u. 4. Controle de Tráfego Pretendemos controlar o tráfego no ISP determinando quando e como responder às requisições. Em sistemas elétricos, mecânicos, hidraulicos entre outros, existe o conceito de casamento de impedância. Significa que há um ponto de equilibrio entre o sistema e a carga que otimiza a transferência de energia. Quando há casamento de impedância o sistema trabalha no ápice da eficiência, ou seja, com perda mínima de energia. No caso de sistemas de internet as coisas não são tão simples. Trata-se de um mundo discretizado onde os componentes e a carga são dificilmente modelados com resultados satisfatórios. Ao requisitar um serviço através da internet o usuário envia uma requisição HTTP GET ou POST a um Servidor HTTP que é a porta de entrada do sistema. A subrede do SH é ideal para hospedar um proxy de monitoração e controle. Pois concentra a interface entre a rede externa e a interna. Quando o SH verifica que a chamada deve ser tratada de forma dinâmica esta tarefa é repassada a servidores de aplicação. Independentemente de como estes servidores são requisitados, para a contrução de uma página dinâmica, nos importa conhecer a curva de resposta do sistema de cada serviço. Na Figura 3 a curva de resposta R s (t) do serviço s, representa a resposta (bytes em função do tempo) do conjunto de recursos que geram a página dinâmica requisitada pelo usuário u (requisição γ s,u ). Figura 2. Diagrama seqüência de segmentos TCP. Figura 3. Sistema internet simplificado recebendo a requisição γs,u do usuário u ao serviço s.

4 Cada um dos serviços de um sistema representa um conjunto de recursos de hardware e software diferentes que conseguem dar vazão a um determinado número de requisições simultâneas. Além do qual fomar-se-ão filas de atendimento em algum ponto do sistema. O que afeta o desempenho do conjunto e se reflete em aumento do tempo de resposta. Assim como a rede interna, a externa também possue suas limitações de resposta. A internet é o gargalo de comunicação. Impõem limitações de taxa de transferência e latência que devido a sua natureza heterogênea podem variar muito de um usuário para outro. Temos, por exemplo, usuários conectados por banda larga e outros por linha discada, backbones rápidos em locais de boa infra-estrutura e sub-redes sobrecarregadas em outros. Inicialmente a inserção de um cache de saída pode melhorar a eficiência do sistema. Cada resposta de um determiando serviço possui uma parte criada dinamicamente única e uma parte comum a todas as respostas. Se pudermos adiantar a parte comum (estática) teremos um ganho em relação ao tempo de resposta Controle de Antecipação A partir da existencia do cache de saída podemos realizar o controle de fluxo. Na Figura 4 temos a malha de controle do proxy para antecipação da parte estática na taxa de transferência adequada a banda do usuário. Dada a requisição γ s,u do usuário u para o serviço s, o sistema responde com tempo de resposta drs. Se esta resposta for gerada dinamicamente a parte estática é separada da dinâmica e armazanada no cache. Caso este serviço já tenha sido requisitado antes então já deve existir uma cópia desta. A partir da existência de uma cópia confiável pode-se antecipar a parte estática Re s. A curva de resposta Rds apresentada ao Moderador é a parte dinâmica filtrada da resposta do serviço. Que pode ser enviada assim que ficar pronta. enlace com a rede pública recebe dados acima da capacidade de e sobrecarrega os buffers dos roteadores. Isso é tratado pelo controle de fluxo e congestionamento do TCP. Mas pode ser evitado através do controle de proposto adiante. O bloco Identificador funciona como sniffer capturando os dados no segmento de rede dos Servidores HTTP. Através da análise das requisições e respostas HTTP pode-se determinar o tempo de resposta e a página gerada. Estas informações são guardadas em uma base de dados formando um cache de respostas HTTP. No caso de páginas estáticas a resposta do Servidor HTTP é rápida e não há a necessidade de antecipar nada. Já no caso de páginas dinâmicas, sempre há um retardo devido ao processamento e montagem. Neste tempo de processamento estão incluidos os períodos de requisições a servidores de aplicações, bases de dados e mainframes. O bloco Filtro tem a função de separar a parte dinâmica e estática da resposta HTTP e armazená-las no cache. A parte estática é enviada ao Moderador. Depois de algumas requisições, a um mesmo serviço, é possível determinar qual a parte dinâmica e qual a parte estáticas da resposta. Alternativamente o início e o fim do trecho dinâmico podem ser indicados por tags. Por exemplo, o site disponibiliza um serviço de tradução Inglês-Português (Figura 5). A página gerada é composta do cabeçalho e do código HTML, conforme exemplificado abaixo: <html> <head> <title>search Results</title> </head> <body BACKGROUND="images/bckgrndyd.jpg> <table class="blue_border" width="90%" cellpadding="2"> <tr><th valign="top" align="left">terms</th><th valign="top" align="left">translations</th></tr> <!- - IniDin - - > <tr> <td align="left" valign="top"><b>1. <a href = "?text=smoothing&service=ep">smoothing</a> [n.]</b></td> <!- - FimDin - - > </table> </body> </html> Figura 4. Diagrama de controle. Devido a limitações da rede interna e da internet os dados enviados pelo sistema Rs,u são recebidos pelo usuário com outra curva R u caracterizada por uma taxa e um retardo específico de cada usuário (conexão). Como o gargalo de comunicação é a internet a taxa de transferência da rede interna ao backbone é maior que a do backbone ao browser do usuário. Então a banda do Figura 5. Exemplo: serviço de tradução do site Neste exemplo, a maior parte do HTML e seus componentes, como a imagem bckgrndyd.jpg, podem ser antecipadas enquanto a parte dinâmica, tradução, é realizada. Esta antecipação será mais efetiva quanto

5 maior a carga estática e menor a taxa de transferência do usuário requisitante. Alguns elementos que aumentam a carga estática são: imagens, applets, arquivos de estilo (CSS) entre outros. Na prática esta antecipação é realizada substituindose o trecho dinâmico por uma chamada ao próprio site conforme segue: <!- - IniDin - - > <frame src = " alt = "Aguarde "> <!- - FimDin - - > Esta chamada é feita pelo browser assim que a linha de código chegar. E quando retornar ao sistema, não será atendida pelo Servidor HTTP e sim pelo proxy. Este irá responder enviando apenas a parte dinâmica da página Determinação dos Instantes de Envio e Processamento Apenas com o controle de antecipação já é possível obter um ganho no tempo de resposta. Na Figura 6 a parte dinâmica é enviada logo após a parte estática. No entanto o da parte estática assim que a requisição é recebida pode nem sempre ser a melhor solução para sistemas de alta demanda. Esta determinação deve ser feita com base no taxa de transferência e no tamanho da parte estática. A taxa de transferência para o usuário u é estimada (β u ). E o tamanho da parte estática é obtido do cache. A existência do cache torna possível o agendamento do inicio de processamento e de inicio de transmissão. Além de permitir o controle da taxa de para adequar a curva de saída R u à curva de resposta β u. Figura 6. Otimização da banda e diminuição do tempo de resposta total: T2< T1. (a) Curva de resposta sem controle (T1). (b) Curva de resposta com antecipação e controle de fluxo (T2). No bloco Moderador estão as funcionalidades para determinação da curva de serviço de comunicação com o usuário e para o controle da taxa de. Determinamos a curva de resposta através de estimativa do RTT dos segmentos TCP enviados. Uma vez conhecida a curva de serviço de comunicação com o usuário u pode-se estimar a duração do de uma determinada resposta de s,u. Sendo Le s o tamanho conhecido da parte estática do serviço s, tem-se: Com base nesta estimativa, e na estimativa do tempo de processamento dp s do serviço s, podemos determinar os antes de início de da parte estática tes,u e dinâmica td s,u (Figura 7): para dp s < de s,u para dp s > de s,u Figura 7. Faixas de tempos de da parte estática e dinâmica. (a) dp s < de s,u (b) dp s > de s,u A determinação do ante de início de processamento pode diminuir o número de usuários simultâneos no sistema e liberar recursos para terminar os serviços em andamento. A existência de muitos usuários no sistema pode afetar o desempenho devido a concorrência no acesso a recursos como rede, disco rígido e processador. Para os serviços com pouca variação no tempo de resposta podemos utilizar a seguinte expressão:, então: quando dp s < de s,u => 0 tp s de s,u - dp s ; quando dp s > de s,u => tp s = 0. Já a determinação dos isntântes de pode ser usada para otimizar a banda de transmissão. Podemos pensar em algoritmos de agendamento de. No entanto deixaremos este tópico para trabalhos futuros. Vamos considerar os seguintes tempos: te s,u = 0, da parte estática assim que a requisição chegar; td s,u = max{dp s, de s,u }, da parte dinâmica assim que ficar pronta, após o da parte estática; Ao invés da ação pontual de determinar os antes de ótimos, optamos por iniciar o o quanto antes e controlar a taxa de transmissão. Este controle feito em malha fechada pode trazer melhores resultados, diante das incertezas do comportamento da rede Controle de Taxa de Transmissão O emissor TCP normalmente tentará enviar os dados na maior taxa possível. Como, com base nos dados do cache, conhecemos o tamanho da parte estática Le s e a duração do processamento da parte dinâmica dp s, podemos determinar a taxa de ótima:, onde d u é a latência de transmissão, característica que não pode ser alterada.

6 Esta é a taxa de transferência mínima necessária para o da parte estática antes que a parte dinâmica fique pronta. Taxas maiores iriam sobrecarregar o enlace de saída da rede desnecessariamente. Para obter esta taxa será necessário manipular as janelas de controle do emissor TCP. A janela de recepção (rwnd) é preferível em relação à janela de congestionamento (cwnd), pois ela não interfere nos algoritmos de controle de fluxo e congestionamento. A pergunta é como calcular o tamanho da janela W u para que a curva de serviço da internet se aproxime de βwu = cu.[du t] +. O diagrama da Figura 8 mostra o processo de transmissão em controle de malha fechada. O moderador não pode controlar a curva de R s,u pois os dados são transmitidos pelo emissor TCP (o SH). A não ser que fosse reescrito um emissor TCP para este fim. O que acarretaria em perda de generalidade e aplicabilidade do proxy. Em vez disso o Moderador pode modificar a janela informada pelo receptor TCP (o browser). ru). Mas quando ru é tal que ru.du > W então βwu >= βu e c u = W u /d u. Figura 9. Curva de serviço βw u para: (a) r u.d u <= W u ; (b) r u.d u > W u Ou seja, devemos modificar a janela de recepção tal que rwnd(t) = min{ [c u.d u - R s,u (t)] +, rwnd(t) } e o emissor TCP utilizará a menor entre Wu e cwnd. Desta forma a taxa de transmissão é modificada utilizando as variáveis de controle do próprio protocolo TCP. 5. Avaliação do Controle de Tráfego Figura 8. Diagrama de controle da taxa de transferência do serviço s ao usuário u. Modificando a janela do receptor percebida pelo emissor podemos atuar na taxa de emissão. O controle realizado pelo moderador deve ser tal que: ou Então, aplicando o Teorema de [8], a máxima solução é a convolução entre R s e o fechamento subaditivo de R u + W, ou seja, (1) Não conhecemos o mapeamento de Rs,u em Ru mas sabemos que R u é limitado por β u (conhecido) : (2) Então, substituindo (2) em (1): Ou, substituindo (1) em (2): Então, dada a curva de serviço da rede (internet) β u = r u.[d u t] + e limitando a janela de a W u, temos a curva de serviço da malha fechada βw u = c u.[d u t] +. A Figura 9 mostra o efeito do controle da janela na taxa de transferência. Para β u com taxa de transferência r u tal que r u.d u <= W não há atuação e βw u = β u (ou c u = Para verificar o ganho com a utilização do contrle de tráfego recorremos aos logs dos Servidores HTTP de um sistema real. Trata-se do log de requisições do IIS (Internet Information Service) de um sistema de Internet Banking. A partir destes dados reais vamos averiguar o ganho caso o cache fosse inserido. Para cada requisição o IIS realiza diversos registros como: date (data da requisição), time (tempo da requisição), c-ip (IP do cliente (browser), s-ip (IP do servidor), cs-uri-stem (trecho da URI sem o domínio início e a query ), cs-uri-query (query, trecho da URI com parâmetros GET), sc-bytes (bytes recebidos), csbytes (bytes enviados), time-taken (tempo para processamento) e cs(referer) (referência). Este último campo permite rastrear qual requisição originou outra. Por exemplo, ao requisitar uma página que possua imagens ao IIS, o browser recebe primeiro a página HTML. Que então indica as imagens que devem ser requisitadas. Neste caso a requisição à página HTML não possui referência, ou seja Referer nulo. Mas as requisições às imagens fazem referência no log à página anterior. Denominamos de requisições primárias as chamadas às páginas e aos serviços. E de requisições secundárias as chamadas aos arquivos complementares como imagens, javscripts, CSS, etc Podemos estimar o tamanho da parte estática e dinâmica considerando, por simplificação, que a parte estática é composta apenas pelos arquivos secundários e que todo o código HTML da requisição primária é construído de forma dinâmica. A Tabela 1 mostra um trecho do log com a vinculação, através do campo ref, das partes secundárias às partes primárias de cada requisição. Com base neste vínculo, determinamos os tamanhos (em kb) das partes primárias ( tam ) e das partes secundárias ( tam ).

7 Tabela 1. Trecho do log e análise para determinação da parte estática (tamanho em bytes). time req cs-uri-stem ref tam tam 00:01: /scripts/comunic_owb.dll :01: /rie/imagens/bul_tit_sessao.gif :01: /rie/imagens/bul_ret_verdec.gif :03: /scripts/comunic_owb.dll :03: /owb/images/setaazul.gif :03: /owb/images/amarelo.gif O cache proposto deve antecipar a parte estática da requisição. Nesta avaliação fomos obrigados a fazer uma simplificação por falta de dados da composição das páginas HTML. Portanto, consideramos que a parte estática é composta apenas pelos arquivos secundários e que todo o código HTML da requisição primária é construído de forma dinâmica. Com base no tamanho da parte estática e com a taxa de transferência média para um dado usuário podemos estimar os tempos de. Vamos considerar que a curva de resposta da rede para todos os usuários é: β(t) = t, ou seja, taxa de transmissão r=32 kb/s e latência de transmissão d = 0 (simplificação). Na Tabela 2 estimamos o tempo de resposta. Sem o cache, a parte secundária só é requisitada após a parte primária ser processada e enviada. Tabela 4. Comparativo com e sem cache (tempos em segundos). time req resp s/ tempo CACHE tempo resp c/ CACHE dif % 00:01: ,623 0,579-0,044-7,098 00:02: ,731 0,528-0,203-27,759 00:03: ,903 0,874-0,029-3,219 00:03: ,445 2,149-0,296-12,105 00:03: ,471 0,328-0,144-30,536 00:03: ,766 0,406-0,360-47,036 Percebe-se uma diferença significativa, mas para validar a comparação fizemos os mesmos cálculos com uma massa maior de dados. Tomamos 30 min do log, aproximadamente 2500 requisições (260 requisições primárias). As Figuras 10 e 11 mostram o ganho do tempo de resposta. Figura 10. Gráfico de Ganho, em segundos, do tempo de resposta por requisição. Tabela 2. Análise do tempo de resposta sem cache (tempos em segundos). time req tam tam dur dur cheg req resp usu U min resp usu U temp resp 00:01: ,376 0, , , , , ,623 0,623 00:02: ,029 0, , , , , ,731 0,731 00:03: ,015 0, , , , , ,903 0,903 00:03: ,015 2, , , , , ,445 2,445 00:03: ,047 0, , , , , ,471 0,471 00:03: ,031 0, , , , , ,766 0,766 Com a inserção do cache a parte secundária é enviada de imediato (sem esperar o processamento da parte primária - dur proc ). Na Tabela 3, podemos notar diminuição dos tempos de resposta. Tabela 3. Análise do tempo de resposta com cache (tempos em segundos). time req tam tam dur dur cheg req min resp usu U min resp usu U temp resp 00:01: ,376 0, , , , , ,579 0,579 00:02: ,029 0, , , , , ,528 0,528 00:03: ,015 0, , , , , ,874 0,874 00:03: ,015 2, , , , , ,149 2,149 00:03: ,047 0, , , , , ,328 0,328 00:03: ,031 0, , , , , ,406 0,406 Na Tabela 4 comparamos os tempos de resposta das Tabelas 2 e 3. Figura 11. Gráfico de Ganho, proporcional, do tempo de resposta por requisição. A diminuição do tempo de resposta foi em média de 17,4%, chegando a 50%. Em servidores de alta demanda, com dezenas de requisições por segundo, estas diferenças porcentuais são muito significativas, podendo trazer redução nos custos de infra-estrutura além de aumento da qualidade de serviço. O ganho obtido com a antecipação será mais efetivo quanto maior a carga estática e menor a taxa de transferência do usuário requisitante. 6. Conclusões Apesar do crescente interesse nesta área ainda é complexo modelar sistemas de internet. Pois o sistema e a carga são governados por eventos de distribuição de probabilidades indeterminados. O que torna difícil controlar o desempenho para manutenção de tempos de resposta baixos. Também existe a dificuldade de

8 determinação de parâmetros de desempenho genéricos, entre servidores e plataformas diferentes. O Controle de Tráfego determina quando transmitir, como transmitir e que tipo de requisição e resposta deve ser transmitida. Com a inserção de um cache para antecipação da parte dinâmica obtemos alguns parâmetros de controle independentes da plataforma e da tecnologia dos servidores. Estes parâmetros são: a taxa de transmissão dos dados, o ante de início transmissão e o ante de início de processamento. Controlando estes parâmetros é possível aumentar a eficiência do ISP. O tempo de resposta é reduzido pela ação antecipatória do cache. A banda de transmissão utilizada é reduzida pelo controle da taxa de transferência e do intante de. E o processamento dos servidores também é reduzido pelo controle do ante de início de processamento. Este conjunto de ações controla o tráfego no Servidor HTTP balanceando a oferta e a demanda do sistema Contribuições do Trabalho A utilização do controle proposto contribui para a melhoria da qualidade de serviço dos sistemas de alto desempenho. E propicía redução de custos de infraestrutura Trabalhos Futuros Trabalhos futuros podem se valer dos algoritimos apresentados para a elaboração de uma ferramenta de gerênciamento de desempenho. Na Figura 12 temos a tela de modelagem da ferramenta que está sendo dedenvolvida. Os componentes hardware e software monitorados são considerados servidores de filas. [5] V. Sivaraman and F. Chiussi, End-to-End Statistical Delay Guarantees using Earliest Deadline First Packet Scheduling, in Proc. of GlobeCom, Rio de Janeiro, Brazil, Dec. 1999, pp [6] L. Sha, X. Liu, Y. Lu and T. Abdelzaher, Queueing model based network server performance control, in 23th IEEE Real- Time System Symposium, [7] L. Sha, X. Liu, Y. Lu, T. Abdelzaher and C. Lu, Feedback Control with Queueing-Theoretic Prediction for Relative Delay Guaranteees in Web Servers, in 9th IEEE Real-Time and Embedded Technology and Applications Symposium, [8] Jean-Yves Le Boudec and Patric Thiran, Network Calculus: A theory of Deterministic Queueing Systems for the Internet, Springer-Verlag, Berlin Germany, [9] D. Starobinski, J. Karpovsky and L. A. Zakrevsky, Application of Network Calculus to General Topologies Using Turn-Prohibition, IEEE/ACM TRANSACTIONS ON NETWORKING Vol. 2 - N.3, Jun [10] C.S. Chang, On deterministic traffic regulator and service guarantee: A systematic aproach by filtering, IEEE Transactions on Information Theory, Aug. 1998, pp [11] R. Arawal and R. Rajan, Performance bounds for guaranteed and adaptive services, IBM Technical Report RC 20649, Dec [12] J. Naudts, Toward real-time meassurement of trafic control parameters, Computer Networks, 2000, pp. 34: [13] F. Baccelli, G. Cohen, G. J. Olsder and J. P. Quadrat Synchronization and Linearity, An Algebra for Discrete Event Systems, John Wiley and Sons, [14] Information Sciences Institute (USC), Transmission Control protocol, Network Working Group RFC 793, EUA, Sep [15] M.Allman, V.Paxson and W.Stevens, TCP Congestion Control, Network Working Group RFC-2581, EUA, Apr [16] G.McKinney, TCP/IP State Transition Diagram, Network Working Group RFC-793, EUA, Feb [17] ITU-T Recomendação I.311, B-ISDN General Networks Aspects, Genebra, [18] Server Watch statistics (indicated by ISOC site), at May Figura 12. Ferramenta de monitoração e análise do sistema. 7. Referências Bibliográficas [1] R. Jain, The Art of Computer Systems Performance Analysis: Techniques for Experimental Design, Measuremente, Simulation and Modeling, Wiley-Interscience, New York - NY, April [2] J. Lehoczky, Real-Time Queueing Theory, in 17th IEEE Real-Time systems Symposium, [3] J. Lehoczky, Real-Time Queueing Network Theory, in 18th IEEE Real-Time systems Symposium, [4] J. Lehoczky, Using Real-Time Queueing Network Theory To Control Lateness In Real-Time Systems, ACM SIGMETRICS 97, 1997, pages