Ottone PDF

__________________________________________
Polticas de atendimento para servidores

Web com servios diferenciados baseadas
nas caractersticas das requisies
Ottone Alexandre Traldi
__________________________________________
SERVIO DE PS-GRADUAO DO ICMC-USP
Data de Depsito: 17/11/2008

Assinatura: ______________________________________
Polticas de atendimento para servidores Web com

servios diferenciados baseadas nas caractersticas
das requisies
Ottone Alexandre Traldi
Orientador: Prof. Dr. Marcos Jos Santana
Dissertao apresentada ao Instituto de Cincias Matemticas e de

Computao ICMC-USP, como parte dos requisitos para obteno do ttulo
de Mestre em Cincias rea Cincias de Computao e Matemtica
Computacional
USP So Carlos
Novembro de 2008
* Agradecimento ao CNPq pelo apoio parcial dado a este trabalho.
Dedico este trabalho a minha famlia e amigos,

que sempre estiveram presentes, dando-me a fora
e incentivo necessrios para conclu-lo com
sucesso.
Agradecimentos
Agradeo a Deus pela vida, sade e inspirao necessrios para a realizao deste trabalho.
Agradeo aos meus pais e irm pela motivao e apoio ao longo de toda a minha vida
acadmica.
Agradeo ao Buby por ter me ajudado a entender muito cedo o real valor da vida.
Agradeo ao Benedicto Geraldo Stoppa, Maria Aparecida Rosa Vianna, Fabio Vianna
Stoppa e Aparecida Poiatti Rosa Vianna por terem atuado como uma segunda famlia.
Agradeo ao Professor Doutor Marcos Jos Santana pela orientao cientfica desde os
tempos de graduao e Professora Doutora Regina Helena Carlucci Santana pela coorientao. Com ambos constru uma amizade que atravessa os muros da Universidade,
amizade que foi determinante em diversas conquistas pessoais.
Agradeo aos professores que participaram do meu exame de qualificao e da minha
defesa, pela leitura respeitosa dos meus textos, que contribuiu para o aprimoramento da
pesquisa.
Agradeo amiga Alessandra Kelli Barbato, com quem mantive uma parceria acadmica
da graduao ao Mestrado.
Agradeo ao amigo Marcelo Fila Pecenin, com quem mantenho uma parceria no esporte e
na vida h mais de 10 anos.
Agradeo Marjorie Mariano pelo apoio que chegou j no fim deste trabalho, mas de
extrema importncia.
Agradeo aos colegas e amigos com quem mantive contato durante o perodo do Mestrado
e que, de alguma forma, contriburam com a realizao deste trabalho: Jos Mrio Franzin,
Vilma Franzin, Rafael Belli, Mateus Pecenin, Umberto Pecenin, Ftima Pecenin, Luiz
Henrique Folster, Tiago Poiatti, Rosa Belli, Jos Armando Belli, Gustavo Belli, Adilson
Renesto, Maria ngela Renesto, Rodrigo Tortella, Gustavo Lazarini, Felipe Francisco, Murilo
Francisco, Felipe Ferreira, Victor Molina, Dirgenes Medeiros Jnior, Michel Lacombe, Luiz
Fernandes e Marlene Fernandes; Matheus Santos, Lucas Casagrande, Julio Estrella, Geraldo,
Valter e demais colegas do LaSDPC; Renato Pimentel, Cibele Russo, Daniel Silva, Daniel
Junqueira, Marcos Martins, Mrcia Sena, Felipe Ladeira, Andr Freire e demais amigos da
USP; Anne Carraretto, Leonardo Martins, Felipe Ricci e demais colegas do Unibanco; e toda
molecadinha do CERD.
Resumo
Este trabalho prope mecanismos de diferenciao de servios para

servidores Web, visando a melhorar o desempenho desses sistemas quando
so consideradas as caractersticas das requisies Web nas polticas de
atendimento. Optou-se por adotar o contexto do comrcio eletrnico para a
realizao das pesquisas, uma vez que esse ambiente um dos mais
impactados negativamente quando h um comportamento inadequado do
servidor em situaes de sobrecarga. Para isso, foi realizada uma
investigao das caractersticas das requisies Web tpicas do e-commerce,
para que tais caractersticas pudessem ser usadas como diretrizes para os
mecanismos e melhorar o desempenho dos servidores. Em seguida, foram
propostos um modelo de carga de trabalho e um modelo de simulao para a
realizao dos experimentos. Com isso, foi possvel avaliar os resultados
obtidos com a insero dos diversos mecanismos no Servidor Web com
Diferenciao de Servios (SWDS), um modelo de servidor cuja arquitetura
o torna capaz de fornecer servios diferenciados a seus usurios e aplicaes.
Foram propostos novos mecanismos de escalonamento de requisies bem
como novos mecanismos de controle de admisso.
Diversas simulaes
foram realizadas e os resultados obtidos mostram que a explorao das

caractersticas das requisies Web, alm de ser fundamental para um bom
entendimento do comportamento do servidor, possibilita a melhoria de
desempenho do sistema.
Abstract
This work proposes differentiated services mechanisms for Web servers,

aiming at improving their performance when the features of Web requests are
considered. The electronic commerce (e-commerce) context was adopted to
develop the researches once this environment is one of the most negatively
influenced when there is an inadequate behavior of the server under overload
situations. Thus, it was realized an investigation on the features of ecommerce Web requests, so that these features could be used both as
guidelines for the mechanisms and to improve the performance of the servers.
Afterwards, a workload model and a simulation model were proposed to
implement the experiments. Thus, it was possible to evaluate the results
obtained with the insertion of several mechanisms in the Web Server with
Differentiated Services (WSDS), a server model with an architecture that
makes it capable of supplying differentiated services to its users and
applications. New request scheduling mechanisms were proposed as well as
new mechanisms for admission control. Several simulations were realized
and the obtained results show that the exploration of the Web request
features, besides being fundamental for a good understanding of the server
behavior, makes possible to improve the system performance.
Lista de Figuras
2.1
As Camadas da Arquitetura TCP/IP ......................................................................
18
2.2
Exemplo de Requisio e Resposta HTTP ............................................................
25
3.1
Servidor Web com Diferenciao de Servios (SWDS) ........................................
39
4.1
Hierarquia das Tcnicas de Avaliao de Desempenho ........................................
47
4.2
Modelo simplificado do Servidor Web com Diferenciao de Servios (SWDS)
52
4.3
Modelo do Cluster de Servidores Web ..................................................................
52
5.1
Compradores Ocasionais (Menasc et al., 1999) ...................................................
57
5.2
Compradores Freqentes (Menasc et al., 1999) ...................................................
58
5.3
Mquina de Estados (Menasc et al., 1999) ...........................................................
58
5.4
Cenrio utilizado para a realizao de experimentos .............................................
61
6.1
Algoritmo Round-Robin .........................................................................................
72
6.2
Algoritmo WFQ .....................................................................................................
78
6.3
Algoritmo RR com CA por tamanho de fila ..........................................................
80
6.4
Algoritmo WFQ com CA por tamanho de fila e admisso seletiva .......................
86
Lista de Tabelas
2.1
Mtodos definidos pelo protocolo HTTP ...............................................................
26
2.2
Classes de cdigo de status das respostas HTTP ...................................................
26
5.1
Carga mdia gerada ao sistema por cada sesso ....................................................
59
5.2
Valores obtidos COM o recurso de cache no cliente .............................................
63
5.3
Valores obtidos SEM o recurso de cache no cliente ..............................................
64
6.1
Taxas de acerto em cache no cliente ......................................................................
68
6.2
Algoritmo Round-Robin .........................................................................................
71
6.3
Tempos mdios de CPU - considerando acertos em cach .................................... 74
6.4
Pesos obtidos para o WFQ (maximizando atendimentos) .....................................
74
6.5
Algoritmo WFQ (maximizando atendimentos) .....................................................
75
6.6
Pesos obtidos para o WFQ (maximizando vendas) ...............................................
76
6.7
Algoritmo WFQ (maximizando vendas) ................................................................
77
6.8
Algoritmo RR com CA por tamanho de fila ..........................................................
79
6.9
Probabilidade de cada estado gerar venda .............................................................
81
6.10
Algoritmo RR com CA seletivo ...........................................................................
82
6.11
Pesos para o WFQ com CA seletivo ....................................................................
84
6.12
Algoritmo WFQ com CA seletivo .......................................................................
85
6.13
Algoritmo WFQ com CA Seletivo (reduzindo fila) .............................................
87
Resultados obtidos .................................................................................................
91
7.1
Lista de Siglas e Abreviaturas

CA
CGI
CPU
DNS
FCFS
FTP
GPL
HTML
HTTP
ICMP
IETF
IP
OSI
PC
QoS
QoWS
RFC
RR
RSVAdap
RSVP
SLA
SMNP
SMTP
SSL
SWDS
TCP
UDP
URL
W3C
WFQ
WWW
Controle de Admisso
Common Gateway Interface
Central Processing Unit
Domain Name Service
First Come, First Served
File Transfer Protocol
General Public License
HyperText Markup Language
Hypertext Transfer Protocol
Internet Control Message Protocol
Internet Engineering Task Force
Internet Protocol
Open Systems Interconnection
Personal Computer
Quality of Service
Quality of Web Services
Request for Comments
Round-Robin
Reserva Adaptativa de Recursos
Resource Reservation Protocol
Service Level Agreement
Simple Network Management Protocol
Simple Mail Transfer Protocol
Secure Socket Layer
Servidor Web com Diferenciao de Servios
Transmission Control Protocol
User Datagram Protocol
Uniform Resource Locators
World Wide Web Consortium
Weighted Fair Queuing
World Wide Web
Sumrio
Introduo............................................................................................................................ 11
1.1 Contextualizao ...................................................................................................... 11
1.2 Motivao ................................................................................................................ 12
1.3 Objetivos.................................................................................................................. 14
1.4 Estrutura................................................................................................................... 14
Infra-estrutura da Web ......................................................................................................... 16
2.1 Consideraes Iniciais .............................................................................................. 16
2.2 A Internet ................................................................................................................. 16
2.2.1 Protocolos TCP/IP ............................................................................................. 17
2.2.2 A Arquitetura TCP/IP ........................................................................................ 17
2.3 A Organizao da Web............................................................................................. 20
2.3.1 Interaes Cliente-Servidor na Web................................................................... 21
2.4 Servidores Web ........................................................................................................ 22
2.5 Protocolo HTTP ....................................................................................................... 24
2.5.1 Mensagens de Requisio e Resposta................................................................. 24
2.5.2 HTTP 1.0 e 1.1 .................................................................................................. 27
2.5.3 Sesses HTTP ................................................................................................... 27
2.6 Consideraes Finais ................................................................................................ 28
Qualidade de Servio e Servidores ....................................................................................... 29
3.2 Limitaes da Internet Atual..................................................................................... 29
3.3 Conceitos Bsicos de QoS ........................................................................................ 31
3.4 Arquitetura para QoS................................................................................................ 33
3.4.1 Servios Integrados ............................................................................................. 33
3.4.2 Servios Diferenciados ...................................................................................... 36
3.5 Servios Diferenciados em Nvel de Aplicao......................................................... 38
3.5.1 Controle de Admisso........................................................................................ 40
3.5.2 Mecanismos de Diferenciao de Servios......................................................... 41
Avaliao de Desempenho ................................................................................................... 46
4.2 Tcnicas de Avaliao de Desempenho .................................................................... 46
4.2.1 Tcnicas de Aferio ......................................................................................... 47
4.2.2 Tcnicas de Modelagem .................................................................................... 47
4.3 Avaliao de Desempenho de Servidores Web ......................................................... 50
4.4 Avaliao de Desempenho do SWDS ....................................................................... 51
Carga de Trabalho................................................................................................................ 54
5.2 Comrcio Eletrnico................................................................................................. 54
5.3 Modelo da Carga de Trabalho................................................................................... 56
5.4 Cenrio Adotado ...................................................................................................... 60
5.5 Consideraes Finais.................................................................................................. 65
Resultados Obtidos .............................................................................................................. 67
6.2 Metodologia para Experimentos ............................................................................... 67

6.3 Resultados dos Experimentos ................................................................................... 70
6.3.1 Algoritmo Round-Robin (RR).............................................................................. 70
6.3.2 Algoritmo Weighted Fair Queuing (WFQ) .......................................................... 72
6.3.3 Algoritmo RR com Controle de Admisso por Tamanho de Fila........................ 79
6.3.4 Algoritmo WFQ com Controle de Admisso por Tamanho de Fila ...................... 83
Concluses........................................................................................................................... 88
7.1 Viso Geral .............................................................................................................. 88
7.2 Resultados e Contribuies....................................................................................... 89
7.3 Trabalhos Futuros..................................................................................................... 93
Referncias .......................................................................................................................... 95
1
Introduo
1.1 Contextualizao
A Internet hoje um dos mais importantes meios de comunicao, entretanto, no foi
projetada para o uso atualmente observado.
Inicialmente, os dados transferidos pela Internet ofereciam pouca carga, porm, com o
surgimento da World Wide Web (WWW), foi observado um grande aumento do trfego na
rede, pois ela passou a existir no apenas para fins de pesquisas, mas tambm para ser
utilizada para fins informativos, educacionais, de entretenimento e comerciais. Portanto,
ocorreram mudanas no apenas na quantidade do trfego da Internet, mas tambm na
natureza do mesmo (Xiao & Ni, 1999). Essa rede se tornou uma plataforma para aplicaes de
contedo dinmico, de comrcio eletrnico, telefonia, entre outras. No entanto, essas
aplicaes no requerem o mesmo tratamento, uma vez que no possuem as mesmas
caractersticas ou mesmas prioridades. Contudo, o servio oferecido pela Internet baseia-se
em um modelo de melhor esforo (best-effort), em que a rede procura transportar os dados
que lhe so confiados no menor tempo possvel, de preferncia sem erros ou inconsistncias,
mas sem dar s aplicaes garantias de que isso realmente ocorrer (Comer, 2000).
Uma das conseqncias da adoo desse modelo de melhor esforo o fato de que todo o
11
trfego tratado de maneira uniforme, sem nenhum tipo de diferenciao ou de priorizao.

Assim, quando h congestionamento, os pacotes presentes na rede so descartados sem
distino, independentemente das necessidades das aplicaes.
1.2 Motivao
Como as aplicaes no possuem as mesmas caractersticas ou mesmas prioridades,
essencial que a Internet fornea diferenciao de servios com diferentes nveis de QoS
(Quality of Service) para os diversos tipos de requisies (Kant & Mohapatra, 2000).
Uma das solues propostas atualmente pela comunidade cientfica baseia-se no aumento
sob demanda da largura de banda da rede, buscando minimizar o descarte de pacotes. Outra
abordagem adotada para a soluo do problema a insero de QoS na Internet por meio do
fornecimento de servios diferenciados, ou seja, o trfego no deve ser tratado de maneira
uniforme, sem nenhum tipo de diferenciao ou de priorizao. A insero de QoS na Internet
por meio dos Servios Diferenciados tem se mostrado uma excelente alternativa ao modelo de
melhor esforo em que o servio oferecido pela rede se baseia.
No difcil perceber que qualquer esforo para o fornecimento de QoS na Web no
poder ter sucesso se apenas mecanismos em nvel de rede e sistema operacional forem
utilizados, pois, em ltima instncia, so os servidores Web os responsveis pelo atendimento
das solicitaes dos usurios. Dessa forma, necessrio que os servidores Web tambm sejam
capazes de prover QoS, e, para isso, eles devem possuir polticas de atendimento que
consigam realizar a diferenciao de servios.
Esto disponveis diversas especificaes para a proviso de QoS sobre redes IP, com
destaque para as arquiteturas de Servios Integrados (IntServ) (Braden et al., 1994) e
Diferenciados (DiffServ) (Blake et al., 1998). Em nvel de aplicao, a utilizao de Servios
Diferenciados tem sido proposta como uma soluo eficiente para a proviso de melhores
12
servios. Isso pode ser observado por meio dos vrios trabalhos desenvolvidos na rea, entre
eles o de Cardellini et al. (2001), em que introduzido o conceito de Quality of Web Services
(QoWS), inspirado nos princpios de garantia de QoS em nvel de rede, definidos por Kurose
& Ross (2006).
Em Teixeira 2004, proposta uma arquitetura para um servidor Web que o torne capaz de
fornecer servios diferenciados a seus usurios e aplicaes, de acordo com suas
caractersticas de demanda. Esse modelo foi denominado Servidor Web com Diferenciao de
Servios (SWDS).
Foram includos alguns algoritmos de escalonamento no modelo SWDS visando tanto ao
balanceamento de carga entre os processos quanto diferenciao de servios. No primeiro
caso, destacam-se os algoritmos Round Robin e Shortest Queue First (Teixeira, 2004). No
segundo caso, destacam-se os algoritmos de Reserva de Recursos (Teixeira, 2004), Reserva
Adaptativa de Recursos (RSVAdap) (Traldi et al., 2006), Baseados em Prioridades (Estrito e
Adaptativo) (Teixeira et al., 2005) e Weighted Fair Queuing (WFQ) (Traldi et al., 2006).
Tambm foram includas, no modelo SWDS, algumas polticas de controle de admisso,
conforme Teixeira (2004). Essas polticas, levando em considerao a carga do sistema e a
classe a que pertence uma determinada requisio que chega ao servidor, decidem pela
aceitao ou pela rejeio da solicitao.
Os resultados fornecidos pelas polticas inseridas no modelo SWDS so promissores e
motivam a investigao de novas polticas de controle de servios. Entretanto, tanto as
polticas de escalonamento quanto as polticas de controle de admisso implantadas no
modelo no levam em considerao as caractersticas das requisies Web como parmetro na
tomada de decises. Essas polticas baseiam-se apenas na classe da tarefa, que definida pela
sua prioridade.
13
1.3 Objetivos
O objetivo central da pesquisa desenvolvida nesta dissertao de Mestrado foi avaliar a
possibilidade de melhorar o desempenho do modelo de Servidor Web com Diferenciao de
Servios (SWDS), quando so consideradas as caractersticas das requisies Web nas
polticas de atendimento. Entre os objetivos especficos, destacam-se:
Investigao das caractersticas das requisies Web;
Realizao de um detalhamento do modelo SWDS considerando-se os recursos

necessrios para a execuo das requisies Web;
Desenvolvimento de novas polticas de escalonamento que considerem o tipo das

requisies Web, e/ou alterao das j existentes;
Desenvolvimento de novas polticas de controle de admisso que considerem os tipos

das requisies Web, e/ou alterao das j existentes;
Insero das polticas desenvolvidas em um modelo de simulao do Servidor Web

com Diferenciao de Servios (SWDS).
1.4 Estrutura
No Captulo 2, ser apresentada a infra-estrutura da Internet, seus protocolos e principais
servios, com destaque para a Web.
No Captulo 3, ser abordado o tpico de diferenciao de servios na Internet, e sero
discutidas as limitaes do seu modelo atual e como a insero de qualidade de servio pode
tornar essa rede mais eficiente. A abordagem de servios diferenciados sobre redes IP e a
viabilidade de seu emprego em nvel de aplicao, particularmente em servidores Web, sero
destacados. Em seguida, ser apresentado o modelo para um Servidor Web com
14
Diferenciao de Servios, o SWDS. Ser descrita a sua arquitetura e tambm sero

discutidos alguns algoritmos de controle de admisso e diferenciao de servios.
No Captulo 4, sero apresentadas algumas das tcnicas de Avaliao de Desempenho
encontradas na literatura e mostrada a metodologia adotada neste trabalho, uma vez que
necessria a utilizao de algumas dessas tcnicas para avaliar o desempenho do modelo
SWDS com a insero de novas estratgias de atendimento.
No captulo 5, sero apresentados os critrios utilizados para a gerao da carga de
trabalho sinttica utilizada para alimentar o modelo do SWDS descrito no captulo anterior.
No captulo 6, sero apresentadas as estratgias propostas para melhorar o desempenho do
SWDS quando so consideradas as caractersticas das requisies Web na tomada de deciso
e os resultados obtidos.
Finalmente, no captulo 7, sero apresentadas as concluses e propostas de trabalhos
futuros.
15
2
Infra-estrutura da Web
2.1 Consideraes Iniciais

