Controle de Tráfego em Provedores de Serviço de Internet
Carlos Alexandre Zimmermann
Tereza Cristina M. B. Carvalho
Escola Politécnica da Universidade de São Paulo
Lab. Arquitetura e Redes de Computadores
Escola Politécnica da Universidade de São Paulo
[email protected]
[email protected]
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.
2.2. 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
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.
2.3. 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].
3.1. Á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 instante. 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].
3.2. 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
OFFSET
NÚMERO DE RECONHECIMENTO
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
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 envio 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.
3.2.1. 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= ru.[t– du]+, podemos
aferir os parâmetros – taxa de transmissão ru e retardo
du, 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 envio 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.
Figura 2. Diagrama seqüência de segmentos TCP.
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 envio 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 envio de dados o tempo transcorrido entre
o envio 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 envio ru (em bytes/s) e a
latência du (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 Rs(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 3. Sistema internet simplificado recebendo a requisição
γs,u do usuário u ao serviço s.
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.
4.1. 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 envio 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 envio 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 www.yourdictionary.com 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 Ru 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
www.yourdictionary.com.
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
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:
os instantes de início de envio da parte estática tes,u e
dinâmica tds,u (Figura 7):
• para dps < de s,u
• para dps > de s,u
<!- - IniDin - - >
<frame src = "http://site/ParteDin?ID=3167&delay=8” 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.
4.2. 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 envio 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
envio para adequar a curva de saída Ru à 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 envio.
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 envio 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 dps do serviço s, podemos determinar
Figura 7. Faixas de tempos de envio da parte estática e
dinâmica. (a) dp s < de s,u (b) dps > de s,u
A determinação do instante 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 dps < de s,u => 0 ≤ tps ≤ de s,u - dps ;
• quando dps > de s,u => tps = 0 .
Já a determinação dos isntântes de envio pode ser
usada para otimizar a banda de transmissão. Podemos
pensar em algoritmos de agendamento de envio. No
entanto deixaremos este tópico para trabalhos futuros.
Vamos considerar os seguintes tempos:
• tes,u = 0 , envio da parte estática assim que a
requisição chegar;
• tds,u = max{dp s , de s,u}, envio da parte dinâmica
assim que ficar pronta, após o envio da parte
estática;
Ao invés da ação pontual de determinar os instantes
de envio ótimos, optamos por iniciar o envio 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.
4.3. 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 dps,
podemos determinar a taxa de envio ótima:
, onde du é a latência de transmissão,
característica que não pode ser alterada.
Esta é a taxa de transferência mínima necessária para
o envio 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 Wu para que a curva
de serviço da internet se aproxime de βwu = c u.[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 envio Rs,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/du.
Figura 9. Curva de serviço βwu para: (a) ru.du <= W u; (b) ru.d u > W u
Ou seja, devemos modificar a janela de recepção tal
que rwnd(t) = min{ [c u.du - Rs,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 4.3.1 de [8], a máxima
solução é a convolução entre Rs e o fechamento subaditivo de Ru + W, ou seja,
(1)
Não conhecemos o mapeamento de Rs,u em Ru mas
sabemos que Ru é 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 =
ru.[du – t]+ e limitando a janela de envio a Wu, temos a
curva de serviço da malha fechada βwu = c u.[du – t]+.
A Figura 9 mostra o efeito do controle da janela na
taxa de transferência. Para βu com taxa de transferência
ru tal que ru.du <= W não há atuação e βwu = βu (ou cu =
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
Pri’, 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 Pri’) e das
partes secundárias (‘tam Sec’).
Tabela 1. Trecho do log e análise para determinação da parte
estática (tamanho em bytes).
time
req
00:01:54
00:01:54
00:01:55
00:03:20
00:03:24
00:03:38
107
108
109
117
118
119
cs-uri-stem
ref Pri tam Pri
/scripts/comunic_owb.dll
tam
Sec
0
12038
1416
/rie/imagens/bul_tit_sessao.gif
107
0
0
/rie/imagens/bul_ret_verdec.gif
107
0
0
/scripts/comunic_owb.dll
0
476
930
/owb/images/setaazul.gif
119
0
0
/owb/images/amarelo.gif
119
0
0
Tabela 4. Comparativo com e sem cache (tempos em
segundos).
time
00:01:54
00:02:17
00:03:20
00:03:53
00:03:53
00:03:55
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 envio. Vamos considerar que a
curva de resposta da rede para todos os usuários é:
β(t) = 32000.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.
req
tempo
resp s/
CACHE
tempo
resp c/
CACHE
107
110
117
122
123
133
0,623
0,731
0,903
2,445
0,471
0,766
0,579
0,528
0,874
2,149
0,328
0,406
dif
-0,044
-0,203
-0,029
-0,296
-0,144
-0,360
%
-7,098
-27,759
-3,219
-12,105
-30,536
-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 re quisição.
Tabela 2. Análise do tempo de resposta sem cache (tempos
em segundos).
time req
00:01:54
00:02:17
00:03:20
00:03:53
00:03:53
00:03:55
tam tam
Pri Sec
dur
envio
Pri
107 12038 1416
110 912 15994
117 476
930
122 479 68299
123 1488 4607
133 989 11535
inst resp inst min inst resp
dur
inst cheg
inst
envio
Pri usu
envio Sec usu
req
envio Pri
Sec
U
Sec
U
temp
resp
0,376
0,044
114,000
114,203
114,579
114,579
114,623
0,623
0,029
0,015
0,015
0,047
0,031
0,500
0,029
2,134
0,144
0,360
137,000
200,000
233,000
233,000
235,000
137,203
200,859
233,296
233,281
235,375
137,232
200,874
233,311
233,328
235,406
137,232
200,874
233,311
233,328
235,406
137,731
200,903
235,445
233,471
235,766
0,731
0,903
2,445
0,471
0,766
Figura 11. Gráfico de Ganho, proporcional, do tempo de
resposta por requisição.
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
Pri Sec
dur
envio
Pri
dur
envio
Sec
inst
cheg
req
inst
min
envio
Sec
inst
resp
Sec
usu U
inst
min
envio
Pri
inst
resp
Pri usu
U
temp
resp
00:01:54
107 12038
1416
0,376
0,044 114,000 114,000 114,044 114,203 114,579
0,579
00:02:17
110
912
15994
0,029
0,500 137,000 137,000 137,500 137,500 137,528
0,528
00:03:20
117
476
930
0,015
0,029 200,000 200,000 200,029 200,859 200,874
0,874
00:03:53
122
479
68299
0,015
2,134 233,000 233,000 235,134 235,134 235,149
2,149
00:03:53
123 1488
4607
0,047
0,144 233,000 233,000 233,144 233,281 233,328
0,328
00:03:55
133
11535
0,031
0,360 235,000 235,000 235,360 235,375 235,406
0,406
989
Na Tabela 4 comparamos os tempos de resposta das
Tabelas 2 e 3 .
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
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 instante de início
transmissão e o instante 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 envio. E o processamento
dos servidores também é reduzido pelo controle do
instante 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.
6.1. 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.
6.2. 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. 13071312.
[6] L. Sha, X. Liu, Y. Lu and T. Abdelzaher, “Queueing model
based network server performance control”, in 23th IEEE RealTime System Symposium, 2003.
[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, 2003.
[8] Jean-Yves Le Boudec and Patric Thiran, Network Calculus:
A theory of Deterministic Queueing Systems for the Internet,
Springer-Verlag, Berlin – Germany, 2001.
[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. 2003.
[10] C.S. Chang, “On deterministic traffic regulator and service
guarantee: A systematic aproach by filtering”, IEEE
Transactions on Information Theory, Aug. 1998, pp. 1096-1107.
[11] R. Arawal and R. Rajan, “Performance bounds for
guaranteed and adaptive services”, IBM Technical Report RC
20649, Dec. 1996.
[12] J. Naudts, “Toward real-time meassurement of trafic
control parameters”, Computer Networks, 2000, pp. 34:157-167.
[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, 1992.
[14] Information Sciences Institute (USC), “Transmission
Control protocol”, Network Working Group RFC 793, EUA, Sep.
1981.
[15] M.Allman, V.Paxson and W.Stevens, “TCP Congestion
Control”, Network Working Group RFC-2581, EUA, Apr. 1999.
[16] G.McKinney, “TCP/IP State Transition Diagram”, Network
Working Group RFC-793, EUA, Feb. 2002.
[17] ITU-T Recomendação I.311, B-ISDN General Networks
Aspects, Genebra, 1991.
[18] Server Watch statistics (indicated by ISOC site), at
http://www.serverwatch.com/stats/netcraft/article.php/3349231 ,
May 2004.
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 1991.
[2] J. Lehoczky, “Real-Time Queueing Theory”, in 17th IEEE
Real-Time systems Symposium, 1996.
[3] J. Lehoczky, “Real-Time Queueing Network Theory”, in 18th
IEEE Real-Time systems Symposium, 1997.
[4] J. Lehoczky, “Using Real-Time Queueing Network Theory
To Control Lateness In Real-Time Systems”, ACM
SIGMETRICS’ 97, 1997, pages 158-168.