Neste captulo, dada uma viso geral da infra-estrutura da Internet e da World Wide Web,
sendo discutidas suas caractersticas e apresentados seus principais protocolos. Dada a
importncia desse elemento na rede, tambm realizada uma descrio das formas de
organizao e funcionamento dos servidores Web.
2.2 A Internet
A Internet pblica uma rede de computadores mundial, isto , uma rede que conecta
milhes de equipamentos de computao em todo o mundo. A maior parte desses
equipamentos formada por PCs tradicionais e pelos chamados servidores, que armazenam e
transmitem informaes, como pginas Web e mensagens por e-mail (Koruse & Ross, 2006).
Cada vez mais, equipamentos de computao esto sendo conectados Internet. Esses
equipamentos so chamados de hospedeiros ou sistemas finais.
Os sistemas finais, assim como a maioria dos outros componentes da Internet, operam
protocolos que controlam o envio e o recebimento de informaes na Internet. O TCP
16
(Transmission Control Protocol) e o IP (Internet Protocol) so os protocolos mais

importantes da Internet. Eles so conhecidos coletivamente como TCP/IP (Kurose & Ross,
2006).
2.2.1 Protocolos TCP/IP

O protocolo TCP/IP foi elaborado antes dos PCs, antes da proliferao das Ethernets e de
outras tecnologias de redes locais e, portanto, antes da Web. Esse protocolo surgiu da
necessidade de um protocolo de rede que fornecesse amplo suporte para aplicaes ainda a
serem definidas e permitisse, ao mesmo tempo, a interoperao de hospedeiros arbitrrios e
protocolos de camada de enlace (Kurose & Ross, 2006). O TCP/IP tornou-se um padro para
a interligao de computadores, tanto em redes locais quanto em longa distncia.
O TCP/IP usa a comutao de pacotes para realizar a comunicao entre hosts e pode ser
empregado sobre diferentes protocolos das camadas de enlace e fsica, de forma transparente
para as aplicaes. Outra caracterstica importante que o TCP/IP faz a entrega de dados de
forma mais confivel, utilizando para isso um mecanismo de acknowledgements entre a
origem e o destino final de uma comunicao.
As especificaes dos protocolos TCP/IP esto livremente disponveis na Internet, por
meio de RFCs (Request for Comments), promulgadas pela IETF (Internet Engineering Task
Force) (Postel, 1981c).
2.2.2 A Arquitetura TCP/IP

A arquitetura TCP/IP visualiza a rede de computadores em quatro camadas: acesso rede,
Internet, transporte e aplicao. Esse modelo de organizao equivalente s camadas do
modelo OSI (Reference Model of Open Systems Interconnection), que prope uma
organizao de arquitetura em sete camadas: aplicao, apresentao, sesso, transporte, rede,
17
enlace de dados e fsica (Tanenbaum, 2002). Essa equivalncia ilustrada pela Figura 2.1:
Figura 2.1: As Camadas da Arquitetura TCP/IP
Camada de Acesso Rede
A Camada de Acesso Rede, com o menor nvel de abstrao na arquitetura TCP/IP, usa
padres para conexo rede fsica. Ela utiliza vrios protocolos de acesso rede conforme o
tipo de rede disponvel, dando flexibilidade aos protocolos TCP/IP para que funcionem em
diversos meios fsicos.
Essa camada tambm faz o encapsulamento dos datagramas IPs nos frames usados na rede,
e converte os endereos IP para o formato da rede.
Camada de Internet
Nessa camada est estabelecido o protocolo IP (Internet Protocol) (Postel, 1981b), para
transporte no-confivel de mensagens, e o protocolo ICMP (Internet Control Message
Protocol) (Postel, 1981a), para controle da comunicao e informe de erros.
O protocolo IP prov um servio de rede no orientado conexo no requerendo troca
de informaes de controle iniciais (handshaking) para que uma comunicao seja iniciada
18
e providencia o roteamento da mensagem de um dispositivo para outro, em uma rede local ou

uma de longa distncia. As informaes so enviadas dentro de unidades de transferncia de
dados chamadas datagramas. Cada datagrama contm informaes necessrias para que possa
ser roteado de forma independente. O roteamento dos datagramas entre os hosts e a
fragmentao e remontagem dos datagramas ao passarem de uma camada para outra da pilha
TCP/IP so funes do protocolo IP.
O IP tambm responsvel pelo endereamento da rede. Cada host conectado Internet
possui um endereo distinto que utilizado pelos equipamentos da rede para encontrar o
caminho entre origem e destino.
Em suma, a camada de Internet permite a comunicao entre duas mquinas da rede.
Camada de Transporte
A Camada de Transporte permite a comunicao fim-a-fim entre dois hosts ou, mais
especificamente, entre processos executados em hosts conectados Internet. Essa camada
introduz o conceito de porta, um nvel de endereo adicional que identifica a aplicao na
mquina. Um endereo completo nesse nvel estabelecido por um par (host, port).
Nessa camada, esto definidos os protocolos TCP (Transmission Control Protocol) (Postel,
1981c) e UDP (User Datagram Protocol) (Postel, 1980).
O protocolo TCP fornece um servio confivel, garantindo que os dados cheguem sem
erros ao seu destino. um protocolo orientado conexo, ou seja, uma conexo lgica fim-afim estabelecida entre os dois hosts antes de a comunicao ser iniciada. O TCP tambm
realiza controle de fluxo para suas aplicaes e controle de congestionamento. O controle de
fluxo procura eliminar a possibilidade de o remetente saturar o destinatrio com o envio de
dados. O controle de congestionamento tenta regular os remetentes quando a rede encontra-se
congestionada.
19
O protocolo UDP no orientado conexo e oferece um servio no-confivel. O UDP

indicado para a construo de aplicaes cliente-servidor, principalmente, em redes locais
(Coulouris et al., 2000). Mensagens DNS (Domain Name Service), SNMP (Simple Network
Management Protocol) e algumas aplicaes de transmisso de udio e vdeo utilizam o
protocolo UDP.
Camada de Aplicao
Essa camada, de maior nvel de abstrao da pilha TCP/IP, define o conjunto de servios
manipulados por usurios. Nela esto os processos que utilizam os servios da camada de
transporte para a entrega dos dados, podendo escolher entre os servios oferecidos pelo
protocolo TCP ou protocolo UDP. nessa camada que so encontrados os servios de
TELNET, FTP, DNS, HTTP, SMTP, entre outros.
2.3 A Organizao da Web

O funcionamento da World Wide Web, iniciado na dcada de 1990, levou a Internet para os
lares e empresas de milhes de pessoas em todo o mundo. Ela serviu como plataforma para a
habilitao e disponibilizao de centenas de novas aplicaes. Com isso, gerou um grande
aumento no trfego da Internet, superando servios como FTP e e-mail. Com toda essa
popularidade, muitos usurios pensam que a Web a prpria Internet.
A Web considerada um sistema de hipertexto em escala global e uma grande plataforma
cliente-servidor. Por meio de browsers ou navegadores, os usurios acessam as informaes
que so armazenadas em servidores Web ou HTTP espalhados por todos os continentes
(Orfali et al., 1999).
A linguagem HTML e o protocolo HTTP so dois padres sobre os quais a Web funciona,
garantindo a sua portabilidade. A HTML (W3C, 1999a; W3C, 2000) o idioma universal
20
falado na Web. Suas tags descrevem a estrutura do documento, fornecem informaes sobre
sua formatao e estabelecem os links com outros documentos ou outros recursos da Web. O
protocolo HTTP utilizado para a comunicao entre os browsers e os servidores Web e
funciona sobre o TCP.
Uma caracterstica importante na organizao da Web seu sistema de nomenclatura
baseado em URLs (Uniform Resource Locators). Uma URL pode identificar pginas HTML,
um recurso ou um objeto qualquer existente na Internet. Sua estrutura composta por:
Protocolo: informa qual protocolo utilizado para o transporte dos dados;
Nome do servidor: um endereo IP ou nome de um host vlido;
Nmero da porta: onde um processo aguarda mensagens, no servidor;
Localizao do recurso: path ou caminho at o recurso.
2.3.1 Interaes Cliente-Servidor na Web

A Web considerada como uma grande plataforma cliente-servidor. Um servidor recebe as
requisies e, sendo consideradas vlidas, interpreta e retorna os objetos requisitados ao
cliente. Os objetos podem estar armazenados no servidor (Pginas Estticas) ou podem ser
gerados dinamicamente por um programa ou script invocado no servidor (Pginas
Dinmicas).
Pginas Estticas
Pginas estticas so pginas HTML fisicamente armazenadas nos servidores Web. Dessa
forma, os clientes, por meio de browsers, acessam um servidor Web, que por sua vez devolve
as pginas HTML para o usurio.
21
Segundo Casalicchio & Colajanni (2001), as Pginas Estticas podem ser classificadas
como estticas leves e disk-bound (pginas estticas geradas a partir de consultas ao banco de
dados). Esse tipo de classificao leva em considerao o consumo de recursos do sistema
causado pelas requisies HTTP. Em geral, considerado o consumo de CPU e o nmero de
operaes de I/O.
Pginas Dinmicas
O protocolo CGI (Common Gateway Interface), criado em 1995, trouxe uma maior
interatividade para a Web, permitindo iniciar uma aplicao do lado servidor, a partir de um
browser (Yeager & McGrath, 1996). No entanto, a independncia de plataforma ainda
garantida, pois toda a comunicao entre o browser e o servidor Web continua ocorrendo no
formato HTML.
O CGI recebe o pedido de execuo de aplicao via formulrios HTML, em que os
parmetros so digitados no browser pelo usurio, e, ento, faz a transferncia para o
programa apropriado, localizado no lado servidor. Esse programa envia uma Pgina Dinmica
como resposta. O usurio no tem a percepo de que a pgina foi gerada dinamicamente, a
partir de um processo iniciado sob o comando do servidor Web e apenas a recebe como se
fosse uma pgina esttica.
Segundo Casalicchio & Colajanni (2001), as requisies dinmicas podem ser classificadas
como dinmicas leves, CPU-bound e disk/CPU-bound.
2.4 Servidores Web

O servidor Web um elemento de grande importncia na rede, sendo responsvel pelo
atendimento aos usurios e deve ser projetado de maneira a atender o maior nmero de
requisies possveis, uma vez que, quando sobrecarregado, pode se tornar o gargalo do
22
sistema.
Um servidor Web est sempre em um lao infinito, aguardando por requisies dos
clientes. Os servidores atuais tratam as requisies que recebem segundo uma disciplina
FCFS (First Come, First Served), ou seja, mantida uma nica fila de espera em que cada
requisio aguarda o momento de ser atendida, de acordo com sua ordem de chegada.
Embora diferentes esquemas de controle de concorrncia possam ser implementados no
servidor, visando a agilizar o atendimento das requisies, este ocorre em geral de maneira
uniforme, sem considerar as particularidades e urgncia de cada tipo de requisio (Teixeira,
2004). A seguir, algumas formas de organizao dos servidores Web so apresentadas
brevemente:
Servidor Iterativo: trata as requisies pela ordem de chegada, sem nenhum tipo de
concorrncia;
Processo por Requisio: existe um processo principal que fica aguardando as

requisies. Ao chegar uma requisio, o processo principal cria uma cpia de si
mesmo e passa a esse filho a responsabilidade de tratar a requisio;
Pool de Processos: ao iniciar sua execuo, o servidor cria um nmero mnimo de

processos que ficam aguardando at que sejam convocados pelo processo dispatcher
para atenderem as requisies dos clientes;
Threads por Requisio: para cada requisio que chega criada uma nova thread
para trat-la;
Pool de threads: vrias threads so criadas quando o servidor Web iniciado. Elas
ficam aguardando pela chegada de requisies.
23
2.5 Protocolo HTTP

O HTTP (Hypertext Transfer Protocol), o protocolo de camada de aplicao da Web, est
implementado em dois programas: um programa cliente e um programa servidor. O programa
cliente e o programa servidor conversam pela troca de mensagens HTTP. Isso permite que o
cliente acesse os recursos armazenados no servidor Web. Todo o trfego de informaes entre
os browsers e servidores Web feito por mensagens HTTP. Os dados so representados
conforme o padro MIME (Multi-Purpose Internet Mail Extensions) (Borenstein, 1993).
O HTTP um protocolo do tipo stateless, isto , o servidor no guarda nenhuma
informao em relao ao estado dos clientes e, se uma falha na execuo da tarefa acontecer,
o cliente dever fornecer novamente todas as informaes necessrias para que a transao
possa ser realizada. Uma transao HTTP se desenrola segundo um mecanismo do tipo
requisio/resposta (request/reply).
2.5.1 Mensagens de Requisio e Resposta

As mensagens de requisio e resposta so definidas pelo protocolo HTTP em um formato
padro. Uma requisio formada tipicamente por:
Request line: linha que informa a ao a ser executada no servidor em que se encontra
o mtodo invocado (HTTP), a localizao do objeto no servidor e a verso do
protocolo HTTP utilizada;
Request header: uma ou mais linhas de cabealho contendo informaes do cliente

para informar ao servidor, por exemplo, os tipos de dados que ele capaz de aceitar;
Corpo da mensagem: opcional. utilizado quando dados adicionais do cliente devem

ser enviados ao servidor.
24
O protocolo HTTP determina que uma mensagem de resposta deve conter:
Response header: nesse cabealho encontrada a verso do protocolo e o cdigo de

status com o seu significado;
Request header: composto de vrios campos nos quais esto contidas informaes das
caractersticas do servidor e do objeto retornado ao cliente;
Corpo da mensagem: est contido o objeto retornado ao cliente, em geral um

documento HTML precedido por uma linha em branco.
Na Figura 2.2, mostrado um exemplo de Requisio e Resposta, em que um cliente

solicita (GET) o arquivo /doc/file.html do servidor www.nome.com, usando o protocolo
HTTP/1.1. O campo Accept, no cabealho, informa que o cliente capaz de receber textos em
formato HTML (text/html) e imagens em formato JPEG (image/jpeg). O tipo de browser do
cliente mostrado pelo campo User-Agent.
A resposta do servidor diz que a requisio foi bem sucedida (indicada pelo cdigo 200). O
tipo do servidor Web informado pelo campo Server, o campo Content-Type mostra que o
objeto retornado um documento HTML, e o campo Content-Lenght indica o nmero de
bytes do objeto que est sendo enviado. Aps a linha em branco, encontra-se o documento
solicitado:
Figura 2.2: Exemplo de Requisio e Resposta HTTP
25
O cliente pode enviar comandos ao servidor invocando um conjunto de mtodos definidos

pelo protocolo HTTP. A verso 1.0 do protocolo HTTP descrita na RFC 1945 (Berners-Lee
et al., 1996), na qual esto definidos os mtodos GET, HEAD e POST. No protocolo HTTP
1.1, descrito na RFC 2616 (Fielding et al., 1999), so acrescentados os mtodos OPTIONS,
PUT, DELETE, TRACE e CONNECT. Uma breve descrio desses mtodos pode ser vista
na Tabela 2.1:
Mtodo
Finalidade
GET
Faz a requisio do recurso especificado pela

URL
Envia ao servidor informaes do cliente,
geralmente, digitadas em formulrios HTML
Utilizado para obter informaes de um
recurso sem retorn-lo ao cliente. Testa a
validade de links, acessibilidade e a data da
ltima atualizao
Usado para obter opes de comunicao
disponveis. Permite ao cliente determinar os
requisitos associados ao recurso requisitado
Cria ou modifica um recurso no servidor
Faz a solicitao para apagar um recurso no
servidor, identificado na URL
Envia mensagem de teste ao servidor
Reservado para servidores proxy
POST
HEAD
OPTIONS
PUT
DELETE
TRACE
CONNECT
Tabela 2.1: Mtodos definidos pelo protocolo HTTP
Para informar o resultado da execuo realizada, o servidor retorna em sua resposta HTTP
um cdigo de status. Esse cdigo pode pertencer a uma das classes apresentadas na Tabela
2.2:
Classe
1xx
2xx
3xx
4xx
5xx
Descrio
Finalidade Informativa
Sucesso
Redirecionamento
Erro do cliente
Erro do servidor
Tabela 2.2: Classes de cdigo de status das respostas HTTP
26
2.5.2 HTTP 1.0 e 1.1

O protocolo HTTP 1.0 foi introduzido juntamente com a Web, em 1990. Nessa verso
inicial, ele nada mais era do que um modo simples de recuperar dados por meio da Internet.
Com o crescimento da Web, surgiram novos requisitos, e algumas de suas fraquezas foram
aparecendo.
A primeira delas que o HTTP 1.0 exige o estabelecimento de uma nova conexo TCP
para cada objeto solicitado. No incio, quando os documentos da Web eram constitudos
basicamente de texto, isso no chegava a ser um problema. Porm, atualmente, uma simples
pgina HTML pode conter dezenas de pequenas imagens. Isso tende a causar uma grande
sobrecarga no trfego da Internet, bem como nos servidores.
O protocolo HTTP 1.1, padronizado em 1999 pelo W3C (World Wide Web Consortium)
(W3C, 1999b), usa como padro o esquema de conexes persistentes, que permite que uma
mesma conexo TCP seja usada por vrias transaes HTTP, o que bem mais eficiente. O
HTTP 1.1 tambm permite fazer o pipelining de requisies. Nesse caso, vrias requisies
so enviadas em seqncia, sem aguardar pelas respostas. Isso bastante til, por exemplo,
para recuperar as imagens de uma pgina em ambientes que possuam uma alta latncia para o
estabelecimento de conexes TCP.
2.5.3 Sesses HTTP

O crescimento da fidelidade dos clientes em relao aos servios de banco e compras de
produtos na Internet pode aumentar muito a demanda aos servidores Web. Como
conseqncia, alm de haver um alto trfego na rede, devem existir garantias de atendimento
a essa demanda, o que torna difcil, no atual modelo da Internet (Wei et al., 2003), o
oferecimento de um bom nvel de qualidade a esses servios.
Tipicamente, um acesso ao servidor Web ocorre na forma de uma sesso, que constituda
27
de vrias requisies individuais de um mesmo cliente (Arlitt, 2000). Por exemplo: um pedido
de um cliente a um site comercial pode envolver uma requisio para selecionar o produto,
outra para o fornecimento das informaes necessrias, uma para estabelecer um acordo de
pagamento e uma ltima requisio para o recebimento de uma confirmao.
Assim, tanto para o cliente quanto para o site de vendas, necessrio que seja garantido o
atendimento de todas as requisies pertencentes a uma transao comercial, pois o sucesso
da transao obtido somente quando o atendimento de uma seqncia de requisies for
concludo.
2.6 Consideraes Finais

Neste captulo, foi abordada a infra-estrutura da Internet. Foi apresentada a arquitetura
TCP/IP, sendo mostradas as caractersticas e funes de cada uma de suas camadas. Foi
apresentado tambm um panorama geral da Web e discutida sua organizao atual como
plataforma de comunicao de clientes e servidores. Em seguida, foi realizado um breve
resumo a respeito do funcionamento dos servidores Web e suas formas de organizao. Por
fim, foi estudado o protocolo HTTP.
No prximo captulo, ser mostrada a necessidade de introduzir qualidade de servio na
Web. Essa necessidade surge dados os problemas e limitaes do modelo atual de servios
existente.
28
3
Qualidade de Servio e Servidores

Neste captulo, so discutidos os problemas atuais da Internet e como a insero de
qualidade de servio pode tornar essa rede mais eficiente. A abordagem de servios
diferenciados sobre redes IP e a viabilidade de seu emprego em nvel de aplicao,
particularmente em servidores Web, so destacados. Em seguida, apresentado o modelo para
um Servidor Web com Diferenciao de Servios, o SWDS. descrita a sua arquitetura e
tambm so discutidos alguns algoritmos de controle de admisso e diferenciao de servios.
3.2 Limitaes da Internet Atual

O trfego da Internet tem crescido enormemente nos ltimos anos, principalmente depois
do surgimento da Web. Esse crescimento no se deve apenas ao aumento do nmero de
usurios e aplicaes, mas tambm se d em decorrncia do aparecimento de novos tipos de
aplicaes, principalmente multimdia e de tempo real, que exigem da Internet uma resposta
para a qual ela no foi projetada (Teixeira, 2004).
A Internet capaz de fornecer um servio de melhor esforo (best-effort). A rede tenta
transportar os dados no menor tempo possvel e sem erros, mas no so dadas s aplicaes
29
garantias de que isso ocorrer. Esse modelo de melhor esforo decorrente da prpria
concepo do protocolo IP, no qual a Internet baseada, que foi projetado para ser simples,
eficiente e flexvel. Essa poltica funciona bem quando o trfego se mantm inferior
capacidade da rede, porm, em fases de congestionamento, podero ocorrer atrasos na entrega
dos pacotes e perda de dados na rede (Vasiliou & Lutfiyya, 2000).
Desde a criao das redes IPs, procura-se deixar a complexidade nas bordas da rede
(hosts), mantendo os elementos internos (roteadores) mais simples. Os roteadores fazem a
verificao dos endereos IPs dos datagramas em uma tabela de rotas, para determinar qual o
prximo salto (hop) a ser dado (Stardust, 1999b). Essa soluo tem sido suficiente para a
transmisso de dados convencionais e-mail, transferncia de arquivos e navegao na Web.
Entretanto, ela se revela inadequada para os novos tipos de aplicaes encontradas na rede,
tais como: aplicaes multimdia, telefonia sobre IP, vdeo-conferncia, transmisso de rdio
e TV (Teixeira, 2004). Essas aplicaes possuem certos requisitos que a Internet no est
preparada para atender. As aplicaes multimdia, por exemplo, necessitam de grande largura
de banda e suportam pequenas perdas de pacotes. J para a telefonia sobre IP, so exigidos
requisitos de temporizao. Alm disso, a Web tem se tornado uma plataforma de negcios,
exigindo alta confiabilidade e disponibilidade do meio de transmisso, cujos usurios esto
dispostos a pagar mais por um servio mais previsvel e de melhor qualidade (Xiao & Ni;
1999).
primeira vista, o problema da Internet poderia parecer de largura de banda, ou seja,
supondo-se que fosse possvel acrescentar capacidade de transmisso indiscriminadamente
rede, teoricamente seria possvel acolher todo o trfego existente, satisfazendo a todos.
Porm, alm de economicamente invivel, no a soluo adequada para alguns casos, pois,
para algumas aplicaes, o ponto crtico no est na quantidade de largura de banda
disponvel, mas sim na latncia de transmisso (Teixeira, 2004).
30
Sendo assim, faz-se necessrio realizar um gerenciamento da largura de banda disponvel,

diferenciando o trfego que passa pelos elementos internos da rede, e, dessa forma, fornecer
classes ou nveis de servio diferenciados aos usurios e aplicaes (Xiao & Ni; 1999).
3.3 Conceitos Bsicos de QoS

A idia de aplicar Qualidade de Servio em redes IP surgiu da necessidade de minimizar os
problemas existentes nesse tipo de rede. Fornecer a um elemento da rede a garantia de que
seus requisitos de trfego e servio sero satisfeitos a principal funo da Qualidade de
Servio (QoS) (Stardust, 1999b). Em outras palavras, a capacidade da rede de prover servio
de encaminhamento de dados de forma consistente e previsvel.
A QoS obtida por meio da cooperao de todos os nveis da rede, desde o topo at a base,
bem como de todos os elementos da rede fim-a-fim. Qualquer garantia de QoS ser to forte
quanto o mais frgil elemento do caminho da transmisso de dados na rede (Stardust, 1999b).
Os mecanismos de QoS, conforme a demanda das aplicaes, administram a largura de
banda existente na rede. Habilitar QoS para as aplicaes de alta prioridade no deve implicar
na anulao das aplicaes menos prioritrias.
A QoS pode ser descrita de forma absoluta ou de forma relativa. Uma especificao de
QoS em termos absolutos fornece mtricas a serem cumpridas, relacionadas, em geral, ao
atraso ou perda de pacotes. J a QoS relativa faz diferenciao de servios, garantindo que
uma aplicao em uma classe de mais alta prioridade nunca receba um servio pior que o de
qualquer classe inferior (Zhao et al., 1999).
Duas caractersticas importantes dentro do tema de QoS so identificadas: garantia de
desempenho e diferenciao de servios (Zhao et al., 1999). A primeira caracterstica est
relacionada ao gerenciamento de largura de banda, perda de pacotes, atraso e jitter (variao
do atraso). A segunda est relacionada com o fornecimento de nveis de QoS distintos para
31
diferentes aplicaes.
Em Koruse & Ross (2006), so estabelecidos alguns princpios para o fornecimento de
garantias de qualidade de servio:
Princpio 1: a classificao de pacotes permite que um roteador faa distino de

pacotes pertencentes a diferentes fluxos de trfego;
Princpio 2: desejvel fornecer um certo grau de isolamento entre os fluxos de

trfego, de modo que um fluxo no seja adversamente afetado por outro mal
comportado;
Princpio 3: ao fornecer isolamento de fluxos, desejvel que se usem os recursos da

maneira mais eficiente;
Princpio 4: necessrio um processo de aceitao de chamada pelo qual os fluxos

declarem suas exigncias de QoS e, em seguida, sejam admitidos ou no na rede.
Outro componente importante para a determinao do modelo de QoS a ser fornecido aos
usurios diz respeito ao tipo de trfego que as aplicaes geram e qual o comportamento
esperado da rede para que elas funcionem corretamente. Com relao ao tipo de trfego, as
aplicaes podem ser classificadas em Braden et al. (1994):
Aplicaes de tempo real (no elsticas): exigentes no que diz respeito ao tempo de
transporte dos seus dados (caractersticas rgidas de temporizao). Essa classificao
pode ainda ser quebrada em duas categorias:
o Aplicaes tolerantes: so aquelas que toleram variaes no atraso (jitter)

causadas pela rede;
o Aplicaes intolerantes: as variaes no atraso so inaceitveis;
32
Aplicaes elsticas (no tempo real ou adaptveis): para esse tipo de aplicao, a
recepo correta dos dados mais importante do que a sua apresentao em uma taxa
constante. Exemplos de aplicaes elsticas so: correio eletrnico, transferncia de
arquivos, consultas interativas a informaes (como na Web) e aplicaes
cliente/servidor tradicionais.
3.4 Arquitetura para QoS

Na Internet, destacam-se dois tipos bsicos de arquiteturas para QoS (Stardust, 1999b;
Zhao et al., 1999):
Baseada na Reserva de Recursos: os recursos da rede so atribudos s aplicaes

segundo suas demandas de QoS e submetidos poltica de gerenciamento de largura
de banda. Essa a abordagem empregada pela arquitetura de Servios Integrados
(IntServ);
Baseada na Priorizao: o trfego na rede classificado de acordo com suas

caractersticas de demanda e recebe os recursos segundo a poltica de gerenciamento
vigente. As classes de trfego mais exigentes recebem tratamento preferencial,
abordagem adotada pela arquitetura de Servios Diferenciados (DiffServ).
3.4.1 Servios Integrados

A idia principal da arquitetura IntServ a de reserva de recursos. As aplicaes precisam
encontrar um caminho at o receptor que satisfaa as demandas de QoS e realizar a reserva
dos recursos necessrios ao longo do mesmo, antes do incio da transmisso dos dados. Esse
sistema exige dos roteadores a manuteno de informaes de estado para cada fluxo de
33
dados, levando complexidade para o ncleo da rede. Apesar de fornecer a maior QoS possvel
em uma rede baseada nos protocolos TCP/IP, pois realiza a reserva de recursos fim-a-fim,
representa uma ruptura com a abordagem tradicionalmente empregada nas redes IP. Seu
objetivo fornecer um servio mais prximo possvel da abstrao de circuitos virtuais, em
uma rede comutada por pacotes, como a Internet.
So definidas duas classes de servio na arquitetura IntServ, alm do tradicional modelo de
melhor esforo encontrado nas redes IP: Servio Garantido e Servio de Carga Controlada:
Servio Garantido: garantida a disponibilidade de largura de banda e fornecido um

limite superior para o atraso de comunicao. As aplicaes que possuem requisitos
estritos de tempo real podem utilizar esse servio;
Carga Controlada: esse servio oferece uma nica funo. As aplicaes que fazem
reserva de QoS usando os servios de carga controlada recebem um servio
equivalente ao servio fornecido pelo modelo de melhor esforo em condies de
sobrecarga leve. No garantido um atraso mximo, apenas um limiar probabilstico,
assim como no assegurado que no haver perda de pacotes. Os servios de carga
controlada so projetados para aplicativos que podem tolerar uma quantia razovel de
perda e retardo de pacotes, tal como aplicaes de udio e videoconferncia.
Protocolo RSVP
Para a arquitetura IntServ, deve ser realizada a reserva de recursos ao longo do caminho
entre o transmissor e o receptor antes de a transmisso de dados ser iniciada. Em princpio, a
reserva de recursos pode ser executada por qualquer protocolo que seja compatvel com o
modelo, mas na prtica o protocolo RSVP (Resource Reservation Protocol) (Braden et al.,
1997) o padro.
34
O protocolo RSVP considerado como uma das solues mais complexas em suporte ao
fornecimento de QoS (Stardust, 1999a). um protocolo de controle e sinalizao que atua na
camada de rede.
Algumas caractersticas importantes do protocolo RSVP so:
O RSVP faz reservas tanto para transmisses unicast como para transmisses
multicast;
O RSVP faz reservas somente para fluxos unidirecionais. Para conseguir reservas
bidirecionais, deve solicitar duas reservas unidirecionais distintas;
No RSVP, o receptor dos dados o responsvel por iniciar e manter as reservas para
os fluxos;
O estado das reservas no RSVP segue a abordagem soft-state, ou seja, expira aps um
certo perodo de tempo, sendo necessrio renov-lo periodicamente;
O RSVP no um protocolo de roteamento. Ele utiliza as rotas escolhidas pelo

protocolo de roteamento adotado;
O RSVP permite fazer o gerenciamento de fluxo em uma granulosidade bem fina,

conseguindo-se altos nveis de QoS na Internet;
Para conseguir QoS, necessrio que todos os roteadores ao longo do caminho dem
suporte ao RSVP, mantendo informaes de estado e escalonando pacotes para cada
fluxo de dados.
importante destacar que o RSVP leva uma complexidade significativa para o ncleo da
Internet, uma vez que exige que os roteadores gerenciem informaes relativas aos fluxos de
35
dados que passam por eles. Isso leva a um rompimento com o modelo tradicional de servios
da Internet, que sempre procurou deixar a complexidade nas bordas da rede. Portanto, a
abordagem de servios integrados mais bem empregada em um ambiente de rede local,
fornecendo uma QoS para aplicaes de um domnio.
3.4.2 Servios Diferenciados

A abordagem DiffServ baseia-se na idia de agregao de fluxos em umas poucas classes
de servio (Magalhes & Cardozo, 1999). Realiza a marcao de pacotes nos pontos de
ingresso na rede de forma distinta, o que permite que os mesmos sejam tratados internamente
de maneira diferenciada, segundo suas classes de servio. Esse mtodo, ao contrrio do
modelo IntServ, que exige complexidade por todo percurso da entrega de dados, mantm a
complexidade nas bordas da rede, conservando um dos princpios bsicos do projeto da
Internet.
Baseado em um esquema de prioridades relativas, o modelo Diffserv garante um melhor
tratamento ao trfego gerado pelas aplicaes com maior prioridade (Xiao & Ni, 1999). Para
isso, feita uma classificao de pacotes, para que eles sejam tratados de maneira
diferenciada no interior da rede.
Os pacotes so classificados modificando-se a definio do layout do octeto Type-ofService do cabealho do protocolo IPv4 (ou o campo Traffic Class do IPv6). Utilizando um
campo do prprio datagrama IP para a marcao de pacotes, no h necessidade de um
protocolo para o DiffServ, sendo somente preciso que o roteador examine essa informao
para distinguir os pacotes entre um certo nmero de classes de servio pr-definidas, dando a
eles o tratamento conveniente.
Atualmente so definidas na arquitetura de servios diferenciados duas classes de servios
principais, Encaminhamento Garantido e Encaminhamento Expresso, que so abordadas a
36
seguir (Kilkki, 1999):
Encaminhamento Garantido: a classe de servio Encaminhamento Garantido (Assured

Forwarding - AF) oferece um servio mais confivel do que o de melhor esforo.
garantido um tratamento preferencial ao trfego, mas sem oferecer limites superiores
para o atraso e jitter. O trfego dividido em classes com diferentes nveis de
precedncia de descarte. Dessa forma, o nvel de garantia de encaminhamento de um
pacote depende da quantidade de recursos alocados para a classe, a carga atual da
classe e, em caso de congestionamento, o nvel de descarte do pacote;
Encaminhamento Expresso: o servio Encaminhamento Expresso (Expedited

Forwarding - EF) ou Premium Service define garantias mais rgidas de QoS para
aplicaes muito sensveis a variaes de caractersticas temporais da rede. Ele pode
ser utilizado para implementar um servio com pouco atraso, pouca variao do atraso
(jitter) e largura de banda garantida. Para os usurios, esse servio parece com uma
linha privativa virtual. Com o servio de Encaminhamento Expresso, os pacotes da
classe Premium so colocados em uma fila de maior prioridade e sempre so os
primeiros a serem encaminhados. Alm disso, sempre evitado que os pacotes com
esse contrato sejam descartados.
Service Level Agreements
Um componente central dos Servios Diferenciados o Service Level Agreement (SLA) acordo de nvel de servio. O SLA um contrato de servio entre um cliente e um provedor
de servios que especifica os detalhes da classificao de trfego e o servio de
encaminhamento que um cliente deve receber.
O provedor de servios precisa garantir que o trfego de um cliente, com o qual ele tem um
SLA, obtenha a QoS contratada. Assim, a administrao da rede do provedor de servios
37
precisa definir os planos de ao dos servios apropriados e medir o desempenho da rede para
garantir o desempenho de trfego combinado.
As polticas de QoS podem ser aplicadas baseadas em nmeros de portas, data e hora,
endereos de origem e destino, ou em outras informaes que estejam contidas no trfego
(Stardust, 1999b). Alm disso, podem ser especificados procedimentos de tarifao e
cobrana, servios de criptografia e autenticao, procedimentos de renegociao dos
parmetros do SLA, entre outros (Vasiliou & Lutfiyya, 2000).
3.5 Servios Diferenciados em Nvel de Aplicao

Como j citado anteriormente, qualquer esforo para o fornecimento de QoS na Web no
poder ter sucesso se apenas mecanismos em nvel de rede e sistema operacional forem
utilizados, pois, em ltima instncia, so os servidores Web os responsveis pelo atendimento
das solicitaes dos usurios. Dessa forma, para que haja fornecimento de QoS, necessria a
cooperao de todos os elementos do sistema.
Infelizmente, a grande maioria dos servidores atuais ainda trata todas as solicitaes
igualmente, conforme uma disciplina FCFS (First-Come First-Served). Dessa forma, no
possvel haver uma proviso de QoS na Web, uma vez que, para isso, fundamental que esses
servidores sejam providos de polticas de atendimento que consigam realizar a diferenciao
de servios.
Esse um importante assunto a ser tratado, pois a Web tem sido fortemente utilizada como
um meio para a conduo de negcios, cujo elemento central o servidor Web.
Em Teixeira (2004), proposta uma arquitetura para um servidor Web que o torne capaz
de fornecer servios diferenciados a seus usurios e aplicaes, de acordo com suas
caractersticas de demanda. A Figura 3.1 descreve a arquitetura proposta, que composta
pelos seguintes mdulos: um Classificador, um mdulo de Controle de Admisso e um cluster
de processos ou servidores Web:
38
Figura 3.1: Servidor Web com Diferenciao de Servios (SWDS)
O Classificador o elemento responsvel por receber as requisies que chegam ao

sistema e subdividi-las em classes de servio, segundo critrios preestabelecidos. Aps essa
fase, a nova requisio entra no sistema em uma determinada categoria e recebe um
tratamento condizente com a classe qual pertence.
O Controle de Admisso recebe as requisies j classificadas e gerencia a sua aceitao
pelo servidor, levando em conta as polticas de atendimento vigentes e as informaes da
carga de trabalho do sistema. Caso o servidor esteja sobrecarregado, uma requisio poder
ser rejeitada (descarte) ou poder ter suas exigncias de qualidade de servio relaxadas
(negociao), a fim de que possa ser aceita em outra classe de prioridade (Estrela et al., 2006).
Aps ser admitida no sistema, a requisio atribuda a um dos ns do cluster de
servidores Web, sendo atendida conforme o algoritmo de escalonamento ou diferenciao de
servios vigente. Aps a concluso do processamento, os resultados so retornados ao cliente
que originou a solicitao.
Para o modelo SWDS, no suposta nenhuma plataforma de hardware ou sistema
39
operacional especficos. Os ns do cluster so considerados como servidores Web

convencionais, compostos de CPU, disco e interface de rede.
Apesar de ser formado por servidores Web, o cluster do modelo pode ser abstrado para
processos ou at mesmo CPUs em um computador paralelo, pois no h exigncias de que a
arquitetura seja necessariamente formada por mquinas dispostas em um sistema distribudo.
Uma caracterstica importante do modelo SWDS a sua flexibilidade, pois admite vrios
tipos de mecanismos de controle de admisso e diferenciao de servios.
3.5.1 Controle de Admisso

Em funo das caractersticas da carga de trabalho da Web, o Controle de Admisso um
mecanismo essencial em servidores. A carga que atinge os servidores pode, de modo
imprevisvel, sobrecarregar o sistema e, dessa forma, comprometer toda a diferenciao de
servios realizada para atingir os nveis de QoS pretendidos. Portanto, o principal objetivo do
mdulo de controle de admisso do servidor SWDS fazer com que a carga do sistema seja
sempre mantida dentro de nveis aceitveis. Para isso, so consideradas as informaes da
carga do sistema, alm das polticas de atendimento.
Mecanismos de Controle de Admisso

Foram implementados, por Teixeira (2004), trs mecanismos de controle de admisso no
SWDS: Tamanho das Filas, Tempo de Resposta e Utilizao do Sistema.
O mecanismo que considera o tamanho das filas impe um tamanho mximo para as filas
dos servidores do cluster, recusando novas requisies quando esse limite for atingido. A
principal funo desse mecanismo manter a carga do sistema em nveis aceitveis, mas ele
no oferece garantias de QoS aos clientes.
O mecanismo baseado no tempo de resposta preocupa-se em manter o tempo de resposta
das requisies de alta prioridade abaixo de um certo limiar. Seu funcionamento consiste em
40
aceitar as requisies de alta prioridade sempre que possvel e somente admitir aquelas de
baixa prioridade quando a carga estiver abaixo do limiar pr-determinado. Com esse
mecanismo, evita-se que o tempo de resposta apresente picos devido aos aumentos na carga
de trabalho, conseguindo-se uma maior estabilidade no sistema.
O mecanismo que leva em considerao a utilizao do sistema emprega uma mdia
exponencialmente ponderada da utilizao do cluster para o controle de admisso, a qual pode
ser ajustada conforme valores atuais ou o histrico da carga do sistema. Esse mecanismo
consegue, de forma rigorosa, manter a utilizao do servidor SWDS dentro do limiar
especificado, o que permite oferecer um tratamento mais justo a todas as classes de
requisies.
So encontrados na literatura outros trabalhos que consideram a presena do Controle de
Admisso fundamental para que os servidores ofeream qualidade de servio, como os
trabalhos de Cardellini et al. (2001), Lee et al. (2002) e Andreolini et al. (2004).
As polticas de controle de admisso podem ainda considerar outros parmetros como base
para a tomada de decises, como as caractersticas das requisies Web, por exemplo.
3.5.2 Mecanismos de Diferenciao de Servios

Com o objetivo de realizar o balanceamento de carga e prover diferenciao de servios no
Servidor Web com Diferenciao de Servios (SWDS), foram propostos em Teixeira (2004) e
Traldi et al. (2006) alguns algoritmos de diferenciao de servios. Esses algoritmos
especificam a forma de compartilhamento do cluster de servidores Web entre as classes de
servio. Eles determinam qual categoria de clientes ter preferncia no atendimento,
realizando a diferenciao de servios propriamente dita.
Em Teixeira (2004) so propostos algoritmos de diferenciao de servios baseados em
Reserva de Recursos e algoritmos baseados em Prioridades, alm dos algoritmos que
objetivam apenas o balanceamento de carga.
41
Os algoritmos baseados na Reserva de Recursos fazem a subdiviso do cluster de

servidores Web do SWDS em parties. feita ento uma associao dessas parties s
classes de servio. Com isso, uma parcela da capacidade de processamento do servidor
reservada para cada classe de requisies. Nos algoritmos baseados em Prioridades, a
diferenciao realizada atribuindo-se prioridades s requisies presentes nas filas do
cluster.
Como algoritmo baseado em Reserva de Recursos, foi apresentado em Teixeira (2004) o
RSV (Algoritmo de Reserva de Recursos). O algoritmo RSV subdivide os ns do cluster do
SWDS em parties e associa cada partio a uma classe ou um conjunto de classes de
servio, de maneira esttica. Esse algoritmo apresenta bons resultados quando a carga a que o
sistema submetido previamente conhecida, uma vez que o particionamento dos recursos
realizado de maneira no dinmica. Entretanto, para ambientes onde a carga varia, como no
caso da Web, no aconselhada a sua utilizao.
Como algoritmos baseados em Prioridades, so propostos em Teixeira (2004) um
Mecanismo de Prioridades Rigoroso e um Mecanismo de Prioridades Adaptativo.
O Mecanismo de Prioridades Rigoroso exige que o atendimento das requisies siga uma
disciplina de prioridades rgida, ou seja, as requisies de prioridade inferior somente sero
atendidas quando no houver nenhuma requisio de prioridade superior aguardando na fila.
Esse mtodo garante que as requisies de maior prioridade sempre recebam atendimento
preferencial. Entretanto, dependendo da carga a que o sistema submetido, pode ocorrer
negao de servio s requisies de menor prioridade.
A fim de evitar o monoplio do sistema por parte das requisies de alta prioridade, foi
proposto o Mecanismo de Prioridades Adaptativo. Com o mecanismo adaptativo, pode-se
atribuir maior ou menor importncia s classes de maior prioridade por meio da utilizao de
um parmetro k, denominado look-ahead, que determina o nmero mximo de posies da
42
fila de espera que sero percorridas a partir do incio, procura de requisies de uma
determinada prioridade. Caso no encontre nenhuma requisio do tipo especificado, o
algoritmo ser repetido para o nvel de prioridade imediatamente inferior. Quanto maior o
valor de k, melhor ser o tratamento dado s requisies de maior prioridade. Uma
caracterstica indesejvel desse mtodo que, dependendo do valor de k, uma requisio da
classe de menor prioridade pode esperar por muito tempo na fila para ser atendida, mesmo
que o tempo de processamento necessrio para o seu atendimento seja muito pequeno se
comparado ao tempo necessrio para o atendimento das requisies de maior prioridade. Isso
leva a um aumento no tempo mdio de espera na fila.
Em Traldi et al. (2006) apresentado o algoritmo de Reserva Adaptativa de Recursos
(RSVAdap). Esse algoritmo foi desenvolvido com o intuito de adaptar o funcionamento do
algoritmo RSV para ambientes em que a carga varivel. O RSVAdap aloca os ns do cluster
nas classes de usurios (requisies) sob demanda, segundo a carga de trabalho vigente. Para
a alocao dos recursos, o algoritmo se baseia no nmero de requisies de cada classe
presente no sistema no momento da anlise e no nvel de diferenciao pretendido. Definido o
particionamento do cluster, o algoritmo RSVAdap, que atua no mdulo escalonador do
modelo SWDS, distribui as requisies pertencentes a uma determinada classe aos ns
reservados a ela, utilizando o conceito de Shortest Queue First (SQF). Uma caracterstica
importante do algoritmo RSVAdap que, havendo requisies de uma determinada classe no
sistema, independentemente de seu nvel de prioridade, o algoritmo realiza a reserva de pelo
menos um n do cluster a essa classe, impedindo que seja negado atendimento a essas
requisies. Isso pode levar, em algumas situaes, ao desperdcio de recursos do cluster e
tambm diferenciao de servios inadequada.
Em Traldi et al. (2006) foi realizada a adaptao para o nvel de aplicao do algoritmo
Weighted Fair Queuing (WFQ) projetado para o nvel de rede. Esse algoritmo baseado em
43
Prioridades e utiliza a idia de dividir a capacidade de processamento dos ns do cluster entre

as classes de requisies de acordo com os pesos que so atribudos s classes. Como
parmetro para o escalonamento, o algoritmo tambm considera o tempo de processamento
necessrio para atender uma requisio, priorizando requisies menos custosas. Por no
realizar reserva de recursos, esse mecanismo evita a subutilizao do sistema.
Em Traldi (2005) apresentado o algoritmo WFQ Adaptativo. Esse algoritmo baseia-se no
funcionamento do algoritmo WFQ, entretanto tambm apresenta bons resultados para
ambientes em que a carga varivel.

Neste captulo, foram apresentadas as limitaes da Internet atual, que motivam a insero
de QoS nessa rede. Foram apresentados tambm os conceitos bsicos de QoS, bem como as
arquiteturas utilizadas para a proviso de qualidade de servio.
Em seguida, foi discutida a importncia de ter diferenciao de servios tambm em nvel
de aplicao e apresentada a arquitetura do Servidor Web com Diferenciao de Servios, o
SWDS. Foram tambm mostradas algumas polticas de controle de admisso e polticas de
diferenciao de servios. Essas polticas so fundamentais para que o SWDS consiga
fornecer qualidade de servio no atendimento s requisies Web.
Os resultados fornecidos pelas polticas descritas motivam a investigao de novas
estratgias de controle de servios. No entanto, essas polticas no levam em considerao as
caractersticas das requisies Web na tomada de decises, baseando-se apenas na classe da
tarefa, que definida pela sua prioridade.
Para avaliar o desempenho do modelo de Servidor Web com Diferenciao de Servios
(SWDS) quando so consideradas as caractersticas das requisies Web nas polticas de
atendimento, necessria a utilizao de alguma tcnica de Avaliao de Desempenho.
44
No prximo captulo, sero apresentadas algumas das tcnicas de Avaliao de

Desempenho encontradas na literatura e mostrada a metodologia adotada neste trabalho.
45
4
Avaliao de Desempenho

Na computao, h sempre a preocupao em obter informaes relevantes a respeito dos
sistemas. Por meio dessas informaes, obtidas no processo de avaliao de desempenho,
pode-se verificar se o sistema avaliado est realizando bem as tarefas para as quais foi
designado.
Assim, para analisar os mecanismos de diferenciao desenvolvidos para o SWDS, foram
utilizadas tcnicas de avaliao de desempenho.
A seguir, so apresentadas algumas dessas tcnicas e mostrada a metodologia adotada
neste trabalho.
4.2 Tcnicas de Avaliao de Desempenho

Para a avaliao de desempenho de um sistema, pode-se utilizar uma das tcnicas que se
encontram distribudas em dois grandes grupos: Tcnicas de Aferio e Tcnicas de
Modelagem (Santana, 1990a; Santana, 1990b). As tcnicas de Aferio mais utilizadas so:
construo de Prottipos, utilizao de Benchmarcks e Coleta de Dados. Quanto
46
modelagem, as tcnicas de Redes de Petri, Statecharts e Rede de Filas so as mais utilizadas.

A hierarquia das Tcnicas de Avaliao de Desempenho mostrada na Figura 4.1:
Figura 4.1: Hierarquia das Tcnicas de Avaliao de Desempenho
4.2.1 Tcnicas de Aferio

Tcnicas de Aferio so aplicadas principalmente na avaliao de sistemas j existentes
ou em fase final de desenvolvimento (Santana et al., 1997).
No caso da aferio de um sistema, so utilizados monitores de hardware ou de software
(Jain, 1991; Hofmann et al., 1994). necessrio que haja uma grande preocupao em no
alterar o funcionamento natural do sistema durante a experimentao prtica.
4.2.2 Tcnicas de Modelagem

Um modelo uma descrio do sistema, constituindo uma abstrao do sistema, em que
so incorporadas as suas caractersticas fundamentais vistas sob uma tica especfica.
Uma das tarefas mais difceis no processo de modelagem decidir quais elementos do
sistema devem ser includos no modelo. Assim, ao modelar um sistema, deve-se procurar
abstrair quais de seus elementos so importantes na resoluo de uma dada questo particular
e quais relaes entre esses elementos so pertinentes resoluo do modelo. Dessa forma,
podem-se ter vrias descries (modelos) de um sistema, cada uma mais adequada resoluo
de um problema particular (Soares, 1990) - isto constitui as vrias vises que se tem do
sistema.
Freqentemente os modelos so classificados de acordo com os mtodos utilizados na
47
obteno dos resultados numricos (medidas de desempenho). Assim, modelos analticos so

definidos como modelos cuja estrutura formada por uma srie de equaes matemticas, por
meio dos quais o comportamento do sistema pode ser obtido pela atribuio dos valores aos
parmetros do modelo e pela soluo das equaes. J os modelos para simulao podem ser
definidos como aqueles representados por uma estrutura matemtica/lgica, que pode ser
exercitada de forma a imitar o comportamento do sistema por meio de programas
computacionais, por exemplo. Com o experimento (simulao), vrias observaes so
realizadas para dar subsdio s concluses sobre o sistema (Soares, 1990). Pode-se ainda
enxergar a natureza analtica ou de simulao em funo da tcnica empregada para
solucionar o modelo. Isto , tendo-se um modelo, se for vivel obter a sua soluo a partir de
equaes que o representem, ento o modelo ser resolvido analiticamente e se referi-r a ele
como um modelo analtico. Se, por outro lado, a soluo do modelo for obtida por meio de
um programa de simulao, tratar-se- de uma soluo por simulao e o modelo ser dito,
muitas vezes, um modelo de simulao (Santana, 1990a).
Existem vrias tcnicas de representao de sistemas adequadas modelagem de sistemas
computacionais. Entre elas, destacam-se: Redes de Petri, Statecharts e Rede de Filas. A
seguir, a tcnica de modelagem por Rede de Filas detalhada.
Rede de Filas
Rede de Filas uma tcnica baseada na Teoria de Filas criada para modelar sistemas nos
quais existe a ocorrncia de filas (Francs, 1998).
Uma rede de filas bsica consiste de entidades chamadas centros de servios e um conjunto
de entidades chamadas de usurios, que recebem servio e circulam pelo sistema (Soares,
1990).
48
Um centro de servio consiste de um ou mais servidores, correspondentes a recursos no

sistema modelado, e uma rea de espera (uma fila) de capacidade finita ou infinita para
usurios que esto requisitando servios. A CPU de um computador um exemplo de recurso
(Soares, 1990).
Para que possa existir distino entre os vrios usurios que circulam em um sistema,
utiliza-se o conceito de Classes de Usurios. Assim, quando o modelo possui mais de uma
classe de usurios, pode-se estabelecer prioridades entre elas.
Medidas de Desempenho
No processo de avaliao de desempenho de um sistema, algumas medidas so

fundamentais. Essas medidas so chamadas de medidas de desempenho.
Para a avaliao de um sistema, deve-se determinar um conjunto de medidas de
desempenho a serem colhidas e, por meio dessas medidas, verificar se o sistema est
atendendo aos requisitos de desempenho estipulados previamente.
A seguir so apresentadas algumas medidas de desempenho, considerando-se um sistema
em que h formao de filas, que o caso dos sistemas computacionais:
A utilizao de um recurso a frao do tempo em que o recurso esteve ocupado.

Ela pode ser obtida por meio da razo entre o tempo que o recurso esteve ocupado
durante um intervalo e o tempo total de durao desse intervalo;
A vazo (throughput) uma medida da taxa de concluso dos trabalhos. Ela dada
pelo nmero de completudes por unidade de tempo;
O tamanho (comprimento) mdio da fila o nmero mdio de usurios em
49
espera e em servio;
O tempo mdio no sistema (centro de servio) o tempo mdio que os usurios

gastam esperando na fila e em servio.
O conhecimento pleno e prvio do sistema fundamental para a escolha adequada da

tcnica a ser utilizada, pois o uso de uma tcnica inadequada pode levar ao fracasso da
avaliao. O estado de desenvolvimento do sistema a ser avaliado tambm deve ser levado em
considerao.
4.3 Avaliao de Desempenho de Servidores Web

O uso da tcnica de modelagem torna-se bastante atrativo quando o objeto de estudo so
sistemas complexos ou ainda inexistentes, pois um modelo uma abstrao de uma situao
real, em que se procuram incorporar suas caractersticas mais relevantes. No caso da Internet,
devido ao seu tamanho e constante evoluo, a avaliao de desempenho baseada em modelos
se impe como a alternativa mais adequada (Teixeira, 2004).
Para avaliar o desempenho de um sistema, de suma importncia caracterizar bem o tipo
de carga a que ele normalmente submetido, bem como o nvel de detalhamento empregado
na descrio da carga. Os recursos do sistema considerados na caracterizao da carga devem
ser aqueles cuja utilizao tenha o maior impacto no desempenho do sistema (Ferrari et al.,
1983). No caso de um servidor Web, a CPU e o sistema de I/O so os principais recursos a
serem analisados. Finalmente, precisam ser determinados os parmetros que melhor
caracterizam cada componente da carga (taxa de chegada, nmero de clientes, tempo de CPU,
de I/O).
Algumas caractersticas especiais devem ser consideradas quando se pretende avaliar o
desempenho de um servidor Web:
50
A populao de usurios de um servidor Web potencialmente ilimitada e as

requisies podem vir de qualquer lugar do mundo;
Um servidor Web pode ser submetido por longos perodos a cargas relativamente
baixas e repentinamente ser alvo de cargas superiores sua capacidade;
A variabilidade no tamanho dos objetos armazenados em um servidor tambm deve

ser considerada, pois a diversidade dos mesmos muito grande. O servidor pode
armazenar objetos que variam desde arquivos texto e HTML a arquivos multimdia;
Atualmente os servidores tambm vm sendo utilizados como servidores de

aplicao, dando suporte gerao dinmica de pginas.
A avaliao de desempenho de especial importncia quando se pretende avaliar o

comportamento de um sistema considerando-se diferentes polticas de funcionamento, como
por exemplo, os escalonadores em servidores Web e a insero de caractersticas de QoS.
4.4 Avaliao de Desempenho do SWDS

A tcnica escolhida para a avaliao de desempenho do Servidor Web com Diferenciao
de Servios (SWDS) foi a modelagem por meio de Rede de Filas. Foi adotado um modelo
simplificado do servidor SWDS, conforme apresentado na Figura 4.2.
Esse modelo consiste de um Classificador, Controle de Admisso, um mdulo de
Escalonamento e um cluster de servidores Web. O mdulo escalonador responsvel por
fazer a distribuio das requisies entre os ns do cluster, assumindo as funes de um
despachante. Cada n do cluster modelado com um recurso que representa o consumo de
CPU e outro que representa o consumo de I/O, conforme Figura 4.3.
51
Figura 4.2: Modelo simplificado do Servidor Web com Diferenciao de Servios (SWDS)
Classificador, Controle de Admisso, escalonador e os ns do cluster foram modelados

como centros de servio. No foram modelados detalhes da rede externa, assumindo-se haver
largura de banda suficiente na rede, uma vez que o foco principal a anlise do desempenho
do SWDS e da sua capacidade de fornecer servios diferenciados.
Figura 4.3: Modelo do Cluster de Servidores Web

Neste captulo, foram mostradas algumas das tcnicas de Avaliao de Desempenho
52
encontradas na literatura. Como tcnicas de Aferio, foram discutidas a construo de

Prottipos, a utilizao de Benchmarcks e a Coleta de Dados. Quanto s tcnicas de
Modelagem, foram apresentadas as Redes de Petri, Statecharts e Rede de Filas.
Em seguida, discutiu-se sobre as medidas que so fundamentais para o processo de
Avaliao de Desempenho, as medidas de desempenho.
Dando continuidade, foram exibidas algumas caractersticas dos servidores Web, que so
sistemas cuja Avaliao de Desempenho baseada em modelos considerada bastante
adequada.
Finalmente, foi apresentado o modelo do Servidor Web com Diferenciao de Servios
utilizado para avaliar as estratgias de melhoria de desempenho propostas neste trabalho.
Para avaliar o desempenho de um sistema, de suma importncia caracterizar bem o tipo
de carga a que ele normalmente submetido. Por isso, no prximo captulo sero
apresentados os critrios utilizados para a gerao de uma carga de trabalho sinttica para um
site de comrcio eletrnico. Optou-se pelo comrcio eletrnico porque esses servios so uns
dos mais impactados negativamente quando h um comportamento ruim do servidor em
situaes de sobrecarga.
No captulo a seguir, tambm sero discutidas as caractersticas das requisies Web
tpicas do e-commerce, uma vez que se tem por objetivo melhorar o desempenho do modelo
SWDS quando so consideradas tais caractersticas. As caractersticas consideradas devem ser
as que causam os maiores impactos no desempenho do sistema. No caso de um servidor Web,
os consumos de CPU e de sistema de I/O so as principais a serem analisadas.
53
5
Carga de Trabalho

Neste captulo, descrito o processo realizado para gerao de uma carga de trabalho
sinttica para um site de comrcio eletrnico. Para a realizao de uma avaliao de
desempenho sem a participao de uma empresa do mercado, necessrio reproduzir um
cenrio que retrate a realidade atual de sites de comrcio eletrnico e gerar uma carga de
trabalho sinttica que retrate o mais prximo possvel o atual comportamento dos
consumidores de sites de comrcio eletrnico.
Com o propsito de melhorar o desempenho do SWDS quando consideradas as
caractersticas das requisies Web na tomada de deciso, para a gerao da carga de
trabalho, foram consideradas informaes dos diversos tipos de requisies tpicas de ecommerce.
O modelo de carga de trabalho foi definido com base em trabalhos relacionados.
5.2 Comrcio Eletrnico

Segundo E-Bit (2007), os nmeros e as taxas de crescimento das vendas online nos ltimos
54
anos comprovam que o comrcio eletrnico brasileiro est consolidado. Em 2007, esse
segmento cresceu 43% em relao ao ano anterior, atingindo a cifra de R$ 6,3 bilhes
faturados em vendas de produtos pela Internet. A expectativa para o primeiro semestre de
2008 de que as compras cresam aproximadamente 45% em relao ao primeiro semestre de
2007.
Com relao ao nmero de pessoas adeptas s compras no mundo virtual, as expectativas
tambm so boas. 9,5 milhes de internautas j passaram pela experincia de comprar algum
produto pela rede. Em 2008, espera-se que esse nmero suba para 10,5 milhes de econsumidores.
Esses dados evidenciam que a demanda de trfego para aplicaes Web do gnero tem
aumentado, uma vez que a utilizao da Internet para comprar e vender produtos se torna um
hbito cada vez mais comum. Esse aumento na demanda justifica a utilizao de uma
estrutura com diversos servidores Web para atender, com desempenho aceitvel pelos
consumidores, as requisies.
A carga de trabalho no ambiente e-commerce caracterizada pela presena de sesses. As
sesses so definidas por uma seqncia de requisies de diferentes tipos, feitas por um
mesmo usurio durante uma visita ao site (Barbato, 2008). Neste trabalho, essas interaes
sero classificadas em duas categorias gerais:
Categoria Navegar envolvem navegao e pesquisa, mas nenhuma atividade de

pedido de produtos. As interaes tpicas que abrangem essa categoria so: Pgina
Principal, Listar Categorias, Visualizar Detalhes de produto e Buscar produto;
Categoria Pedir envolvem somente atividades de pedido de produtos e incluem as

seguintes interaes: Login, Local de Entrega, Forma de Pagamento e Confirmao de
pedido.
55
Interaes da Categoria Pedir tm maior probabilidade de gerar renda. Em situaes de

sobrecarga, servidores Web para sites de comrcio eletrnico podem deixar de atender
requisies que geram renda por conta do aumento excessivo na quantidade de requisies da
Categoria Navegar. Essas situaes merecem ateno, pois um comportamento adequado da
estrutura da loja virtual em momentos de sobrecarga pode gerar resultados representativos ao
negcio.
5.3 Modelo da Carga de Trabalho

Um dos problemas encontrados na simulao de sistemas relacionados Web consiste na
gerao de uma carga de trabalho que reproduza um cenrio o mais prximo da realidade
atual.
Tendo em vista a dificuldade de encontrar um arquivo de registros com acessos reais ao
site de uma loja varejista online, decidiu-se gerar uma carga de trabalho sinttica para a
experimentao do modelo.
Em uma tpica loja virtual de varejo, muitos usurios navegam e realizam buscas pelas
pginas do site a procura de um produto especfico (interaes do tipo Navegar). Se
encontrarem o produto desejado e tiverem inteno de compr-lo, podero iniciar um
processo de transao para a realizao do pedido (interaes do tipo Pedir). Existe ainda a
possibilidade de o usurio abandonar o site durante qualquer uma das interaes (Sabo, 2006).
Uma interao da Categoria Pedir constituda de um primeiro passo: a pgina de Login.
Desse ponto em diante, o usurio orientado a seguir algumas etapas em seqncia (escolha
do local de entrega da mercadoria e seleo da forma de pagamento) at culminar em uma
requisio do tipo Confirmao, que finaliza o pedido.
Essas transies entre as diferentes categorias de interaes (Navegar e Pedir) dos usurios
pelo site podem ser representadas por uma mquina de estados finitos, em que as
56
probabilidades so estacionrias e as transies de estados sem memria. Dessa forma, em

Menasc et al. (1999) so apresentados dois perfis de usurios: o perfil dos usurios
considerados Compradores Ocasionais e o perfil dos usurios considerados Compradores
Freqentes.
A Figura 5.1 ilustra o comportamento dos usurios Compradores Ocasionais. Os estados
correspondem s pginas que caracterizam as interaes e os arcos representam as transies:
Figura 5.1: Compradores Ocasionais (Menasc et al., 1999)
Os Compradores Ocasionais so aqueles que usam os sites de comrcio eletrnico para

pesquisar por novos produtos, detalhes dos itens a venda, lanamentos e novidades.
A Figura 5.2 apresenta o comportamento dos usurios Compradores Freqentes. Esses
usurios so aqueles que possuem o hbito de efetivamente concluir o processo de compra.
Fica clara a diferena de comportamento entre os dois perfis, principalmente pela
probabilidade de transio do estado Detalhes para o estado Login. Enquanto que para os
Compradores Ocasionais essa probabilidade de 0,5%, para os Compradores Freqentes essa
probabilidade de 30%, ou seja, seis vezes maior.
57
Figura 5.2: Compradores Freqentes (Menasc et al., 1999)
Conforme Menasc et al. (1999), adotando-se 90% dos usurios que iniciam uma sesso
como sendo do tipo Compradores Ocasionais e 10% como Compradores Freqentes, tem-se a
mquina de estados descrita na Figura 5.3:
Figura 5.3: Mquina de Estados (Menasc et al., 1999)
Sabe-se que a probabilidade mxima de transio entre um estado e outro 1. Na Figura

5.3, observa-se que a soma das probabilidades de transio de um estado para outros no
atinge a totalidade. Por exemplo: a soma das probabilidades de transio do estado Categorias
58
para os estados Buscas (0,345), Detalhes (0,2) e/ou de retorno para o prprio estado
Categorias (0,395) de 0,94. Isso ocorre porque h ainda a probabilidade de o usurio deixar
o site, que de 0,06. Por uma questo de esttica, isso no est representado na mquina de
estados.
Tendo-se as probabilidades de transio de um estado para outro, possvel calcular a
carga gerada ao sistema para cada requisio do tipo Principal atendida, ou seja, para cada
nova sesso iniciada.
A seguir, apresentado o sistema de equaes que representa tal carga:
A
-0,5A
-0,5A
+0,605B
-0,345B
-0,2B
-0,345C
+0,605C
-0,2C
-0,415 D
-0,415D
+D
-0,075D
-0,203E
-0,2023E
-0,19E
+0,945E
-0,333E
+F
-0,95F
+G
-0,95G
+H
=
=
=
=
=
=
=
=
1
0
0
0
0
0
0
0
Resolvendo-se o sistema de equaes, obtm-se a carga mdia gerada ao sistema para cada
nova sesso iniciada. Os resultados so apresentados na Tabela 5.1:
A = Principal
B = Categorias
C = Buscas
D = Detalhes
E = Login
F = Entrega
G = Pagamento
H = Confirmao
Carga
1
5,887
5,887
2,391
0,190
0,063
0,060
0,057
Carga Relativa
6,44%
37,90%
37,90%
15,39%
1,22%
0,41%
0,39%
0,37%
Tabela 5.1: Carga mdia gerada ao sistema por cada sesso
Com o modelo de distribuio de tipos de requisies apresentado neste trabalho,

possvel gerar uma carga de trabalho sinttica que represente o comportamento atual de
usurios e clientes de uma loja virtual varejista. Esse modelo de carga de trabalho foi utilizado
59
para a experimentao do modelo de simulao descrito na prxima seo.
5.4 Cenrio Adotado

Com o modelo de carga de trabalho definido, decidiu-se por realizar experimentos reais e
coletar tempos mdios de resposta para cada categoria de pgina que recebe requisies Web.
Com esses experimentos, pode-se obter o comportamento de um sistema Web real e encontrar
valores para parametrizar as simulaes de polticas de atendimento de requisies.
Para a obteno de valores mdios de tempos de resposta para cada tipo de requisio que
compe o modelo de carga de trabalho definido, seria necessrio analisar registros de
servidores Web reais que disponibilizassem esse tipo de informao. Tendo em vista a
dificuldade de encontrar arquivos de registros do gnero, optou-se por reproduzir um cenrio
real o mais prximo da realidade atual, gerar as informaes necessrias e realizar uma
anlise posterior.
Para desenvolver uma aplicao do gnero que implementasse as funcionalidades de uma
loja virtual de varejo, seria necessrio implementar um modelo de dados no trivial para
armazenar informaes de produtos em uma base de dados, dominar uma linguagem de
programao para Web com o uso de sesso, cache , entre outras funcionalidades, e preencher
uma base de dados com informaes coerentes e equivalentes aos de um catlogo de uma loja
virtual real. Assim, concluiu-se que o tempo necessrio para o desenvolvimento de tal
aplicao seria invivel e optou-se pela busca de alternativas.
Em Sabo (2006), apresentado um estudo que utilizou como ferramentas a osCommerce
(Leon et al., 2008), o banco de dados MySQL (MySQL, 2008) e o software Apache (servidor
Web) para encontrar os valores mdios de tempos de resposta para cada tipo de requisio que
compe o modelo de carga de trabalho. Como tal estudo j foi validado e apresentado
comunidade cientfica, decidiu-se pela utilizao dessas informaes neste trabalho.
60
A osCommerce uma soluo de cdigo aberto e com licena GNU/GPL (General Public
License) que implementa um modelo de loja varejista que vende produtos na Internet. Essa
soluo de cdigo aberto oferece funes de comrcio eletrnico que permitem aos
consumidores navegar por categorias de produtos, procurar por informaes sobre produtos
existentes, ver detalhes de produtos, realizar pedidos e escolher o local de entrega e forma de
pagamento. As interaes relacionadas ao pedido de produtos so criptografadas por meio de
conexes SSL (Secure Socket Layer). Os clientes precisam se registrar no site antes de terem
permisso para comprar. O site mantm um catlogo de itens que podem ser pesquisados por
um cliente. Cada item possui uma descrio textual e uma imagem miniatura associada com
tamanho inferior a 5 Kbytes.
A Figura 5.4 ilustra o cenrio que foi utilizado em Sabo (2006) para a realizao dos
experimentos:
Figura 5.4: Cenrio utilizado para a realizao de experimentos
Um computador (identificado como Cliente) foi utilizado para gerar requisies de clientes
Web, o outro foi configurado apenas como um Servidor Web para registrar os tempos de
atendimento) e um terceiro foi configurado como um servidor de aplicaes, responsvel
pelas operaes de acesso ao Banco de Dados. Todos os computadores foram interligados por
uma rede padro Gigabit Ethernet e possuem processadores AMD Athlon XP com 3.2 GHz de
61
freqncia, 1 GByte de memria RAM e disco rgido de 7200 rotaes por minuto, com
capacidade de armazenamento de 80 GBytes.
Para que o Servidor Web Apache registrasse algumas informaes importantes para uma
anlise melhor de componentes especficos do sistema, como tempos mdios de consumo de
CPU e I/O, foram realizadas, em Sabo (2006), algumas modificaes em seu cdigo fonte.
Servidores Web, em geral, registram em arquivos texto (logs) eventos de sucesso e erros
associados s requisies de clientes, sendo que cada registro traz apenas informaes de data
e hora de atendimento, nome do arquivo, mtodo pelo qual realizou a solicitao, quantidades
de bytes enviados e tempo total de atendimento das requisies. Assim, por meio de
instrumentao do cdigo fonte, novas funcionalidades foram disponibilizadas no software
servidor Web Apache. Uma nova funo que coleta o tempo atual de consumo de CPU de
uma requisio Web em um processo do servidor em execuo foi adicionada, com a
utilizao da chamada clock() do sistema operacional Linux. Na estrutura de uma requisio
do Apache existe um campo denominado request_time, designado para armazenar o tempo
inicial de atendimento de uma requisio. Dessa forma, utilizando a mesma analogia, foi
adicionado um novo campo denominado request_time_cpu para armazenar o tempo inicial
de CPU da requisio.
Uma vez extrado do servidor Web o tempo total de atendimento de uma requisio e o
tempo total de consumo de CPU, pode-se calcular o tempo consumido em entrada e sada
(I/O). Esse tempo obtido por meio da equao 5.1, em que: r representa a requisio, Tr,total o
tempo total de atendimento de uma requisio r, e Tr,cpu o tempo total de consumo de CPU
(Sabo, 2006):
Tr,io = Tr,total Tr,cpu
(5.1)
O tempo de entrada e sada inclui o tempo de acesso a disco local e acesso a banco de
dados. No caso, como o banco de dados foi instalado em outro computador, o tempo de
62
entrada e sada inclui tambm os atrasos de rede.

Os resultados apresentados em Sabo (2006) e que so considerados neste trabalho so
mostrados nas Tabelas 5.2 e 5.3. So valores mdios alcanados por meio da gerao de
quantidades diferentes de requisies, com intervalo de 1 segundo entre cada uma.
Na Tabela 5.2 so exibidos os tempos mdios das requisies quando considerado o
recurso de cache no cliente:
Valores COM CACHE no cliente
Tempos de Resposta
Porcentagens
Total
CPU
I/O
CPU
I/O
Principal
0,088253
0,070430
0,017823
79,8046%
20,1954%
Detalhes
0,086097
0,063750
0,022347
74,0442%
25,9558%
Buscas
0,115783
0,094333
0,021450
81,4741%
18,5259%
Categorias
0,096115
0,076333
0,019782
79,4186%
20,5814%
Login
0,046445
0,041331
0,005114
88,9887%
11,0113%
Entrega
0,056348
0,048927
0,007421
86,8292%
13,1708%
Pagamento
0,105471
0,083768
0,021704
79,4220%
20,5780%
Confirmao
0,112506
0,063000
0,049506
55,9971%
44,0029%
Tabela 5.2: Valores obtidos COM o recurso de cache no cliente.
A Tabela 5.3 composta pelos tempos mdios das requisies quando desconsiderado o
recurso de cache no cliente.
Pginas Web dinmicas, em relao a pginas Web estticas, tm como diferencial um
maior consumo de recursos de CPU e o fato de no terem seus contedos armazenados em
memria cache. Operaes de acesso base de dados so caracterizadas por exigirem maior
demanda de dispositivos de I/O.
Como se pode observar nas Tabelas 5.2 e 5.3, o tempo de consumo de CPU das requisies
maior que o tempo de consumo de dispositivos de I/O. Isso se deve no somente pelo fato
de a base de dados estar presente em um servidor de aplicaes (separado do servidor Web),
mas tambm pela presena do recurso de cache do sistema operacional no host servidor Web.
63
Valores SEM CACHE no cliente

Tempos de Resposta
Porcentagens
Total
CPU
I/O
CPU
I/O
Principal
0,091791
0,072928
0,018863
79,4504%
20,5496%
Detalhes
0,087716
0,073754
0,013962
84,0830%
15,9170%
Buscas
0,121153
0,096474
0,024679
79,6301%
20,3699%
Categorias
0,098332
0,082080
0,016252
83,4725%
16,5275%
Login
0,076757
0,041000
0,035757
53,4153%
46,5847%
Entrega
0,125837
0,083333
0,042504
66,2232%
33,7768%
Pagamento
0,140452
0,072333
0,068118
51,5005%
48,4995%
Confirmao
0,144596
0,058667
0,085929
40,5729%
59,4271%
Tabela 5.3: Valores obtidos SEM o recurso de cache no cliente.
Arquivos estticos, acessados com maior freqncia no servidor Web imagens, folhas de
estilos etc. , tendem a permanecer na memria cache gerenciada pelo sistema operacional
que executa o servidor. Dessa forma, ao contrrio do que se espera, so resgatados da
memria e no de um dispositivo de armazenamento. A ferramenta utilizada para medir o
tempo de consumo de CPU classifica acessos memria como operaes de CPU.
Caso o cliente Web utilize cache local (opcional e configurvel no navegador), objetos que
compem as pginas Web podem ou no ser requisitados para o servidor, o que gera
economia de recursos. Como as pginas atendidas pelo servidor so dinmicas e compostas
por pequenos arquivos estticos embutidos com tamanho inferior a 5 Kbytes , essa
economia se torna desprezvel.
Em requisies da Categoria Navegar, o ganho de desempenho COM ou SEM o uso do
recurso de cache no cliente se torna desprezvel. No entanto, quando se trata de interaes do
tipo Pedir, no usar o recurso de cache no cliente gera um aumento no tempo de I/O da
requisio. Isso se deve ao fato de as requisies da categoria Pedir serem criptografadas por
meio de conexes SSL (Secure Socket Layer). Sem o recurso de cache no cliente, a chave de
64
segurana da respectiva sesso do cliente dever ser reenviada ao cliente a cada requisio.
Dessa forma, o servidor executar novamente o procedimento de handshaking troca de
certificados, negociao de compresso e codificao, configurao de identificador de
sesso. Esse procedimento realizado durante o atendimento de uma requisio e pode
aumentar em escalas muito maiores o tempo de I/O, conforme a largura de banda da rede que
interliga o cliente e o servidor (Goldberg et al., 1998).

Neste captulo foi proposto um modelo de carga de trabalho Web para sites de comrcio
eletrnico, especificamente de varejo.
Para a definio da porcentagem das requisies que acessam o servidor Web, foi utilizado
o padro de comportamento apresentado em Menasc et al. (1999). Aps montar e resolver o
sistema de equaes que representa a mquina de estados, chegou-se aos valores apresentados
na Tabela 5.1. Nota-se que, para cada sesso atendida pelo sistema, a maioria das requisies
do tipo Categorias e Buscas, pois so os tipos de solicitaes que permitem ao usurio a
explorao do site em busca do produto desejado. Outro ponto de destaque o fato de que
existe uma probabilidade muito baixa de cada sesso efetivamente gerar uma venda.
Em seguida, foram mostrados e discutidos os tempos mdios de consumo de CPU e I/O
das requisies Web apresentados em Sabo (2006). Como tal estudo j foi validado e
apresentado comunidade cientfica, decidiu-se pela utilizao dessas informaes neste
trabalho. Os valores foram apresentados nas Tabelas 5.2 (COM o recurso de cache no cliente)
e 5.3 (SEM o recurso de cache no cliente).
Tendo-se a mquina de estados que descreve o comportamento dos usurios no sistema e o
tempo mdio de consumo de CPU e I/O de cada uma, possvel gerar a carga de trabalho
necessria para alimentar o modelo proposto neste trabalho.
65
No prximo captulo, sero apresentadas as estratgias propostas para melhorar o

desempenho do SWDS quando so consideradas as caractersticas das requisies Web tpicas
de um site de comrcio eletrnico e os resultados dos experimentos.
66
6
Resultados Obtidos

Com o intuito de aprimorar o funcionamento do servidor Web, foram estudadas diversas
estratgias de atendimento s requisies. Inicialmente foram analisados os impactos de
alterar apenas o modo de funcionamento das filas dos servidores. Em seguida, foram
observadas tambm as vantagens e desvantagens de utilizar mecanismos de controle de
admisso ao sistema. Finalmente, foram feitas combinaes dessas duas abordagens.
A seguir, so apresentados a metodologia utilizada para a realizao dos experimentos e os
resultados obtidos com as diversas anlises realizadas.
6.2 Metodologia para Experimentos

A simulao foi a tcnica escolhida para solucionar o modelo de Rede de Filas do SWDS
apresentado na Figura 4.2. Optou-se por essa abordagem por ser bastante flexvel e permitir a
verificao de diferentes configuraes prontamente.
Todas as caractersticas necessrias para a gerao da carga de trabalho foram consideradas
do estudo apresentado no Captulo 5. As porcentagens de acesso das requisies so definidas
67
de acordo com a Tabela 5.1. Os tempos de atendimento de CPU e I/O so estabelecidos por
distribuies exponenciais com valores mdios baseados nas Tabelas 5.2 ou 5.3. A taxa de
acerto em cache para cada requisio apresentada na Tabela 6.1:
Acertos em Cache (Cliente)

Principal
30%
Detalhes
30%
Buscas
30%
Categorias
30%
-
Login
Entrega
100%
Pagamento
100%
Confirmao
100%
Tabela 6.1: Taxas de acerto em cache no cliente
A taxa de acerto em cache para requisies da Categoria Navegar fixada em 30%,

segundo SPECweb2005 (2005). J as requisies da Categoria Pedir possuem taxas de acerto
diferenciadas. Isso se deve ao fato de as requisies dessa categoria serem criptografadas por
meio de conexes SSL (Secure Socket Layer) e apresentarem algumas particularidades em
relao ao uso do recurso de memria cache no cliente.
Neste trabalho, considera-se que o procedimento de handshaking troca de certificados,
negociao de compresso e codificao, configurao de identificador de sesso
executado apenas em requisies do tipo Login e que a chave gerada permanece armazenada
no cache local do cliente. Isso significa que, para todas as requisies do tipo Login, sero
utilizados os tempo de consumo de CPU e I/O da Tabela 5.3, uma vez que no existe
probabilidade de o cliente possuir uma chave de sesso vlida que o permita utilizar objetos
embutidos armazenados em cache local.
Tendo em vista que as requisies dos tipos Entrega, Pagamento e Confirmao no
repetiro o procedimento de handshaking, atribuem-se a elas os tempos de consumo de CPU e
68
I/O da Tabela 5.2. Mesmo que, por motivos adversos, aps a etapa de Login, o contedo da
memria cache do cliente possa ser apagado, assume-se uma taxa de acerto de 100% nessas
requisies.
Para dar origem s requisies, foi utilizado o log de acesso a servidores do site da Copa
do Mundo de 1998 (World Cup, 1998). As simulaes so controladas pelo tempo, tendo sido
definido em vinte minutos, sendo quatro minutos para o warm-up. O log traz informaes de
oito servidores, mas para este trabalho so consideradas as informaes de apenas dois deles,
sendo suficiente para gerar uma situao de sobrecarga.
Todas as requisies geradas a partir do log, quando admitidas pelo sistema, so
consideradas requisies da categoria Principal. Sendo atendidas, as respostas so enviadas ao
consumidor e, aps o tempo de pensar do consumidor (thinking time), daro origem a
requisies do tipo Categorias ou do tipo Buscas, de acordo com as probabilidades
apresentadas na mquina de estados da Figura 5.3. Por sua vez, as requisies do tipo
Categorias daro origem a requisies do tipo Buscas, Detalhes ou a outras requisies do
tipo Categorias. Essa lgica utilizada para a gerao dos demais tipos de requisies. O
tempo de pensar do consumidor foi representado segundo uma distribuio uniforme [4, 8].
A capacidade de processamento do Classificador foi definida como 8000
requisies/seg. A capacidade do Controle de Admisso foi definida como 4000
requisies/seg (Traldi et al., 2006).
Para todos os experimentos, o modelo do SWDS foi configurado como um cluster de dez
ns (servidores Web). Essa configurao apresentou-se adequada, pois permitiu a manuteno
da situao de sobrecarga necessria s anlises, mantendo a caracterstica de servidor
distribudo.
Todos os resultados apresentados correspondem a uma mdia de cinco simulaes. So
apresentados tambm os intervalos de confiana de 95%.
69
Para a implementao e soluo do modelo por simulao, foi utilizada a biblioteca

SimpackJava (Fishwick, 2004), desenvolvida a partir da biblioteca SMPL (MacDougall,
1987).
6.3 Resultados dos Experimentos

Os resultados obtidos para as diversas estratgias de atendimento implementadas no
modelo SWDS so apresentados a seguir.
6.3.1 Algoritmo Round-Robin (RR)

O primeiro experimento realizado utilizou o algoritmo de escalonamento Round-Robin
para distribuir as requisies entre os ns do cluster do SWDS. Esse algoritmo atribui as
requisies aos servidores do cluster segundo um esquema de rodzio.
No foi implementado nenhum mecanismo de controle de admisso no modelo. Nas filas
dos ns servidores, foi mantida a tradicional disciplina de atendimento FCFS (First-Come
First-Served), que atende as requisies de acordo com a ordem de chegada,
independentemente da sua classe de prioridade.
Esse experimento foi realizado com o intuito de analisar o comportamento do SWDS em
situaes de sobrecarga, quando nenhum mecanismo de diferenciao de servios utilizado.
Pode-se observar, conforme dados apresentados na Tabela 6.2, que todas as requisies
foram admitidas pelo sistema e receberam o mesmo tipo de atendimento, sem diferenciao.
A utilizao dos recursos de CPU do sistema atinge 100%, uma vez que as requisies so do
tipo CPU-Bound, conforme Tabelas 5.2 e 5.3. Com a sobrecarga, o tempo mdio de resposta
s requisies ficou muito elevado, com mdia de 305,90 s. Alm disso, apenas 57,03% das
requisies admitidas pelo sistema foram concludas.
Para auxiliar no critrio de avaliao das polticas de atendimento propostas nesta
dissertao, foram elaborados dois novos ndices: eficincia e rejeio.
70
ndice de Eficincia: obtido pela razo entre a quantidade de requisies

concludas da classe Confirmao (C) e a quantidade total de requisies feitas ao
sistema (U). Ele mostra, do total de requisies feitas ao servidor, qual o
percentual de requisies concludas de efetivao de venda.
ndice de Rejeio: obtido pela razo entre a parcela de requisies no admitidas

pelo sistema (U - A) e a quantidade total de requisies (U). Esse indicador mostra
a proporo de requisies rejeitadas pelo servidor.
Esses indicadores so apresentados na parte inferior das tabelas.
Taxa Chegada (req/s)

224,85
Requisies
Principal
Categorias
Buscas
Detalhes
Login
Entrega
Pagamento
Confirmao
Total
Requisies
Principal
Categorias
Buscas
Detalhes
Login
Entrega
Pagamento
Confirmao
Total
Eficincia
(C / U)
IC(95%)
0,41
Throughput (req/s)
128,23
IC(95%)
0,03
Util. CPU(%)
100,00
IC(95%)
0,00
Chegadas (n)
97.063,20
52.874,60
53.045,80
12.124,20
547,20
108,40
58,80
29,20
IC(95%)
319,66
190,07
206,00
74,19
16,78
15,10
12,05
7,21
Admisses (n)
97.063,20
52.874,60
53.045,80
12.124,20
547,20
108,40
58,80
29,20
IC(95%)
319,66
190,07
206,00
74,19
16,78
15,10
12,05
7,21
Admisses (%)
100,00
100,00
100,00
100,00
100,00
100,00
100,00
100,00
215.851,40
394,30
215.851,40
394,30
100,00
Trminos (n)
55.326,00
30.238,00
30.145,00
6.951,40
326,00
61,80
31,20
19,20
IC(95%)
83,65
83,28
85,99
63,23
14,16
11,66
6,11
4,06
123.098,60
29,48
Trminos (%)
Tempo Med Resp (s)
57,00
305,95
57,19
305,73
56,83
306,07
57,33
305,38
59,58
308,36
57,01
311,64
53,06
288,55
65,75
308,79
57,03
305,90
Rejeio
(U- A) / U
0,009%
IC(95%)
0,42
1,22
1,28
2,03
7,53
17,72
19,39
25,16
0,51
0,00%
Tabela 6.2: Algoritmo Round-Robin
71
Para esse experimento, o ndice de Eficincia muito baixo (0,009%), indicando que,
apesar do sistema estar sobrecarregado, conclui poucas vendas.
O ndice de Rejeio manteve-se zerado, pois no foi implantado nenhum mecanismo de
controle de admisso. Assim, o SWDS foi mantido em situao de sobrecarga, fazendo com
que o tempo de resposta s requisies fosse crescendo ao longo da simulao, conforme
grfico da Figura 6.1.
Tempo de Resposta x Tempo de Simulao
1500
1400
1300
1200
1100
Tempo de Resposta (s)
1000
900
800
700
600
500
400
300
200
100
0
240
440
640
840
1040
1240
Tempo de Simulao (s)
Principal
Categorias
Buscas
Detalhes
Login
Entrega
Pagamento
Confirmao
Figura 6.1: Algoritmo Round-Robin
O baixo ndice de Eficincia obtido nesse experimento e o elevado tempo mdio de

resposta s requisies evidenciam a necessidade de outros mecanismos de atendimento.
6.3.2 Algoritmo Weighted Fair Queuing (WFQ)

Com o objetivo de melhorar a utilizao dos recursos do servidor SWDS, de acordo com
os interesses geralmente envolvidos em um negcio do tipo e-commerce, foi inserido no
modelo o algoritmo de diferenciao de servios Weighted Fair Queuing (WFQ) (Traldi et al.,
72
2006). Esse algoritmo baseado em Prioridades e utiliza a idia de dividir a capacidade de

processamento dos ns do cluster entre as classes de requisies de acordo com os pesos que
so atribudos s classes. Como parmetro para o escalonamento, o algoritmo tambm
considera o tempo de processamento necessrio para atender a uma requisio, priorizando
requisies menos custosas (Traldi et al., 2006). De uma maneira simplista, se forem
atribudos pesos 2 e 1 s classes A e B, respectivamente, esperar-se- que a cada trs
requisies (de mesmo custo) atendidas pelo servidor, duas sejam da classe A e uma seja da
classe B.
Uma vez inserido o WFQ no modelo SWDS, a prxima etapa para definir os parmetros
para a realizao do experimento foi determinar os pesos a serem utilizados pelo algoritmo, de
acordo com os interesses do negcio, para as diversas classes de requisies existentes:
Principal, Categorias, Buscas, Detalhes, Login, Entrega, Pagamento e Confirmao.
Para a determinao dos pesos a serem utilizados, foi proposto um modelo de Otimizao
Linear que busca maximizar o nmero de requisies atendidas pelo servidor em um intervalo
de tempo. O modelo proposto apresentado a seguir:
Maximizar:
A+B+C+D+E+F+G+H
(6.1)
Sujeito s restries:
0,072A
+0,071B
+0,096C
+0,080D
+0,041E
-0,5A
+0,605B
-0,345C
-0,415D
-0,5A
-0,345B
+0,605C
-0,2B
-0,2C
<=
-0,203E
<=
-0,415D
-0,203E
<=
+D
-0,190E
<=
-0,075D
+0,945E
<=
<=
<=
<=
-0,333E
+0,049F
+0,084G
+0,063H
+F
-0,95F
+G
-0,95G
+H
73
Maximizar a equao 6.1 significa maximizar a quantidade de requisies atendidas pelo

servidor. No entanto, devem ser satisfeitas todas as restries apresentadas no modelo.
A primeira restrio responsvel por otimizar o nmero de requisies que o servidor
atende em um determinado intervalo de tempo, uma vez que os coeficientes dessa equao de
restrio so os tempos mdios de CPU das requisies de cada tipo, levando-se em conta as
taxas de acerto em cache apresentadas na Tabela 6.1. Utilizou-se o tempo de CPU por se
tratar de requisies CPU-Bound. Esses coeficientes so apresentados na Tabela 6.3:
>
0,072179 s
0,070753 s
0,095832 s
0,080356 s
0,041000 s
0,048927 s
0,083768 s
0,063000 s
A = Principal
B = Categorias
C = Buscas
D = Detalhes
E = Login
F = Entrega
G = Pagamento
H = Confirmao
Tabela 6.3: Tempos mdios de CPU - considerando acertos em cache
As demais equaes de restrio garantem a consistncia da carga de trabalho com relao

mquina de estados da Figura 5.3, uma vez que, mudando-se a proporo de requisies de
um determinado tipo, altera-se a proporo dos demais tipos tambm.
Com o auxlio da ferramenta Solver (Excel, 2003), foi solucionado o modelo de
Otimizao Linear pelo mtodo simplex (Dantzig, 1951). O resultado apresentado na Tabela
6.4:
Tipo de Requisio
A = Principal
B = Categorias
C = Buscas
D = Detalhes
E = Login
F = Entrega
G = Pagamento
H = Confirmao
Peso
7,654
6,326
0,000
0,000
0,000
0,000
0,000
0,000
Peso Relativo
54,75%
45,25%
0,00%
0,00%
0,00%
0,00%
0,00%
0,00%
Tabela 6.4: Pesos obtidos para o WFQ (maximizando atendimentos)
Os pesos apresentados na Tabela 6.4 foram utilizados no algoritmo WFQ inserido no

74
SWDS. Como o custo das requisies j foi considerado no modelo de otimizao, o

algoritmo WFQ foi configurado para desprezar essa informao no critrio de diferenciao.
236,84
Requisies
Principal
Categorias
Buscas
Detalhes
Login
Entrega
Pagamento
Confirmao
Total
Requisies
Principal
Categorias
Buscas
Detalhes
Login
Entrega
Pagamento
Confirmao
Total
Eficincia
(C / U)
IC (95%)
0,05
Throughput (req/s)
139,77
IC (95%)
0,01
Util. CPU (%)

100,00
IC (95%)
0,00
Chegadas (n)
96.794,80
60.640,20
57.861,60
12.060,20
4,20
1,40
0,40
-
IC (95%)
39,83
94,13
220,30
143,22
4,34
2,42
1,11
-
Admisses (n)
96.794,80
60.640,20
57.861,60
12.060,20
4,20
1,40
0,40
-
IC (95%)
39,83
94,13
220,30
143,22
4,34
2,42
1,11
-
Admisses (%)
100,00
100,00
100,00
100,00
100,00
100,00
100,00
-
227.362,80
45,03
227.362,80
45,03
100,00
Trminos (n)
73.978,60
60.167,80
18,40
11,00
2,40
0,60
-
IC (95%)
82,72
88,55
5,59
1,24
2,86
1,11
-
134.178,80
6,29
0,000%
Trminos (%)
Tempo Med Resp (s)
76,43
166,44
99,22
40,12
0,03
455,46
0,09
747,22
57,14
660,47
42,86
709,12
59,02
IC (95%)
109,89
Rejeio
(U - A) / U
8,12
18,17
80,33
130,76
210,18
130,15
9,49
0,00%
Tabela 6.5: Algoritmo WFQ (maximizando atendimentos)
Conforme resultados apresentados na Tabela 6.5, foram atendidas mais requisies pelo
servidor SWDS, um aumento de 9% em relao ao algoritmo RR. O throughput evoluiu de
128,23 req/s para 139,77 req/s. Isso ocorreu porque foram atendidas poucas requisies com
maior custo de processamento ao sistema Buscas, Detalhes e Pagamentos. Assim, mais
requisies puderam ser atendidas.
No entanto, evidente que para um negcio de e-commerce o objetivo principal no
atender o maior nmero de requisies web, mas sim gerar o maior nmero de vendas. Dessa
forma, a funo objetivo do modelo de otimizao linear foi ajustada para maximizar o
nmero de concluses de processos de venda. O novo modelo apresentado a seguir:
75
Maximizar:
0A+0B+0C+0D+0E+0F+0G+H
(6.2)
Sujeito s restries:
0,072A
+0,071B
+0,096C
+0,080D
+0,041E
-0,5A
+0,605B
-0,345C
-0,415D
-0,5A
-0,345B
+0,605C
-0,2B
-0,2C
<=
-0,203E
<=
-0,415D
-0,203E
<=
+D
-0,190E
<=
-0,075D
+0,945E
<=
<=
<=
<=
-0,333E
+0,049F
+0,084G
+0,063H
+F
-0,95F
+G
-0,95G
+H
A equao a ser maximizada foi determinada levando-se em considerao que o processo

de venda concludo com as requisies do tipo Confirmao. Assim, maximizar a equao
6.2 significa maximizar a probabilidade de gerar vendas pelo servidor.
O modelo foi solucionado, e o novo resultado apresentado na Tabela 6.6:
Tipo de Requisio
A = Principal
B = Categorias
C = Buscas
D = Detalhes
E = Login
F = Entrega
G = Pagamento
H = Confirmao
Peso
0,791
4,656
4,656
1,891
0,150
0,050
0,047
0,045
Peso Relativo
6,44%
37,90%
37,90%
15,39%
1,22%
0,41%
0,39%
0,37%
Tabela 6.6: Pesos obtidos para o WFQ (maximizando vendas)
A soluo do modelo de otimizao indica que, para maximizar o nmero de vendas pelo
sistema, deve ser priorizado o atendimento a todas as sesses cujo atendimento tenha sido
iniciado ou, ento, ao se admitir uma nova sesso no sistema, deve-se garantir o atendimento
s requisies subseqentes, pertencentes mesma sesso. Isso fica claro ao comparar as
Tabela 5.1 e 6.6.
76
Os pesos apresentados na Tabela 6.6 foram utilizados no algoritmo WFQ e os resultados

obtidos so apresentados na Tabela 6.7.
216,20
Requisies
Principal
Categorias
Buscas
Detalhes
Login
Entrega
Pagamento
Confirmao
Total
Requisies
Principal
Categorias
Buscas
Detalhes
Login
Entrega
Pagamento
Confirmao
Total
Eficincia
(C / U)
IC (95%)
0,19
Throughput (req/s)
122,81
IC (95%)
0,06
Util. CPU (%)

100,00
IC (95%)
0,00
Chegadas (n)
97.147,60
44.798,00
44.916,00
18.103,40
1.400,60
452,80
392,40
345,40
IC (95%)
124,75
183,38
201,51
90,10
19,05
6,77
9,56
15,72
Admisses (n)
97.147,60
44.798,00
44.916,00
18.103,40
1.400,60
452,80
392,40
345,40
IC (95%)
124,75
183,38
201,51
90,10
19,05
6,77
9,56
15,72
Admisses (%)
100,00
100,00
100,00
100,00
100,00
100,00
100,00
100,00
207.556,20
185,63
207.556,20
185,63
100,00
Trminos (n)
8.242,20
44.591,40
44.672,60
17.942,80
1.338,60
416,40
364,20
329,00
IC (95%)
71,29
191,10
171,05
74,87
12,74
11,70
17,89
13,05
Trminos (%)
Tempo Med Resp (s)
8,48
598,98
99,54
40,54
99,46
42,22
99,11
61,05
95,57
78,52
91,96
97,61
92,81
75,88
95,25
55,64
IC (95%)
11,12
11,81
19,25
11,38
10,84
30,78
27,10
21,47
117.897,20
60,36
0,159%
56,80
84,11
Rejeio
(U - A) / U
8,27
0,00%
Tabela 6.7: Algoritmo WFQ (maximizando vendas)
Comparando-se os resultados aos obtidos com o algoritmo RR, alguns pontos destacam-se:
O nmero de vendas concludas melhorou 1614%, passando de 19,2 para 329

pedidos. Isso elevou o ndice de Eficincia de 0,009% para 0,159%;
O tempo mdio de resposta s requisies passou de 305,9s para 84,11s. Uma

queda de 72,5%. No entanto, as requisies do tipo Principal so extremamente
penalizadas, uma vez que o WFQ atende menos sesses, mas garante o atendimento
das iniciadas at a concluso da venda;
O throughput diminuiu de 128,23 req/s para 122,81 req/s. Uma queda de 4,2%. Isso
ocorreu dada a nova distribuio de requisies atendidas pelo sistema. So
77
atendidas mais requisies com maior custo de processamento, como dos tipos
Buscas e Detalhes.
O ndice de Rejeio manteve-se zerado, pois no foi considerado nenhum mecanismo de
controle de admisso, ou seja, todas as requisies so admitidas pelo sistema.
Como o WFQ inicia o atendimento a novas sesses apenas quando pode garantir o
atendimento a todos os seus pedidos subseqentes, as requisies da categoria Principal so
penalizadas. Isso faz com que o tempo de resposta a essas requisies cresa
consideravelmente ao longo da simulao. Para os demais tipos de requisies, pode-se
considerar que o tempo cresce de maneira equivalente. Isso pode ser observado no grfico da
Figura 6.2:
1500
1400
1300
1200
1100
1000
900
800
700
600
500
400
300
200
100
0
240
340
440
540
640
740
840
940
1040
1140
1240
Principal
Categorias
Buscas
Detalhes
Login
Entrega
Pagamento
Confirmao
Figura 6.2: Algoritmo WFQ
Apesar de todas as melhorias obtidas com a insero do algoritmo WFQ no modelo, outros
mecanismos de diferenciao de servios ainda so necessrios para o SWDS. Essa
necessidade fica clara quando analisado o tempo mdio de resposta s requisies que,
mesmo com a reduo, ainda permanece elevado. Assim, em seguida so apresentados os
78
resultados dos experimentos com a insero de mecanismos de controle de admisso no

modelo SWDS.
6.3.3 Algoritmo RR com Controle de Admisso por Tamanho de Fila

Com o objetivo de reduzir o tempo mdio de resposta s requisies, foi inserido, no
modelo SWDS, o mecanismo de Controle de Admisso (CA) por tamanho de fila. O mdulo
CA recebe a informao do tamanho mdio das filas dos ns do cluster de servidores Web a
cada requisio que chega ao servidor. Se o tamanho mdio exceder o valor definido pelo
administrador do sistema, a requisio ser rejeitada pelo SWDS. Para os experimentos a
seguir, o tamanho mximo mdio das filas foi definido em 1024 requisies.

225,41
Requisies
Principal
Categorias
Buscas
Detalhes
Login
Entrega
Pagamento
Confirmao
Total
Requisies
Principal
Categorias
Buscas
Detalhes
Login
Entrega
Pagamento
Confirmao
Total
Eficincia
(C / U)
IC (95%)
0,19
Throughput (req/s)
128,62
IC (95%)
0,04
Chegadas (n)
97.049,60
53.467,00
53.502,40
11.710,80
505,00
89,40
44,80
22,40
IC (95%)
174,50
56,55
88,41
76,63
30,33
21,41
13,64
7,68
Admisses (n)
58.602,00
29.042,40
29.122,80
6.341,80
279,20
47,20
24,20
12,00
216.391,40
182,82
123.471,60
Trminos (n)
58.621,60
29.086,40
29.063,80
6.339,60
275,80
47,80
23,80
12,00
IC (95%)
131,13
117,81
91,11
55,93
33,74
14,94
9,01
3,93
123.470,80
41,06
0,006%
Util. CPU (%)

100,00
IC (95%)
87,18
108,74
66,75
82,18
29,92
13,78
9,35
6,02
Admisses (%)
60,38
54,32
54,43
54,15
55,29
52,80
54,02
53,57
40,57
57,06
Trminos (%)
Tempo Med Resp (s)
100,03
79,78
100,15
79,77
99,80
79,81
99,97
79,78
98,78
79,78
101,27
79,66
98,35
79,74
100,00
79,72
100,00
IC (95%)
0,00
79,79
Rejeio
(U - A) / U
IC (95%)
0,02
0,02
0,03
0,03
0,07
0,14
0,14
0,29
0,02
42,94%
Tabela 6.8: Algoritmo RR com CA por tamanho de fila
Conforme informaes da Tabela 6.8, observa-se que o tempo mdio de resposta foi
79
reduzido com sucesso, caindo de 305,9s (algoritmo RR sem o uso do Controle de Admisso)
para 79,79s. De acordo com o grfico da Figura 6.3, esse tempo mdio de resposta se mantm
constante ao longo da simulao, uma caracterstica bastante interessante do uso do CA.
No entanto, o ndice de Rejeio foi de 42,94%, indicando que uma parcela representativa
das requisies no foi admitida pelo sistema. Isso necessrio para que a situao de
sobrecarga no leve a um aumento progressivo no tempo mdio de resposta, inviabilizando o
uso do sistema.
O ndice de Eficincia manteve-se muito baixo, em 0,006%, dado que no foi utilizado
nenhum tipo de controle que focasse na concluso dos processos de venda. O CA descarta as
requisies Web, independentemente do tipo, quando o tamanho mdio das filas dos ns do
cluster de servidores Web atinge o mximo definido, no priorizando requisies com
maiores probabilidades de gerar venda. A poltica de atendimento das filas tambm no
oferece nenhum tipo de privilgio s requisies, pois segue a disciplina FCFS.
1500
1400
1300
1200
1100
1000
900
800
700
600
500
400
300
200
100
0
240
340
440
540
640
740
840
940
1040
1140
1240
Principal
Categorias
Buscas
Detalhes
Login
Entrega
Pagamento
Confirmao
Figura 6.3: Algoritmo RR com CA por tamanho de fila

Assim, visando melhorar o ndice de Eficincia do SWDS, foi inserido no mdulo CA um
80
mecanismo de descarte seletivo de requisies. Quando as filas dos servidores Web atingem
95% do tamanho mximo permitido, dado incio a um processo de descarte que leva em
considerao o tipo da requisio que chega ao sistema.
Para a definio do critrio de descarte, foram calculadas as probabilidades que cada tipo
de requisio tem de gerar uma venda. Esses dados foram obtidos dadas as probabilidades de
transio de um estado para outro da mquina de estados da Figura 5.3. A seguir
apresentado o sistema de equaes que representa essas probabilidades:
A
-0,5B
+0,605B
-0,345B
-0,415B
-0,203B
-0,5C
-0,345C
+0,605C
-0,415C
-0,203C
-0,2D
-0,2D
+D
-0,19D
-0,075E
+0,945E
-0,333F
+F
-0,95G
+G
-0,95H
+H
=
=
=
=
=
=
=
=
0
0
0
0
0
0
0
1
Resolvendo-se o sistema de equaes, obtm-se os valores apresentados na Tabela 6.9.

A = Principal
B = Categorias
C = Buscas
D = Detalhes
E = Login
F = Entrega
G = Pagamento
H = Confirmao
5,7%
5,7%
5,7%
7,4%
35,7%
90,3%
95%
100%
Tabela 6.9: Probabilidade de cada estado gerar venda
Analisando a tabela, observou-se que, como no h desistncia por parte dos compradores
entre a movimentao do estado Principal aos estados Categorias ou Buscas, a probabilidade
desses estados gerarem venda a mesma. No entanto, para a definio do critrio de descarte,
foi considerado que os clientes nos estados Categorias ou Buscas esto um passo a frente dos
clientes que esto no estado Principal no processo de compra. Dessa forma, ao atingir 95% do
tamanho das filas dos servidores, o sistema inicia o processo de descarte de requisies do
tipo Principal apenas. Se esse procedimento no for suficiente para conter a sobrecarga do
81
sistema, ao atingir 100% do tamanho limite para as filas, o sistema descarta as requisies
sem levar em considerao o tipo.
Conforme informaes da Tabela 6.10, a insero do mecanismo de admisso seletiva no
SWDS mostrou-se promissor. O tempo mdio de resposta e o ndice de Rejeio variaram
muito pouco em relao ao mecanismo de CA por tamanho de fila comum. Entretanto, houve
uma melhora expressiva do ndice de Eficincia, que evoluiu de 0,006% para 0,158%. Uma
melhora de 0,152 pp. Por outro lado, houve uma sensvel queda no throughput, gerando uma
diminuio de 4,6% na quantidade de requisies atendidas pelo SWDS. Isso ocorreu dada a
nova distribuio de requisies atendidas pelo sistema. So atendidas mais requisies com
maior custo de processamento, como dos tipos Buscas e Detalhes.

215,82
Requisies
Principal
Categorias
Buscas
Detalhes
Login
Entrega
Pagamento
Confirmao
Total
Requisies
Principal
Categorias
Buscas
Detalhes
Login
Entrega
Pagamento
Confirmao
Total
Eficincia
(C / U)
IC (95%)
0,36
Throughput (req/s)
122,72
IC (95%)
0,05
Util. CPU (%)

100,00
IC (95%)
0,00
Chegadas (n)
96.855,20
44.686,00
44.720,40
18.262,80
1.430,80
458,40
411,00
362,80
IC (95%)
361,02
188,24
113,24
65,06
74,58
25,29
19,69
22,03
Admisses (n)
7.481,60
44.686,00
44.720,40
18.262,80
1.430,80
458,40
411,00
362,80
IC (95%)
46,06
188,24
113,24
65,06
74,58
25,29
19,69
22,03
Admisses (%)
7,72
100,00
100,00
100,00
100,00
100,00
100,00
100,00
207.187,40
343,12
117.813,80
51,99
56,86
Trminos (n)
7.292,20
44.869,20
44.943,40
18.188,60
1.369,60
434,20
384,40
326,60
117.808,20
IC (95%)
40,53
234,97
127,92
33,42
64,55
22,46
18,84
19,66
45,73
Trminos (%)
Tempo Med Resp (s)
97,47
79,39
100,41
79,45
100,50
79,48
99,59
79,46
95,72
79,38
94,72
79,35
93,53
79,41
90,02
79,40
100,00
0,158%
79,46
Rejeio
(U - A) / U
IC (95%)
0,03
0,03
0,03
0,03
0,03
0,09
0,03
0,06
0,03
43,14%
Tabela 6.10: Algoritmo RR com CA seletivo
82
Para conter a sobrecarga, o sistema precisou descartar apenas requisies do tipo Principal.
Foram admitidas 7,72% das sesses que solicitaram atendimento ao servidor. No entanto, no
foi explorado todo o potencial de venda das sesses aceitas, pois no so atendidas 100% das
requisies subseqentes (que possuem maiores probabilidades de gerar venda).
Apesar de funcionarem de maneiras diferentes, h uma grande semelhana entre os
resultados obtidos com a insero do mecanismo de admisso seletiva e os resultados obtidos
com a insero do algoritmo WFQ. Isso ocorre dado que os dois mtodos possuem o mesmo
objetivo: garantir que todas as sesses iniciadas sejam atendidas at o final pelo sistema. O
WFQ busca seu objetivo alterando o funcionamento das filas dos servidores, priorizando ou
penalizando requisies, enquanto que o mecanismo de admisso seletiva opera no mdulo
CA, aceitando ou rejeitando as requisies que chegam ao sistema.
6.3.4 Algoritmo WFQ com Controle de Admisso por Tamanho de Fila

Com o intuito de aprimorar o atendimento do SWDS, foi alterada a poltica de atendimento
utilizada nas filas (FCFS), que no leva em considerao nenhum tipo de diferenciao de
servios, com a insero do algoritmo WFQ. Os critrios para o CA foram mantidos, inclusive
o mecanismo de admisso seletiva e o tamanho das filas em 1024 posies.
Como o mecanismo de admisso seletiva j trabalha com o objetivo de aprimorar o
desempenho do SWDS descartando novas sesses em caso de sobrecarga, a fim de garantir o
atendimento completo das sesses j aceitas pelo sistema, a definio dos pesos a serem
utilizados para o WFQ nesse experimento seguiu nova abordagem.
Foram atribudos maiores pesos s requisies com maiores probabilidades de gerar venda,
conforme dados da Tabela 6.9. Mais uma vez, considerou-se que os clientes nos estados
Categorias ou Buscas esto um passo a frente dos clientes que esto no estado Principal, no
processo de compra. Assim, os pesos foram definidos aumentando-se progressivamente em
83
5% a prioridade das requisies com maiores probabilidades de gerar venda. Os pesos so

apresentados na Tabela 6.11.
A = Principal
B = Categorias
C = Buscas
D = Detalhes
E = Login
F = Entrega
G = Pagamento
H = Confirmao
Probabilidades
de venda
5,7%
5,7%
5,7%
7,4%
35,7%
90,3%
95%
100%
Pesos
1,00
1,05
1,05
1,10
1,15
1,20
1,25
1,30
Tabela 6.11: Pesos para o WFQ com CA seletivo
De acordo com as informaes da Tabela 6.12, a incluso do algoritmo WFQ trouxe

benefcios ao sistema.
Os indicadores de throughput, rejeio e tempo mdio de resposta permaneceram
praticamente inalterados (sensvel melhora) se comparados aos dados do experimento com a
utilizao do algoritmo RR. No entanto, houve uma importante evoluo no ndice de
Eficincia, que passou de 0,158% para 0,205%. Isso ocorreu devido ao avano na quantidade
de concluses de vendas, onde o aumento foi de 29,9%.
Nessa configurao, o sistema prioriza as requisies com maiores probabilidades de gerar
venda e, dessa forma, impulsiona as sesses que esto em estgios mais avanados. Em
decorrncia disso, o tempo mdio de resposta das requisies com maiores probabilidades de
gerar venda so menores.
O sistema precisou descartar apenas requisies do tipo Principal para conter a sobrecarga,
conforme dados da tabela apresentada. Foram admitidas ao sistema 7,75% das sesses que
solicitaram atendimento ao servidor e, praticamente 100% das requisies subseqentes,
foram concludas. Essa a vantagem desse mecanismo em relao ao mecanismo que utiliza o
84
algoritmo RR.

215,98
Requisies
Principal
Categorias
Buscas
Detalhes
Login
Entrega
Pagamento
Confirmao
Total
Requisies
Principal
Categorias
Buscas
Detalhes
Login
Entrega
Pagamento
Confirmao
Total
Eficincia
(C / U)
IC (95%)
0,28
Throughput (req/s)
122,82
IC (95%)
0,10
Util. CPU (%)

100,00
IC (95%)
0,00
Chegadas (n)
96.949,60
44.662,20
44.749,20
18.211,60
1.422,20
473,20
450,40
423,60
IC (95%)
269,47
111,59
257,62
167,98
39,81
32,07
32,30
25,15
Admisses (n)
7.509,60
44.662,20
44.749,20
18.211,60
1.422,20
473,20
450,40
423,60
IC (95%)
41,19
111,59
257,62
167,98
39,81
32,07
32,30
25,15
Admisses (%)
7,75
100,00
100,00
100,00
100,00
100,00
100,00
100,00
207.342,00
266,58
117.902,00
93,91
56,86
Trminos (n)
7.525,60
44.654,40
44.740,40
18.208,80
1.424,80
474,20
450,40
424,20
117.902,80
IC (95%)
41,80
110,48
258,43
169,84
38,21
32,69
32,30
24,43
92,49
Trminos (%)
Tempo Med Resp (s)
100,21
161,58
99,98
77,99
99,98
77,35
99,98
60,73
100,18
43,62
100,21
26,11
100,00
6,56
100,14
4,14
100,00
0,205%
79,25
Rejeio
(U - A) / U
IC (95%)
2,64
0,79
0,86
1,13
5,66
9,68
4,36
3,21
0,07
43,14%
Tabela 6.12: Algoritmo WFQ com CA seletivo
O grfico da Figura 6.4 ilustra o funcionamento desse mecanismo apresentando a evoluo

dos tempos de resposta s requisies ao longo do tempo de simulao. Ao contrrio do que
ocorre no algoritmo RR, quando todos os tipos de requisies recebem o mesmo tratamento,
nesse caso so privilegiadas as requisies em estgios mais avanados no processo de
compra.
Com o objetivo de se reduzir o tempo mdio de resposta s requisies, esse experimento
foi repetido alterando-se, no Controle de Admisso, o tamanho mdio das filas para 300
posies.
85

1500
1400
1300
1200
1100
1000
900
800
700
600
500
400
300
200
100
0
240
340
440
540
640
740
840
940
1040
1140
1240
Principal
Categorias
Buscas
Detalhes
Login
Entrega
Pagamento
Confirmao
Figura 6.4: Algoritmo WFQ com CA por tamanho de fila e admisso seletiva
Conforme dados apresentados na Tabela 6.13, o tempo mdio de resposta foi reduzido
significativamente para 23,42s, enquanto que os demais indicadores permaneceram
praticamente inalterados.
O tempo mdio de resposta das requisies com maiores
probabilidades de gerar venda so menores, o que mostra tambm que o comportamento do

sistema foi mantido.

Neste captulo foram propostos mecanismos de diferenciao de servios e controle de
admisso que consideram as caractersticas das requisies web para melhorar o desempenho
do SWDS. Esses mecanismos, por meio de modificaes nas disciplinas de atendimento das
filas dos servidores e critrios de preveno de sobrecarga, buscam benefcios ao sistema, de
acordo com os objetivos estabelecidos. Foi apresentado tambm um modelo de otimizao
linear que auxilia na parametrizao do algoritmo de diferenciao de servios WFQ.
86

216,07
Requisies
Principal
Categorias
Buscas
Detalhes
Login
Entrega
Pagamento
Confirmao
Total
Requisies
Principal
Categorias
Buscas
Detalhes
Login
Entrega
Pagamento
Confirmao
Total
Eficincia
(C / U)
IC (95%)
0,26
Throughput (req/s)
122,88
IC (95%)
0,11
Util. CPU (%)

100,00
IC (95%)
0,00
Chegadas (n)
97.071,00
44.681,40
44.644,80
18.189,60
1.462,60
481,60
459,40
435,40
IC (95%)
166,64
129,04
276,22
137,34
70,04
31,20
35,94
40,79
Admisses (n)
7.609,60
44.681,40
44.644,80
18.189,60
1.462,60
481,60
459,40
435,40
IC (95%)
68,25
129,04
276,22
137,34
70,04
31,20
35,94
40,79
Admisses (%)
7,84
100,00
100,00
100,00
100,00
100,00
100,00
100,00
207.425,80
248,61
117.964,40
100,71
56,87
Trminos (n)
7.618,60
44.676,60
44.640,00
18.187,00
1.464,20
484,20
460,20
435,80
117.966,60
0,210%
IC (95%)
66,83
128,02
278,26
137,65
69,01
33,03
38,92
41,06
106,74
Trminos (%)
Tempo Med Resp (s)
100,12
34,83
99,99
23,92
99,99
23,62
99,99
18,86
100,11
13,35
100,54
12,54
100,17
11,18
100,09
4,56
100,00
23,42
Rejeio
(U - A) / U
IC (95%)
2,78
2,20
2,58
10,66
9,25
8,78
8,57
5,25
0,02
43,13%
Tabela 6.13: Algoritmo WFQ com CA Seletivo (reduzindo fila)
Diversas simulaes foram realizadas e os resultados obtidos mostram que a explorao

das caractersticas das requisies web, alm de ser fundamental para um bom entendimento
do comportamento do servidor, possibilita uma melhoria significativa de performance do
sistema.
No prximo captulo apresentada uma viso geral do trabalho desenvolvido. Em seguida,
so descritas as concluses, destacando-se os principais resultados e contribuies desta
dissertao.
87
7
Concluses
7.1 Viso Geral

O objetivo central da pesquisa desenvolvida foi avaliar a possibilidade de se melhorar o
desempenho do modelo de Servidor Web com Diferenciao de Servios (SWDS), quando
so consideradas as caractersticas das requisies Web nas polticas de atendimento.
Durante o desenvolvimento do trabalho, optou-se por adotar o contexto do comrcio
eletrnico para a realizao das pesquisas, uma vez que esse ambiente um dos mais
impactados negativamente quando h um comportamento ruim do servidor em situaes de
sobrecarga.
Assim, tendo escolhido o ambiente de comrcio eletrnico, foi realizada uma investigao
das caractersticas das requisies Web tpicas do e-commerce, para que tais caractersticas
pudessem ser usadas para se melhorar o desempenho do modelo SWDS.
Em seguida, foi proposto um modelo de carga de trabalho e um modelo de simulao para
a realizao dos experimentos. Com isso, foi possvel avaliar os resultados obtidos com a
insero de diversos mecanismos de diferenciao de servios no SWDS.
Foram propostos novos mecanismos de escalonamento de requisies e tambm novos
mecanismos de controle de admisso. Diversas simulaes foram realizadas e os resultados
88
obtidos mostram que a explorao das caractersticas das requisies web, alm de ser
fundamental para um bom entendimento do comportamento do servidor, possibilita a
melhoria de desempenho do sistema.
7.2 Resultados e Contribuies

As principais contribuies e resultados deste trabalho so apresentados a seguir:
1. Reviso Bibliogrfica - Foi apresentada uma viso geral da infra-estrutura da Internet

e da World Wide Web, sendo discutidas suas caractersticas e protocolos. Alm disso,
foi realizada tambm a descrio das formas de organizao e funcionamento dos
servidores Web. Em seguida, foram discutidos os problemas atuais da Internet e as
vantagens da insero de qualidade de servio na rede. A abordagem de servios
diferenciados sobre redes IP e a viabilidade de seu emprego em nvel de aplicao,
particularmente em servidores Web, foram destacados. Na seqncia, foi apresentado
o modelo SWDS. Foi descrita a sua arquitetura e discutidos alguns algoritmos de
controle de admisso e diferenciao de servios. Para finalizar a reviso bibliogrfica,
foram apresentadas algumas tcnicas de avaliao de desempenho.
2. Modelo e Gerao da Carga de Trabalho - Com base em trabalhos relacionados, um

modelo de carga de trabalho para e-commerce foi desenvolvido considerando-se os
principais tipos de requisies que caracterizam uma loja virtual. Utilizando o modelo
desenvolvido, gerou-se uma carga sinttica para a realizao dos experimentos.
3. Alteraes no Modelo SWDS - Foi realizado um detalhamento do SWDS para que

fossem consideradas no modelo as caractersticas que causam os maiores impactos no
89
desempenho do sistema. No caso de um servidor Web, os consumos de CPU e de

operaes de I/O. Assim, no modelo proposto cada n do cluster servidor modelado
com um recurso que representa o consumo de CPU e outro que representa o consumo
de I/O. Essa modificao permite um melhor entendimento do funcionamento do
servidor, bem como a identificao de gargalos e pontos de melhoria.
4. Novas Polticas de Escalonamento - Foram propostas e inseridas no modelo SWDS

novas polticas de escalonamento para a realizao da diferenciao de servios com
base nas caractersticas das requisies Web. Essas polticas utilizam como base o
algoritmo WFQ e so comparadas s polticas que no utilizam qualquer tipo de
priorizao no escalonamento das requisies. O algoritmo WFQ capaz de dividir a
capacidade de processamento dos ns do cluster entre os diversos tipos de requisies,
de acordo com os pesos que a eles so atribudos. Assim, essa caracterstica foi
explorada tanto para priorizar o atendimento s sesses j admitidas pelo sistema,
quanto para priorizar o atendimento s requisies com maiores probabilidades de
gerar venda. Para a definio dos pesos a serem utilizados pelo algoritmo WFQ, foi
proposto um modelo de otimizao linear que leva em considerao os objetivos do
negcio.
5. Novas Polticas de Controle de Admisso - Foram propostas e inseridas no modelo

SWDS novas polticas de controle de admisso para a realizao da diferenciao de
servios com base nas caractersticas das requisies Web. Essas polticas utilizam
como base o tamanho mdio das filas dos servidores Web no critrio de admisso ou
rejeio da requisio. Foi proposto tambm um mecanismo de admisso seletivo, que
considera a probabilidade de gerar venda dos diversos tipos de requisio no processo
90
decisrio.
A seguir, apresentada uma tabela que sintetiza os principais resultados obtidos com a
insero dos mecanismos de diferenciao de servios no modelo SWDS.
Configurao
Chegadas (n)
Admisses (n)
ndice de
Rejeio
Trminos (n)
Vendas
Concludas (n)
ndice de
Eficincia
Tempo Med
Resposta (s)
RR
215.851,40
215.851,40
0,00%
123.098,60
19,20
0,009%
305,90
WFQ
(max. atendimentos)
227.362,80
227.362,80
0,00%
134.178,80
0,00
0,000%
109,89
WFQ
(max. vendas)
207.556,20
207.556,20
0,00%
117.897,20
329,00
0,159%
84,11
RR - CA Fila
216.391,40
123.471,60
42,94%
123.470,80
12,00
0,006%
79,79
RR - CA Seletivo
207.187,40
117.813,80
43,14%
117.808,20
326,60
0,158%
79,46
WFQ - CA Seletivo
207.342,00
117.902,00
43,14%
117.902,80
424,20
0,205%
79,25
WFQ - CA Seletivo
( fila reduzida )
207.425,80
117.964,40
43,13%
117.966,60
435,80
0,210%
23,42
Tabela 7.1: Resultados obtidos
Na Tabela 7.1, foram destacados em cor verde os resultados tidos como melhores casos e
em vermelho os piores casos para diversos critrios de comparao. A seguir, seguem
algumas explicaes para os resultados em realce:
Nmero de chegadas e trminos: o caso com o maior nmero de chegadas de

requisies no sistema foi obtido com a utilizao do algoritmo WFQ, configurado para
maximizar o nmero de requisies atendidas. Isso ocorreu justamente porque o
servidor, nessa configurao, consegue atender o maior nmero de requisies, pois so
91
atendidas menos requisies de maior custo de processamento (Buscas, Detalhes e

Pagamentos). Essa caracterstica j era esperada, uma vez que as requisies atendidas
motivam a chegada de novas requisies, de acordo com o modelo de gerao de carga
de trabalho definido. O caso que apresentou o menor nmero de chegadas foi quando se
utilizou o algoritmo RR com controle de admisso seletivo. Pelo modelo de gerao de
carga de trabalho definido, esse caso coincide com o caso em que so atendidas menos
requisies. Isso ocorre porque so atendidas mais requisies de maior custo de
processamento, por influncia do critrio de admisso seletiva. Por conseqncia, so
admitidas menos requisies, o que eleva o ndice de rejeio.
Quantidade de requisies admitidas e ndice de rejeio: o melhor caso, quando foi

admitido o maior nmero de requisies, ocorreu fazendo-se uso do algoritmo WFQ
configurado para maximizar o nmero de requisies atendidas. A explicao est no
fato de no ter sido utilizado nenhum mecanismo de controle de admisso e tambm
por influncia do algoritmo WFQ, que eleva o nmero de requisies concludas e,
conseqentemente, o nmero de chegadas. A no utilizao de mecanismos de controle
de admisso influencia no ndice de rejeio, que se mantm zerado. Os piores ndices
de rejeio foram obtidos quando se utilizou o mecanismo de admisso seletiva, pois
so atendidas menos requisies, uma vez que o servidor conclui mais requisies com
maior custo de processamento.
Nmero de vendas concludas e ndice de eficincia: o pior caso foi verificado

quando utilizado o algoritmo WFQ configurado para maximizar o nmero de
requisies atendidas. Isso ocorre porque so aceitas muitas sesses no sistema e, por
conseqncia, poucas so concludas. O melhor caso ocorreu com o uso do algoritmo
92
WFQ e controle de admisso seletivo, pois so priorizadas as requisies com maior

probabilidade de gerar venda e o trmino das sesses admitidas pelo sistema.
importante destacar que foram obtidas evolues muito relevantes no ndice de
eficincia utilizando-se mecanismos que penalizam sensivelmente outras mtricas.
Tempo mdio de resposta: o pior caso verificou-se com o algoritmo RR, quando no
foi utilizado nenhum mecanismo de controle de admisso. Nessa configurao,
admitido o maior nmero de requisies com maior custo ao sistema, o que gera filas
maiores e, por conseguinte, maiores tempos de resposta. O melhor caso ocorreu quando
foi utilizado o algoritmo WFQ com controle de admisso seletivo e reduo do tamanho
da fila. Essa reduo a responsvel pela queda no tempo de resposta.
7.3 Trabalhos Futuros

A seguir, so apresentadas algumas sugestes de trabalhos futuros:
Anlise do custo de processamento do algoritmo WFQ em ambientes reais, para que

possa ser feito um estudo da relao custo benefcio de sua utilizao na prtica;
Estudo e aprimoramento do modelo de otimizao linear apresentado para auxiliar

na parametrizao do algoritmo WFQ, de acordo com os objetivos do negcio. Esse
modelo pode ser testado para outros perfis de comportamento de usurios, a fim de
explorar melhor os benefcios trazidos por ele e entender suas limitaes;
Insero de outros algoritmos de diferenciao de servios e mecanismos de

controle de admisso que possam aprimorar o desempenho do modelo SWDS e que
93
levem em considerao, alm das caractersticas das requisies web, outras

informaes relevantes do sistema;
Elaborao de mecanismos que induzam o usurio a percorrer caminhos menos

custosos ao servidor em um fluxo de compra no site de comrcio eletrnico. Isso
poderia, por exemplo, reduzir requisies do tipo Buscas e ampliar o nmero de
requisies do tipo Categorias, que so, em geral, menos custosas.
94
Referncias
Andreolini, M.; Casalicchio, E.; Colajanni, M.; Mambelli, M. (2004). A cluster-based web
system providing differentiated and guaranteed services. Cluster Computing, v.7, n.1, p.7
19.
Arlitt, M. (2000). Characterizing web user sessions. SIGMETRICS Perform. Eval. Rev., v.28,
n.2, p.5063.
Barbato, A. K.; Santana, R. H. C.; Traldi, O. A.; Santana, M. J.; Teixeira, M. A. M. (2005).
Avaliao de Polticas de Controle de Admisso para Servidores Web com Servios
Diferenciados. XIII Simpsio Internacional de Iniciao Cientfica da Universidade de
So Paulo (SIICUSP), So Carlos, Brasil.
Barbato, A. K. (2008). Polticas para servidores Web baseados em sesses visando qualidade
e diferenciao de servios. Dissertao de Mestrado, Instituto de Cincias Matemticas e
de Computao - Universidade de So Paulo.
Berners-Lee, T.; Fielding, R.; Frystyk, H. (1996). Hypertext Transfer Protocol - HTTP/1.0.
RFC 1945, IETF.
Blake, S.; Black, D.; Carlson, M.; Davies, E.; Wang, Z.; Weiss, W. (1998). An Anchitecture
for Dierentiated Services. RFC 2475, IETF.
Borenstein, N. (1993). MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms
for Specifying and Describing the Format of Internet Message Bodies. RFC 1521,IETF.
Braden, R.; Clark, D.; Shenker, S. (1994). Integrated Services in the Internet Architecture.
RFC 1633, IETF.
Braden, R.; Zhang, L.; Berson, S.; Herzog, S.; Jamin, S. (1997). Resource ReSerVation
Protocol (RSVP) - Version 1 Functional Specification. RFC 2205, IETF.
Cardellini, V.; Casalicchio, E.; Colajanni, M.; Mambelli, M. (2001). Web switch support for
differentiated services. SIGMETRICS Perform. Eval. Rev., v.29, n.2, p.1419.
Casalicchio, E.; Colajanni, M. (2001). A client-aware dispatching algorithm for web clusters
providing multiple services. In Proceedings of the 10th international Conference on World
Wide Web, p. 535{544, New York, NY. ACM Press.
Comer, D. E. (2000). Internetworking with TCP/IP: Principles, Protocols and Architecture.
Prentice Hall, 4. edio.
95
Coulouris, G.; Dollimore, J.; Kindberg, T. (2000). Distributed Systems: Concepts and Design.
Addison-Wesley, 3. edio.
E-Bit (2007). Informaes do Comrcio Eletrnico. Web Shoppers, 17. edio.
Estrella, J. C.; Teixeira, M. A. M.; Santana, M. J.; Santana, R. H. C.; Bruschi, S. M. (2006).
Negotiation mechanisms on application level: A new approach to improve quality od
service in web servers. WCCIA The 2nd International Workshop on Colaborative
Computing, Integration and Assurance, p. 255-259. IEEE Proceedings.
Ferrari, D.; Serazzi, G.; Zeigner, A. (1983). Measurement and Tuning of Computer Systems.
Prentice Hall.
Fielding, R.; Gettys, J.; Mogul, J.; Frystyk, H.; Masinter, L.; Leach, P.; Berners-Lee, T.
(1999). Hypertext Transfer Protocol - HTTP/1.1. RFC 2616, IETF.
Fishwick, P. A. (2004). SimPackJ: Version 1.0. University of Florida. Disponvel em
http://www.cise.ufl.edu/~fishwick/simpackj
Francs, C. R. L. (1998). Stochastic Feature Charts: Uma Extenso Estocstica para os
Statecharts. Dissertao de Mestrado, Instituto de Cincias Matemticas e de Computao
- Universidade de So Paulo.
G. B. Dantzig, Maximization of a linear function subject to linear inequalities, in T. C.
Koopmans (ed.), Activity Analysis of Production and Allocation, John Wiley & Sons,
New York, 1951, pp. 339347.
Goldberg, A.; Buff, R.; Schmitt, A. (1998). Secure web server performance dramatically
improved by caching ssl session keys. Workshop on Internet Server Performance.
Hofmann, R.; Klar, R.; Mohr, B.; Quick, A.; Single, M. (1994). Distributed Performance
Monitoring: Methods, Tools and Applications, vol. 5, 6 ed. IEEE Transactions on Parallel
Distributed Systems.
Internet Traffic Archive (1998). World Cup web site access logs. Disponvel em
<http://ita.ee.lbl.gov/html/contrib/WorldCup.html>. Acesso em 14 nov. 2008.
Jain, R. (1991). The Art of Computer Systems Performance Analysis - Techniques for
Experimental Design, Measurement, Simulation and Modeling. Wiley - Interscience, New
York, NY.
Kant, K.; Mohapatra, P. (2000). Scalable Internet servers: Issues and challenges. Proceedings
of the Workshop on Performance and Architecture of Web Servers (PAWS). ACM
SIGMETRICS.
Kilkki, K. (1999). Differentiated Services for the Internet. Macmillan Publishing.
96
Kurose, J. F.; Ross, K. W. (2006). Rede de Computadores e a Internet: uma abordagem topdown. Addison Wesley, So Paulo.
Lee, S. C. M.; Lui, J. C. S.; Yau, D. K. Y. (2002). Admission control and dynamic adaptation
for a proportional-delay diffserv-enabled web server. Proceedings of the 2002 ACM
SIGMETRICS Conference on Measurement and Modeling of Computer Systems.
Leon, H. P.; Bissett, S.; Rollin, P.; Ressler, M. (2008). osCommerce - Open Source ECommerce Solutions. Disponvel em: <http://www.oscommerce.org>. Acesso em: 14 nov.
2008.
MacDougall, M. H. (1987). Simulating Computer Systems Techniques and Tools. The MIT
Press.
Magalhes, M. F.; Cardozo, E. (1999). Qualidade de servio na Internet. Relatrio tcnico,
UNICAMP/FEEC/DCA, Campinas, SP.
Menasc, D. A.; Almeida, V. A.; Fonseca, R.; Mendes, M. A. (1999). A methodology for
workload characterization of E-commerce sites. In Proceedings of the 1st ACM
Conference on Electronic Commerce. EC '99. ACM, New York, NY.
Microsoft Office Excel (2003). Microsoft Office Professional Edition. Microsoft Corporation.
MySQL (2008). Sun Microsystems. Disponvel em <http://www.mysql.com>. Acesso em 14
nov. 2008.
Orfali, R.; Harkey, D.; Edwards, J. (1999). Client/Server Survival Guide. John Wiley, 3.
edio.
Postel, J. (1980). User Datagram Protocol. RFC 768, IETF.
Postel, J. (1981a). Internet Control Message Protocol. RFC 792, IETF.
Postel, J. (1981b). Internet Protocol. RFC 791, IETF.
Postel, J. (1981c). Transmission Control Protocol. RFC 793, IETF.
Sabo, C. P. (2006). Avaliao de desempenho com algoritmos de escalonamento em clusters
de servidores Web. Dissertao de Mestrado, Instituto de Cincias Matemticas e de
Computao - Universidade de So Paulo.
Santana, M. J. (1990a). Advanced Filestore Architeture for a Multiple-Lan Distributed
Computing System. Phd thesis, University of Southamptom.
Santana, R. H. C. (1990b). Performance Evaluation of Lan-Based File Server. Phd thesis,
97
University of Southamptom.
Santana, R. H. C.; Santana, M. J.; Francs, C. R. L.; ORLANDI, R. C. G. S. (1997). Tool and
Methodologies for Performance Evaluation of Distributed Computing System - A
Comparison Study. In: The proceedings of the 1997, Portland, Oregon, USA.
Soares, L. F. G. (1990). Modelagem e Simulao Discreta de Sistemas. So Paulo: VII Escola
de Computao.
SPECweb2005 (2005). SPECweb2005 E-Commerce Workload Design Document. Disponvel
em: <http://www.spec.org/web2005>. Acesso em 14 nov. 2008.
Stardust (1999a). White Paper QoS protocols & architectures. Disponvel em http:
//www.qosforum.com
Stardust (1999b). White Paper
http://www.qosforum.com
The
need
for
QoS.
Disponvel
em
Tanenbaum, A. S. (2002). Computer Networks. Prentice Hall, 4. edio.

Teixeira, M. A. M. (2004). Suporte a Servios Diferenciados em Servidores Web: Modelos e
Algoritmos. Tese de doutorado, Instituto de Cincias Matemticas e de Computao Universidade de So Paulo.
Teixeira, M. A. M.; Santana, M. J.; Santana, R. H. C. (2005). Servidor Web com
Diferenciao de Servios: Fornecendo QoS para os Servios da Internet. XXIII Simpsio
Brasileiro de Redes de Computadores (SBRC), Fortaleza, CE.
Traldi, O. A. (2005). Servidor web com diferenciao de servios e algoritmo weighted fair
queuing adaptativo (wfqadap). Monografia de concluso de curso, Instituto de Cincias
Matemticas e de Computao - Universidade de So Paulo.
Traldi, O. A.; Barbato, A. K.; Santana, R. H. C.; Santana, M. J.; Teixeira, M. A. M. (2006).
Service differentiating algorithms for qos-enabled web servers. WebMedia06:
Proceedings of the 12th Brazilian symposium on Multimedia and the web, p. 263272,
New York, NY, USA. ACM Press.
Vasiliou, N.; Lutfiyya, H. (2000). Providing a differentiated quality of service in a World
Wide Web server. ACM SIGMETRICS Performance Evaluation Review, v.28, n.2, p.22
28.
W3C (1999a). HTML 4.01 specification. Disponvel em <http://www.w3c.org/TR/html4>.
Acesso em 14 nov. 2008.
W3C
(1999b).
HTTP
1.1
specification.
Disponvel
<http://www.w3.org/Protocols/rfc2616/rfc2616.html>. Acesso em 14 nov. 2008.
em
98
W3C (2000). XHTML 1.0 The Extensible HyperText Markup Language. Disponvel em
<http://www.w3c.org/TR/html>. Acesso em 14 nov. 2008.
Wei, Y.; Lin, C.; Ren, F.; Dutkiewicz, E.; Raad, R. (2003). Session based differentiated
quality of service admission control for web servers. ICCNMC 03: Proceedings of the
2003 International Conference on Computer Networks and Mobile Computing, p. 112.
IEEE Computer Society.
Xiao, X.; Ni, L. M. (1999). Internet QoS: a big picture. IEEE Network.
Yeager, N. J.; McGrath, R. E. (1996). Web Server Technology: the Advanced Guide for
World Wide Web Information Providers. Morgan Kaufmann.
Zhao, W.; Olshefski, D.; Schulzrinne, H. (1999). Internet quality of service: an overview.
IEEE Network.
99

Ottone PDF

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Ottone PDF

Enviado por

Direitos autorais:

Formatos disponíveis

__________________________________________

Polticas de atendimento para servidores

SERVIO DE PS-GRADUAO DO ICMC-USP

Data de Depsito: 17/11/2008

Polticas de atendimento para servidores Web com

Ottone Alexandre Traldi

Orientador: Prof. Dr. Marcos Jos Santana

Dissertao apresentada ao Instituto de Cincias Matemticas e de

* Agradecimento ao CNPq pelo apoio parcial dado a este trabalho.

Dedico este trabalho a minha famlia e amigos,

Este trabalho prope mecanismos de diferenciao de servios para

foram realizadas e os resultados obtidos mostram que a explorao das

This work proposes differentiated services mechanisms for Web servers,

As Camadas da Arquitetura TCP/IP ......................................................................

Exemplo de Requisio e Resposta HTTP ............................................................

Servidor Web com Diferenciao de Servios (SWDS) ........................................

Hierarquia das Tcnicas de Avaliao de Desempenho ........................................

Modelo simplificado do Servidor Web com Diferenciao de Servios (SWDS)

Modelo do Cluster de Servidores Web ..................................................................

Compradores Ocasionais (Menasc et al., 1999) ...................................................

Compradores Freqentes (Menasc et al., 1999) ...................................................

Mquina de Estados (Menasc et al., 1999) ...........................................................

Cenrio utilizado para a realizao de experimentos .............................................

Algoritmo Round-Robin .........................................................................................

Algoritmo WFQ .....................................................................................................

Algoritmo RR com CA por tamanho de fila ..........................................................

Algoritmo WFQ com CA por tamanho de fila e admisso seletiva .......................

Mtodos definidos pelo protocolo HTTP ...............................................................

Classes de cdigo de status das respostas HTTP ...................................................

Carga mdia gerada ao sistema por cada sesso ....................................................

Valores obtidos COM o recurso de cache no cliente .............................................

Valores obtidos SEM o recurso de cache no cliente ..............................................

Taxas de acerto em cache no cliente ......................................................................

Algoritmo Round-Robin .........................................................................................

Tempos mdios de CPU - considerando acertos em cach .................................... 74

Pesos obtidos para o WFQ (maximizando atendimentos) .....................................

Algoritmo WFQ (maximizando atendimentos) .....................................................

Pesos obtidos para o WFQ (maximizando vendas) ...............................................

Algoritmo WFQ (maximizando vendas) ................................................................

Algoritmo RR com CA por tamanho de fila ..........................................................

Probabilidade de cada estado gerar venda .............................................................

Algoritmo RR com CA seletivo ...........................................................................

Pesos para o WFQ com CA seletivo ....................................................................

Algoritmo WFQ com CA seletivo .......................................................................

Algoritmo WFQ com CA Seletivo (reduzindo fila) .............................................

Resultados obtidos .................................................................................................

Lista de Siglas e Abreviaturas

6.2 Metodologia para Experimentos ............................................................................... 67

trfego tratado de maneira uniforme, sem nenhum tipo de diferenciao ou de priorizao.

Investigao das caractersticas das requisies Web;

Realizao de um detalhamento do modelo SWDS considerando-se os recursos

Desenvolvimento de novas polticas de escalonamento que considerem o tipo das

Desenvolvimento de novas polticas de controle de admisso que considerem os tipos

Insero das polticas desenvolvidas em um modelo de simulao do Servidor Web

Diferenciao de Servios, o SWDS. Ser descrita a sua arquitetura e tambm sero

2.1 Consideraes Iniciais

(Transmission Control Protocol) e o IP (Internet Protocol) so os protocolos mais

2.2.1 Protocolos TCP/IP

2.2.2 A Arquitetura TCP/IP

Figura 2.1: As Camadas da Arquitetura TCP/IP

Camada de Acesso Rede

e providencia o roteamento da mensagem de um dispositivo para outro, em uma rede local ou

O protocolo UDP no orientado conexo e oferece um servio no-confivel. O UDP