Geraldo

Modelo de Servidor Web com Quatro Mdulos de
Atendimento de Requisies (SWMAR)

Geraldo Guiesi Junior
________________________________________________________
ii
SERVIO DE PS-GRADUAO DO ICMC-USP
Data de Depsito: 28.02.2008

Assinatura:________________________
Modelo de Servidor Web com Quatro Mdulos de

Atendimento de Requisies (SWMAR)
Geraldo Guiesi Junior
Orientadora: Prof. Dr. Regina Helena Carlucci 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 de Computao e Matemtica Computacional.
USP - So Carlos
Fevereiro/2008
iii
iv
Dedico este trabalho ao meu filho

Pedro, que me motiva a sempre
tentar alcanar maiores objetivos
para conseguir o mnimo que ele
merece.
vi
Agradecimentos
Agradeo aos meus pais, Geraldo e Telma, pela educao, por estarem presentes em
todos os momentos difceis e felizes da minha vida, pela confiana que depositam sempre em
mim, pela preocupao, pelo apoio financeiro, enfim, por tudo.
professora Regina Santana, pela orientao nesses ltimos anos e pelos
conhecimentos transmitidos durante o mestrado.
professora Sarita por sempre estar disposta a me ajudar.
Ao professor Marcos Santana, pelas crticas e opinies seguras.
Aos amigos do LaSDPC, Jlio, Luis, Lucas, Fbio, Valter, Augusto, Marcelo e
Ottone, pela ajuda e por proporcionarem um ambiente de trabalho alegre.
A todos, que mesmo indiretamente, contriburam para a concluso deste mestrado.
Ao CNPq, pelo apoio financeiro dado a este trabalho.
vii
viii
RESUMO
Esta dissertao de mestrado apresenta a implementao e validao de

um modelo de servidor web que divide o funcionamento de o servidor web
em quatro mdulos onde cada um desses mdulos responsvel por uma
etapa que a requisio percorre ao longo de seu processamento. Esses
mdulos so: atendimento da requisio (mdulo 1), transferncia do
arquivo para a memria principal (mdulo 2), processamento de
requisies dinmicas (mdulo 3) e envio do arquivo ao cliente (mdulo
4). Esses quatro mdulos so interligados e so alimentados
primeiramente por uma carga inicial gerada pelo gerador de cargas
W4Gen e passa obrigatoriamente, nessa ordem, pelo mdulo 1, mdulo 2
e mdulo 4. O mdulo 3 s utilizado quando se trata de uma requisio
dinmica. Ao ser atendido por um dos mdulos, atribudo um tempo de
execuo (leia-se tempo que a requisio toma para ser processada por
esse mdulo). Esses tempos foram baseados em trabalhos que fizeram
benchmarks em servidores web reais. Os resultados alcanados com o
desenvolvimento deste trabalho visam principalmente integrar-se aos
trabalhos de simulao envolvendo servidores web do grupo de Sistemas
Distribudos e Programao Concorrente (LaSDPC) e com isso alcanar
resultados prximos a resultados aplicados em servidores web reais.
ix
Abstract
This work presents the implementation and validation of a web server
model that divides the web server functions into four modules and each
one of these is responsible for an execution step, in which a request goes
through during processing. These modules are: request serving (module
1); file transferring to the main memory (module 2); dynamic request
processing (module 3); and client file sending (module 4). These four
modules are linked and the W4Gen generates the initial loads. These loads
run in the order as follows: modules 1, 2 and 4. The module 3 is used only
when the request is dynamic. When a request is served by a module, an
execution time is defined (i.e. the time used by the request in the module),
which is based on real world web servers benchmarks. The results
obtained in the work aims to be integrated to other projects conduced in
the Distributed System and Concurrent Programming group (LaSDPC) in
order to reach results close to real world web servers.
xi
xii
Sumrio
Lista de Figuras ................................................................................................................ vi
Lista de Tabelas ............................................................................................................... vii
Lista de Abreviaturas.................................................................................................... viii
1.
INTRODUO.................................................................................................................1
1.1.
1.2.
1.3.
1.4.
2.
CONTEXTUALIZAO ...................................................................................................1
MOTIVAO ................................................................................................................2
OBJETIVOS ...................................................................................................................3
ESTRUTURA DA DISSERTAO .....................................................................................3
A INTERNET....................................................................................................................5
2.1.
CONSIDERAES INICIAIS ............................................................................................5
2.2.
MODELO DE REFERNCIA ISO/OSI E PROTOCOLO TCP/IP ..........................................6
2.2.1
Camada de Aplicao .........................................................................................7
2.2.2
Camada de Transporte .......................................................................................8
2.2.3
Camada de Rede .................................................................................................9
2.2.4
Camada de Enlace ............................................................................................10
2.2.5
Camada Fsica ..................................................................................................11
2.3.
A WORLD WIDE WEB ................................................................................................11
2.4.
PROTOCOLO HTTP ....................................................................................................12
2.5.
CONSIDERAES FINAIS .............................................................................................16
3.
ANLISE DE DESEMPENHO E SIMULAO .......................................................17

3.1.
CONSIDERAES INICIAIS ..........................................................................................17
3.2.
CARGA DE TRABALHO ................................................................................................18
3.3.
MTRICAS ..................................................................................................................18
3.4.
MTODOS DE AVALIAO DE DESEMPENHO TCNICAS DE AFERIO ....................19
3.4.1
Benchmarks.......................................................................................................19
3.4.2
Monitoramento..................................................................................................20
3.5.
MTODOS DE AVALIAO DE DESEMPENHO TCNICAS DE MODELAGEM ...............21
3.5.1
Simulao..........................................................................................................21
3.5.2
Soluo Analtica (Teoria de Filas)..................................................................22
3.6.
CONSIDERAES FINAIS ............................................................................................23
4.
SERVIDORES WEB ......................................................................................................25

4.1.
4.2.
FUNES DO SERVIDOR WEB.....................................................................................25
4.3.
ARQUITETURA DOS SERVIDORES WEB ........................................................................26
4.3.1
Requisies Estticas........................................................................................27
4.3.2
Requisies Dinmicas .....................................................................................28
4.4.
SESSES HTTP ..........................................................................................................30
4.5.
ESTRUTURA INTERNA DOS SERVIDORES WEB .............................................................31
xiii
4.5.1
Tratamento de Requisies TCP.......................................................................31
4.5.2
Pool de Threads HTTP .....................................................................................31
4.5.3
Envio de Arquivos Requisitados .......................................................................32
4.5.4
Descarga de Buffers de Sada...........................................................................33
4.6.
5. MODELO DE SERVIDOR WEB COM QUATRO MDULOS DE
ATENDIMENTO DE REQUISIES (SWMAR) .............................................................35
5.1.
5.2.
TRABALHOS RELACIONADOS .....................................................................................35
5.2.1
Modelos de Servidores Web..............................................................................36
5.2.2
Anlise de Servidores Web ...............................................................................37
5.3.
W4GEN......................................................................................................................39
5.3.1
Cdigo de Resposta ..........................................................................................40
5.3.2
Classe de Objeto ...............................................................................................41
5.3.3
Intervalo de Chegada........................................................................................42
5.3.4
Tamanho de Objeto...........................................................................................43
5.3.5
Arquivo Resultante............................................................................................43
5.4.
SIMPACK ....................................................................................................................45
5.5.
MODELO DE SERVIDOR WEB COM QUATRO MDULOS DE ATENDIMENTO DE
REQUISIES (SWMAR).......................................................................................................46
5.5.1
Mdulo 1: Atendimento de Requisies HTTP.................................................48
5.5.2
Mdulo 2: Transferncia de Arquivos Memria Principal ...........................48
5.5.3
Mdulo 3: Script Engine Execuo de Requisies Dinmicas ....................50
5.5.4
Mdulo 4: Envio de Dados ...............................................................................51
5.5.5
Estimativa e Tempos de Servio .......................................................................53
5.5.6
Entrada de Dados .............................................................................................57
5.5.7
Sada de Dados .................................................................................................59
5.6.
6.
ANLISE DE RESULTADOS ......................................................................................61

6.1.
6.2.
6.3.
7.
CONCLUSO .................................................................................................................73
7.1.
7.2.
7.3.
8.

CARACTERSTICAS GERAIS DE SIMULAO ...............................................................61
CONTRIBUIES.........................................................................................................74
SUGESTES PARA TRABALHOS FUTUROS ...................................................................75
REFERNCIAS BIBLIOGRFICAS..........................................................................77
xiv
LISTA DE FIGURAS
FIGURA 2.1 - CAMADAS, PROTOCOLOS E INTERFACES ..................................................................6
FIGURA 2.2- CAMADA DE APLICAO (KUROSE; ROSS, 2003) ................................................8
FIGURA 2.3 - CAMADA DE TRANSPORTE (KUROSE; ROSS, 2003)..............................................9
FIGURA 2.4 - CAMADA DE REDE (KUROSE; ROSS, 2003)........................................................10
FIGURA 2.5 - CAMADA DE ENLACE (KUROSE; ROSS, 2003) ...................................................11
FIGURA 2.6 - ESQUEMA DO PROTOCOLO URL............................................................................12
FIGURA 2.7 - COMPARAO ENTRE A VERSO 1.0 (A) E 1.1 (B) DO PROTOCOLLO HTTP............14
FIGURA 2.8 - REQUISIO HTTP. ..............................................................................................14
FIGURA 2.9 - RESPOSTA HTTP. .................................................................................................15
FIGURA 4.1 - TIPOS DE ARQUITETURA DE SERVIDORES WEB .......................................................26
FIGURA 4.2 - ESQUEMA CLIENTE-SERVIDOR NAS REQUISIES ESTTICAS ................................28
FIGURA 4.3 ESQUEMA CLIENTE-SERVIDOR DAS REQUISIES DINMICAS .................................30
FIGURA 4.4 - UM SERVIDOR HTTP DE UM PROCESSO POR CONEXO COM UM PROCESSO MESTRE.
..........................................................................................................................................32
FIGURA 4.5 - UM SERVIDOR DE UM NICO PROCESSO COM MLTIPLAS THREADS.......................32
FIGURA 5.1 GERAO DE REQUISIES COM CDIGO 200 W4GEN. ......................................40
FIGURA 5.2 - GERAO DE CDIGO DE STATUS BASEADO EM DISTRIBUIO W4GEN.............41
FIGURA 5.3 GERAO DE CLASSES OBJETOS SEGUNDO DISTRIBUIO GEOMTRICA...............41
FIGURA 5.4 GERAO DE CLASSES DE OBJETOS SEGUNDO VALORES DE INTERFACE................42
FIGURA 5.5 INTERVALO DE CHEGADA DAS CLASSES................................................................43
FIGURA 5.6 TAMANHO DE OBJETO DAS CLASSES. ....................................................................43
FIGURA 5.7 GERAO DE CARGA DE TRABALHO. ....................................................................44
FIGURA 5.8 EXEMPLO DE CARGA SINTTICA GERADA PELO W4GEN. ......................................44
FIGURA 5.9 FLUXOGRAMA DO SWMAR.................................................................................47
FIGURA 5.10 ESQUEMA DE ATENDIMENTO NO MDULO 1. ......................................................48
FIGURA 5.11 FLUXO DE REQUISIES NO MDULO 2...............................................................50
FIGURA 5.12 FLUXO DE REQUISIES NO MDULO 3...............................................................51
FIGURA 5.13 FLUXO DE REQUISIES DO MDULO 4...............................................................52
FIGURA 5.14 FUNCIONAMENTO DO ESVAZIAMENTO DE BUFFERS. ...........................................52
FIGURA 5.15 EXEMPLO DE DISTRIBUIO EXPONENCIAL. .......................................................56
FIGURA 6.1 CARACTERSTICAS DAS DIFERENTES CARGAS INICIAIS. ........................................62
FIGURA 6.2 CARACTERSTICAS DOS TRS TIPOS DE LOGS. .......................................................63
FIGURA 6.3 UTILIZAO DOS MDULOS. ................................................................................64
FIGURA 6.4 RESULTADO DE ALTERAO DE PARMETROS DO MDULO 1 - TRADICIONAL. ....64
FIGURA 6.5 - RESULTADO DE ALTERAO DE PARMETROS DO MDULO 1 ACADMICO........65
FIGURA 6.6 - RESULTADO DE ALTERAO DE PARMETROS DO MDULO 1
INFORMATIVO/NOTCIAS....................................................................................................65
FIGURA 6.7 THROUGHPUT E TEMPOS DE SIMULAO TRADICIONAL. ...................................66
FIGURA 6.8 THROUGHPUT E TEMPOS DE SIMULAO ACADMICO.......................................66
FIGURA 6.9 THROUGHPUT E TEMPOS DE SIMULAO INFORMATIVO/NOTCIA. .....................67
FIGURA 6.10 RESULTADO DE ALTERAO DOS PARMETROS DE HARDWARE PARA LOG
TRADICIONAL.....................................................................................................................68
FIGURA 6.11 RESULTADO DE ALTERAO DOS PARMETROS DE HARDWARE PARA LOG
ACADMICO. ......................................................................................................................68
FIGURA 6.12 - RESULTADO DE ALTERAO DOS PARMETROS DE HARDWARE PARA LOG
INFORMATIVO/NOTCIAS. ...................................................................................................68
FIGURA 6.13 PORCENTAGEM DE UTILIZAO DOS MDULOS LOG TRADICIONAL..................69
FIGURA 6.14 PORCENTAGEM DE UTILIZAO DOS MDULOS LOG ACADMICO. ...................69
xv
FIGURA 6.15 PORCENTAGEM DE UTILIZAO DOS MDULOS LOG INFORMATIVO/NOTCIA...69

FIGURA 6.16 THROUGHPUT LOG TRADICIONAL. ..................................................................70
FIGURA 6.17 THROUGHPUT LOG ACADMICO......................................................................71
FIGURA 6.18 THROUGHPUT LOG INFORMATIVO/NOTCIA. ...................................................71
xvi
LISTA DE TABELAS
Tabela 1 Camadas e funes do modelo OSI .........................................................................7
Tabela 2 Mtodos e funes existentes nas mensagens de requisio do protocolo http 1.1
.......................................................................................................................................15
Tabela 3 Cdigos de resposta do protocolo HTTP 1.1 .........................................................16
Tabela 4 Classificao de tempos de acordo com as classes de objetos................................54
Tabela 5 Tempos de utilizao do CPU no processamento de requisies...........................56
Tabela 6 Cenrios de simulao com alterao de parmetros do Mdulo 1........................66
Tabela 7 Cenrios de testes com alteraes de parmetros de hardware...............................69
xvii
xviii
LISTA DE ABREVIATURAS
ARPA
CGI
CISC
CPU
DNS
DoD
FCFS
FTP
HTML
HTTP
Httpd
IETF
IP
ISO
JSP
LCFS-PR
MFLOPS
MIPS
MSS
OSI
PPP
QoS
RFC
RISC
RR
RTT
SE
SMTP
TCP
UDP
WWW
Advanced Research Projects Agency

Commom Gateway Interface
Complex Instruction Set Computing
Unidade central de processamento
Domain Name System
Departamento de Defesa
First Come, First Served
File Transfer Protocol
Hyper Text Markup Language
Protocolo de Transferncia de Hipertexto
daemon http
Internet Engineering Task Force
Internet Protocol
International Organization for Standardization
Java Server Pages
First Come, First Served with Preempt and Resume
Million FLoating-point Operations Per Second
Millions of instructions per second
Maximal Segment Size
Open System Interconnection
Point-to-Point Protocol
Qualidade de Servio
Request for Comments
Reduced (or regular) instruction set computer
Round-Robin
Round Trip Time
Script Engine
Simple Mail Transfer Protocol
Transmission Control Protocol
User Datagram Protocol
World Wide Web
xix
xx
CAPTULO
1. Introduo
1.1. Contextualizao
A popularidade da World Wide Web, tambm chamada WWW ou simplesmente Web,
tem aumentado significativamente nos ltimos anos. Em dezembro de 1992, o trfego da WWW
era praticamente inexistente, sendo no total de apenas 74MB por ms no backbone da rede
NSFNET (ARLITT; WILLIAMSON, 1997). Hoje, o trfego WWW um dos componentes
dominantes da Internet (GILDER, 1997).
Algumas explicaes para o crescimento exponencial da Internet so: o fcil uso da Web
mediante a disponibilidade de interfaces grficas para a navegao e para a visualizao de
documentos; a existncia de editores e ferramentas de suporte para criao e publicao de
documentos Web; crescente tendncia entre pesquisadores, educadores, instituies, e
organizaes comerciais em usar a Internet para disseminar informaes timely fashion1; a
independncia de localidade dos documentos Web que podem ser referenciados livremente; e um
contnuo crescimento exponencial no nmero de hosts e usurios da Internet (ARLITT;
WILLIAMSON, 1997).
Acompanhado com o crescimento da Web veio o surgimento de novas utilizaes que
geraram problemas no enfrentados com as aplicaes originais. Esses problemas aconteceram
pelo fato da Internet passar, de uma rede para fins de pesquisa, restrita a rgos governamentais
e instituies acadmicas onde o trfego era baseado em documentos textuais, para atualmente
utilizar um dos mais importantes meios de comunicao, para fins informativos, educacionais,
comerciais e entretenimento.
Informaes publicadas em tempo real.
Hoje na Internet trafegam, alm de documentos textuais, documentos multimdia (vdeos

e udios). Segundo (COMER, 2000) h a tendncia de convergncia da Internet com outras
redes, como as de telefonia, rdio e TV, o que tende a piorar ainda mais o problema.
Outro fato que afeta o desempenho da Web est relacionado arquitetura da Internet.
Sem administrao centralizada e escalonvel, a Internet permite a insero de dispositivos
clientes heterogneos, o que aumenta a necessidade de autenticao e sistemas de segurana para
o funcionamento de tais dispositivos clientes. O aumento de autenticao e segurana est
atrelado ao aumento da complexidade do middleware 2e das aplicaes software (CARDELLINI
et al., 2002).
Como conseqncia de tais problemas surge um aumento do trfego, das cargas nos
servidores web e, devido a esses problemas, no nmero de recusas de atendimento e falha de
envio de resposta. Esses problemas podem ser atribudos, em parte, ao aumento de carga nos
servidores web graas mudana de contedos suportados, passando de pginas estticas para
pginas dinmicas e tambm ao crescimento desproporcional da capacidade das redes com
relao aos servidores web (GRAY; SHENOY, 2000).
Essa defasagem sofrida pelos servidores web so visveis aos usurios finais, que sofrem
com uma queda na qualidade do servio oferecido, ou QoS3 na Web.
1.2. Motivao
Em um ambiente Web, um usurio no se importa com gargalos no trfego, servidores
sobrecarregados, capacidade total da rede4, entre outros efeitos. Alm do contedo, os usurios
exigem desempenho, disponibilidade e segurana (MENASC; ALMEIDA, 2003).
Como soluo para a queda na qualidade dos servios oferecidos na Web, no incio eram
feitas atualizaes tanto nos meios de rede quanto nos prprios servidores web (DEVLIN et al.,
1999). Mas essa tcnica simplesmente expande a capacidade do sistema pela adio de mais
recursos, resolvendo apenas temporariamente o problema. Essa tcnica no muito apropriada
porque, alm de inutilizar os servidores antigos demandavam muitos recursos financeiros para a
aquisio de novos equipamentos (CPU, disco, interface de disco) (CARDELLINI et al., 2002).
2
Software de interface que permite interao de diferentes aplicaes de softwares, geralmente sobre diferentes
plataformas de hardware e infra-estrutura, para troca de dados.
3
Quality of Service.
4
Bandwidth
Com a capacidade das redes crescendo mais rapidamente que o previsto pela lei de
5
Moore , os servidores web tornam-se o gargalo da Web sendo que recentes medies mostram
que 40% do atraso na Web so de responsabilidade das transaes que acontecem nos servidores
web (HIUTEMA, 2000).
Uma forma de avaliar os servidores web, visando encontrar a melhor proposta para
atender crescente demanda pelos servidores web, a utilizao de modelos de servidores web.
Esses modelos podem responder perguntas especulativas tais como: qual ser o comportamento
do servidor web se um determinado componente interno foi acrescido, ou se for feita alguma
alterao na poltica de esvaziamento dos buffers de sada de dados.
Este projeto foi motivado justamente pela capacidade das tcnicas de modelagem em
responder s perguntas e se e tambm pela capacidade de integrar outros projetos em
desenvolvimento no grupo de sistemas distribudos do ICMC da USP como (TEIXEIRA, 2004)
e (ESTRELLA, 2005) podendo substituir os servidores web utilizados nesses projetos,
modelados como caixas-pretas, por modelos de servidores mais detalhados.
1.3. Objetivos
O objetivo do projeto apresentado nesta monografia desenvolver um modelo de
servidor web, baseado em SANT ANNA (2004), onde sejam modelados componentes internos
responsveis pelo tratamento das conexes desde o estabelecimento da conexo at o envio da
resposta ao cliente. E como foi dito anteriormente, integrar outros projetos do grupo de Sistemas
Distribudos e Programao Concorrente (LaSDPC).
Esse modelo deve considerar tanto requisies estticas quanto requisies dinmicas,
protocolo HTTP 1.1.
1.4. Estrutura da Dissertao

Esta dissertao dividida em 7 captulos. No captulo 1 foi introduzido o tema de
trabalho a ser desenvolvido, identificando a contextualizao, a motivao e os objetivos a serem
alcanados durante o mestrado.
A capacidade dos computadores dobra a cada 18 meses.
No captulo 2 sero apresentadas a Internet e a Web, conceitos importantes para situar o

leitor no contexto onde os servidores web trabalham. Nesse captulo sero explicados os
protocolos TCP/IP e suas camadas e HTTP, alm de apresentar os conceitos relacionados a Web.
No captulo 3 sero apresentados conceitos envolvidos na avaliao de desempenho e
simulao. Conceitos muito importantes para o desenvolvimento do projeto.
No captulo 4 sero apresentadas caractersticas dos servidores web e tcnicas de
simulao desses elementos da Web. Nesse captulo, so mostradas as caractersticas das
arquiteturas disponveis de servidores web e as aplicaes relativas a Web. Ainda nesse captulo,
so apresentados alguns modelos da literatura que simulam servidores web. Dentre esses
modelos so destacados os descritos em (SANT ANNA, 2004), (MEI, 2001) e (DILLEY et al.,
2000).
No captulo 5 apresentado o modelo desenvolvido e trabalhos relacionados que
serviram de base, inspirao e que contriburam de alguma forma para a construo do modelo.
No captulo 6 so apresentados testes em nove cenrios utilizando trs tipos de logs como
carga inicial gerados pelo W4Gen (SILVA, 2006) e so apresentados resultados desses testes.
E, finalmente, so apresentadas as referncias bibliogrficas utilizadas para a elaborao
desta dissertao.
CAPTULO
2. A Internet
2.1. Consideraes Iniciais
No alto da Guerra Fria o Departamento de Defesa (DoD) necessitava de uma rede de
comunicao que, mesmo em caso de um ataque nuclear continuasse funcionando. At ento, a
comunicao era feita inteiramente atravs da rede pblica de telefone. Para resolver esse
problema foi criada a ARPA (Advanced Research Projects Agency), baseada em pesquisas
desenvolvidas por diversos especialistas, dentre eles Larry Roberts que props a ARPANET. A
ARPANET surgiu em 1967 tornou-se o backbone da Internet (COMER, 2000).
A ARPANET usava comunicao ponto-a-ponto, alm de fazer troca de pacotes entre
diferentes redes como: a de telefonia, a rede de rdio e canais de comunicao de satlites. No
incio a ARPANET era utilizada apenas para fins de pesquisa pelo fato que os ns da ARPANET
eram localizados em algumas instituies acadmicas e por isso eram muito utilizados por
pesquisadores do meio acadmico. Apesar da integrao da ARPANET havia o problema de no
haver um protocolo padro. Em 1983, para solucionar esse problema foi adotado o protocolo
TCP/IP (SOCOLOFSKY; KATE, 1997), aceito principalmente por causa da verso Berkley
UNIX que, alm de ter incluso o protocolo TCP/IP o colocou em situao de domnio pblico
possibilitando a alterao e desenvolvimento de aplicaes.
Com a abertura do protocolo TCP/IP surgiram comits e rgos que participavam da
criao e divulgao de tecnologias e novos protocolos, destacando o IETF, que at hoje
responsvel pela manuteno e apoio aos padres de Internet e TCP/IP (principalmente atravs
dos documentos conhecidos como RFC). Tais documentos descrevem diversos protocolos e
servem de base para novas tecnologias. Tais fatores foram de vital importncia para o
crescimento e adeso de novos ns para a Internet.
2.2. Modelo de referncia ISO/OSI e Protocolo TCP/IP

Para reduzir a complexidade, muitas redes de comunicao so organizadas como uma
pilha de camadas ou nveis, cada uma construda sobre a anterior. O nmero de camadas, o nome
e o contedo de cada camada diferem de rede para rede. O propsito de cada camada oferecer
certos servios para camadas superiores, acobertando para uma camada como foi provido um
determinado servio. Outro aspecto importante das camadas o fato que uma camada n de uma
mquina s tem a possibilidade de se comunicar com a camada n de outra mquina como visto
na figura 2.1. As regras e contenes usadas nessa comunicao so conhecidas como protocolo
da camada n (TANENBAUM, 2003). Um protocolo um acordo entre as partes em
comunicao de como a informao ser processada. A quebra de protocolo pode tornar a
comunicao difcil quando no impossvel.
Figura 2.1 - Camadas, protocolos e interfaces
A comunicao entre as camadas de mesmo nvel so demonstradas nas figuras 2.2, 2.3,
2.4, 2.5. Essas figuras representam a comunicao entre os nveis equivalentes.
Em 1997 a ISO (International Organization for Standardization) tomou o primeiro passo

para a padronizao internacional dos protocolos de diferentes camadas (Tanenbaum, 2003). O
modelo foi chamado ISO OSI (Open System Interconnection) Reference Model ou simplesmente
OSI.
O modelo OSI tem sete camadas, que so apresentadas na tabela 3
Camada
Aplicao
Apresentao
Sesso
Transporte
Rede
Enlace
Fsica
Funo
Contm uma variedade de protocolos comumente usados
pelo usurio.
Camada responsvel com a sintaxe e a semntica da
informao transmitida.
Permite que usurios de diferentes mquinas estabeleam
sesses de comunicao.
Sequenciamento, confirmao e recebimento de pacotes.
Roteamento de dados atravs da rede.
Formatao de informao em quadros.
Conexo fsica entre o sistema operacional e a rede.
Tabela 1 Camadas e funes do modelo OSI
Uma camada de protocolo pode ser implementada em software, em hardware, ou em uma

combinao dos dois. Protocolos de camada de aplicao como HTTP (POSTEL, 1981) e SMTP
(Simple Mail Transfer Protocol) (POSTEL, 1982) quase sempre so implementados em
software. O mesmo acontece com protocolos de camada de transporte. Como a camada fsica e a
camada de enlace de dados so responsveis pelo manuseio da comunicao por um enlace
especfico, normalmente so implementadas em placas de interface de rede. J a camada de rede
geralmente implementada de forma mista, hardware e software.
O primeiro modelo de referncia foi o Modelo de Referncia TCP/IP, definido em
(CERF; KAHN, 1974). O protocolo TCP/IP o que est atualmente em uso. As camadas e as
caractersticas desse modelo so apresentadas a seguir.
2.2.1 Camada de Aplicao

Nessa camada residem aplicaes de rede e seus protocolos. Ela inclui diversos
protocolos, tais como: o protocolo HTTP, prov requisio e transferncia de documentos pela
Web; o SMTP prov transferncia de mensagens de correio eletrnico; o FTP (File Transfer
Protocol) (POSTEL, 1985), prov transferncia de arquivos entre dois sistemas finais e o DNS
(Domain Name System) (POSTEL, 1984), utilizado para resolver domnios de acordo com o IP
(Internet Protocol) (POSTEL, 1981) (KUROSE; ROSS, 2003).
Na figura 2.2 exemplificada a comunicao entre as camadas de aplicao.
Figura 2.2- Camada de Aplicao (KUROSE; ROSS, 2003)
2.2.2 Camada de Transporte

Onde so transportadas mensagens da camada de aplicao entre os lados do cliente e
servidor de uma aplicao. Os protocolos de transporte na Internet: TCP e UDP. O TCP oferece
servios orientados conexo para suas aplicaes, alm de possuir garantia de mensagens da
camada de aplicao ao destino e controle de fluxo, fragmenta mensagens longas em fragmentos
mais curtos e prov controle de congestionamento. J o protocolo UDP no prov servio no
orientado conexo.
Na figura 2.2 exemplificada a comunicao entre as camadas de transporte.
Figura 2.3 - Camada de transporte (KUROSE; ROSS, 2003)
2.2.3 Camada de Rede

A camada de rede a responsvel pela movimentao de pacotes entre as mquinas,
tambm chamados de datagramas. Essa camada possui dois componentes principais: o protocolo
que define os campos no datagrama e o protocolo de roteamento. No protocolo que define os
campos do datagrama, tanto os sistemas finais quanto os roteadores agem nesses campos, o
protocolo IP. E o protocolo de roteamento determina as rotas que os datagramas seguem entre
origem e destino. Embora a camada de rede contenha o protocolo IP (POSTEL, 1981) tambm
numerosos protocolos de roteamento, ela quase sempre denominada simplesmente camada IP.
O protocolo da camada de transporte da Internet (TCP ou UDP) em uma mquina de
origem passa um segmento de camada de transporte e um endereo de destino camada de rede.
Essa camada prov o servio de entrega do segmento camada de transporte na mquina
destinatria.
A figura 2.4 esquematiza o roteamento sofrido por um datagrama na camada de
transporte.
Figura 2.4 - Camada de rede (KUROSE; ROSS, 2003)
2.2.4 Camada de Enlace

A camada de rede da Internet roteia um datagrama por meio de uma srie de comutadores
de pacotes entre a origem e o destino. Para levar um pacote de um n ao n seguinte na rota, a
camada de rede passa o datagrama para a camada de enlace que o entrega, ao longo da rota, ao
n seguinte. No n destino o datagrama passado da camada de enlace para a de rede.
Os servios prestados pela camada de enlace dependem do protocolo especifico
empregado nessa camada. Alguns protocolos provem entrega garantida entre enlace, at o n
receptor. Note que esse servio confivel de entrega diferente do servio de entrega garantida
do TCP, que prov servio de entrega garantida de um sistema final a outro. Exemplos de
protocolos de camada de enlace so Ethernet e PPP (point-to-point protocol protocolo ponto-aponto) (SIMPSON, 1994). Como datagramas normalmente precisam transitar por diversos
enlaces para percorrer o caminho desde a origem at o destino estes podem ser manuseados por
diferentes protocolos de camada de enlace em diferentes enlaces ao longo de sua rota, como
visto na figura 2.5. Em alguns casos, podem, por exemplo, ser manuseados por Ethernet em um
enlace e por PPP no seguinte. Assim, a camada de rede receber um servio diferente de cada um
10
dos variados protocolos de camada de enlace. Os pacotes de camada de enlace so denominados

quadros (TANENBAUM, 2003).
Figura 2.5 - Camada de enlace (KUROSE; ROSS, 2003)
2.2.5 Camada Fsica

Enquanto a tarefa de camada de enlace movimentar quadros inteiros de um elemento da
rede at um elemento adjacente, a camada fsica responsvel por movimentar os bits
individuais que esto dentro do quadro de um n para o seguinte. Os protocolos nessa camada
dependem do enlace e, alm disso, dependem do prprio meio de transmisso do enlace (par de
fios tranados ou fibra tica monodal). A Ethernet tem muitos protocolos de camada fsica: um
para par de fios tranados, um para cabo coaxial, um outro para fibra e assim por diante. Em
cada caso, o bit movimentado pelo enlace de um modo diferente.
2.3. A World Wide Web

At a dcada de 1990, a Internet era usada por pesquisadores, acadmicos e estudantes
universitrios para se interligar com hospedeiros remotos, transferir arquivos de hospedeiros
locais para hospedeiros remotos e vice-versa, enviar e recebe notcias e enviar e receber correio
11
eletrnico. Embora essas aplicaes fossem (e continuem sendo) extremamente teis, a Internet
no era conhecida fora das comunidades acadmicas e de pesquisa. No incio da dcada de 1990,
entrou em cena uma nova aplicao A World Wide Web (BERNERS-LEE, 1994). A Web a
aplicao da Internet que chamou a ateno do pblico em geral. Ela transformou
significantemente a maneira como pessoas interagem dentro e fora de seus ambientes de
trabalho. Alou a Internet de apenas mais uma entre muitas redes de dados (X.25 e redes frame
relay) para, essencialmente, a nica rede de dados. (KUROSE; ROSS, 2003).
O funcionamento da Web baseado no paradigma cliente-servidor (TANENBAUM,
1995) onde h uma estrutura de interligao entre os documentos. Essa estrutura permite que um
documento referencie outro que pode estar distribudo geograficamente (em outras mquinas na
Internet). Do ponto de vista do usurio, a Web consiste de uma vasta coleo de documentos, ou
pginas, que podem conter links para outras pginas relacionadas. Para visualizar as pginas so
utilizados programas chamados browsers, que merecem crdito pelo crescimento no nmero de
usurios devido interface grfica disponvel, que em um clique, pode levar o usurio a um novo
documento (ARLITT; WILLIAMSON, 1997).
Figura 2.6 - Esquema do protocolo URL.
As pginas so referenciadas usando o URL (Uniform Resource Locators). O URL,

como mostrado na Figura 2.6, dividido em 5 partes: o protocolo utilizado, o nome do servidor
acessado atravs do DNS (MOCKAPETRIS, 1987), a porta pela qual o servidor recebe as
conexes (default porta 80), o diretrio onde o arquivo est armazenado e o nome do arquivo.
2.4. Protocolo HTTP

O protocolo de transferncia usado sobre a World Wide Web o HTTP (HyperText
Transfer Protocol). Ele especifica quais mensagens podem ser enviadas para o servidor e quais
respostas sero retornadas ao cliente. O protocolo HTTP estabelece uma conexo clienteservidor, transmite e recebe parmetros incluindo um arquivo retornado e encerra a conexo
12
cliente-servidor. Os servidores produzem contedo (pginas HTML) independente da plataforma

do cliente. Os browser so responsveis pelos detalhes especficos para o sistema. O protocolo
HTTP utiliza o TCP como protocolo de transporte.
Quando um cliente solicita uma pgina Web, o browser envia uma requisio HTTP de
objetos ao servidor que, por sua vez responde com uma mensagem de resposta HTTP que
contm os objetos. Existem vrias verses do protocolo HTTP. At 1997 a verso que dominava
era a HTTP/1.0 definida na RFC 1945 (BERNERS-LEE, 2000). A partir de 1998 alguns
servidores Web e browsers comearam a implementar a verso HTTP/1.1, definida na RFC 2616
(FIELDING ET AL., 1999). Para manter a compatibilidade, os servidores Web que rodam a
verso 1.1 conversam com os browsers que rodam verso 1.0 e um browser que roda a verso
1.1 pode conversar com um servidor que roda a verso 1.0.
O protocolo HTTP conhecido como protocolo sem estado (stateless) por no incluir o
conceito de sesso ou iterao alm da entrega do documento solicitado. No protocolo HTTP
original, uma conversao restrita transferncia de documentos e imagens, no mantendo
qualquer informao de requisies passadas. As duas verses do protocolo HTTP possuem
diferenas quanto ao tratamento das conexes aps o envio do contedo, como mostrado na
figura 2.7. Em ambas verses, a ordem seguida a seguinte: 1) estabelecida a conexo entre
cliente e servidor atravs do three hand shake (COMER, 2000); 2) o cliente envia a mensagem
HTTP de requisio HTML para o servidor; 3) o servidor envia uma mensagem de confirmao
de recebimento da requisio (ACK) 4) o servidor envia o contedo requisitado. A partir desse
ponto h divergncia entre as verses 1.0 e 1.1. Na 1.0, aps o envio do contedo, o servidor
envia uma mensagem para encerrar a conexo entre cliente e servidor (FIN). Com isso, se a
mesma pgina for requerida logo em seguida, ser efetuado todo o processo, desde o
estabelecimento da conexo, at a chegada do contedo para o cliente. J na verso 1.1 do
protocolo HTTP h a diferena de que a conexo pode ser mantida aberta (conexes persistentes)
por um tempo (timeout) na esperana que novas requisies sejam feitas para o mesmo servidor,
evitando o overhead de criar novamente a requisio.
13
Figura 2.7 - Comparao entre a verso 1.0 (a) e 1.1 (b) do protocollo HTTP.
O protoloco HTTP possui dois tipos de mensagens, as de requisio e as de resposta. Nas

requisies, (figura 2.8) a primeira linha est o mtodo HTTP a ser aplicado, a localizao do
objeto no servidor e a verso do protocolo. Alm dessas informaes, possvel saber o nome do
Figura 2.8 - Requisio HTTP.
servidor Web (linha 2), o tipo de browser utilizado pelo cliente (linha 4) e a linguagem padro do
cliente (linha 5). O campo connection responsvel pelas conexes persistentes, se o campo
estiver com valor close, mesmo sendo um cliente verso 1.1, a conexo ser fechada.
14
A tabela a seguir mostra alguns mtodos de requisio do protocolo HTTP.

Mtodos
GET
Funo
Solicita que seja retornado o recurso identificado pela
URL
HEAD
Obtm informaes sobre o recurso sem que o mesmo seja
retornado ao cliente. Testa a validade de links,
acessibilidade e a data da ltima modificao.
POST
Estabelece e encerra enlaces de comunicao.
OPTIONS Sequenciamento, confirmao, recebimento de pacotes de
dados.
PUT
Roteamento de pacotes atravs da rede.
DELETE
Formatao da informao em quadros
TRACE
Conexo fsica entre o sistema operacional e a rede.
CONNECT Conexo fsica entre o sistema operacional e a rede.
Tabela 2 Mtodos e funes existentes nas mensagens de requisio do protocolo http 1.1.
As mensagens de resposta seguem o padro mostrado na figura 2.9.
Figura 2.9 - Resposta HTTP.
Na primeira linha tem-se a verso do protocolo e um cdigo de status, no exemplo, a

solicitao foi completa com sucesso (cdigo 200). A linha connection, com o valor close, diz
que a conexo TCP ser fechada aps o trmino do envio da mensagem. Os trs campos
seguintes so informativos quanto a data e horrio da resposta, o tipo de servidor web, a ltima
atualizao do arquivo, o tamanho do arquivo e o tipo do documento (text/html).
O protocolo HTTP oferece uma lista com cdigos de status para os servidores web
informarem aos clientes o grau de sucesso obtido na tentativa de atender uma requisio. As
classes de cdigos de respostas podem ser observados na tabela 3.
15
Classes
1xx
2xx
3xx
4xx
5xx
Descrio
Requisio recebida e em fase de processamento.
Requisio recebida, entendida e processada com sucesso.
Redireciona o cliente para uma outra URL.
Requisio invlida.
Incapacidade do servidor em processar a requisio.
Tabela 3 Cdigos de resposta do protocolo HTTP 1.1.
2.5. Consideraes finais

Neste captulo foram abordados os conceitos bsicos da Web, um assunto importante para
este trabalho. Foi feito um breve histrico da criao da internet seguido pela explicao dos
modelos de referncia ISO/OSI, do protocolo TCP/IP e do funcionamento das camadas desse
protocolo. Tambm foi abordado o protocolo HTTP e as mensagens de requisies e respostas
possveis.
O conhecimento da estrutura pela qual uma requisio a um servidor web necessita
passar de vital importncia para que a modelagem e posteriormente a simulao sejam bem
fundamentadas e elaboradas. Um reforo positivo para tal estudo pode ser relacionado ao
crescimento de aplicaes que necessitam de QoS, que pode vir a no existir se houver atraso nas
requisies e nas entregas de dados.
No prximo captulo ser abordada a avaliao de desempenho e alguns mtodos de
simulao, dois assuntos que foram importantes para o desenvolvimento deste projeto.
16
CAPTULO
3. Anlise de Desempenho e
Simulao
Avaliar o desempenho de um sistema computacional essencial para obter concluses
sobre o desempenho e o comportamento em determinadas situaes. Em todo o ciclo de vida de
um sistema de computador, desde o projeto at sua atualizao, o estudo de avaliao permite
aos responsveis do projeto abstrair informaes importantes, tais como, o melhor sistema para
uma dada aplicao e a quantidade de recursos a ser utilizado. Apesar de sua importncia, muitas
vezes esta atividade desprezada com conseqncias drsticas para o sistema final. Essa falta de
interesse est relacionada, principalmente, a dois fatores: os responsveis no dominam o
emprego de ferramentas de anlise; ou a avaliao torna-se uma tarefa difcil, apesar do analista
possuir conhecimento sobre as ferramentas (SANTANA et al., 1994).
A avaliao de desempenho uma arte, pois algo que no pode ser feito
mecanicamente (JAIN, 1991). A avaliao de um sistema envolve conhecimento do sistema
modelado e uma seleo cuidadosa de metodologia, carga de trabalho e ferramentas. O problema
deve ser definido e convertido para uma forma em que as ferramentas e tcnicas existentes
possam ser usadas, considerando uma srie de requisies (entre elas o tempo disponvel). Cada
analista tem seu estilo: dado o mesmo problema, podem-se escolher mtricas e mtodos de
avaliao diferentes. E, com os mesmos dados obtidos, pode-se chegar a concluses diferentes, e
at opostas (JAIN, 1991). As principais tcnicas para avaliar desempenho so tcnicas de
aferio e modelagem. As tcnicas de aferio podem utilizar benchmarks, monitoramento ou
coleta de dados diretamente no sistema. J as tcnicas de modelagem podem usar Redes de Petri
(FRANCS, 2000), Redes de filas e Statecharts (HAREL, 1987). Os modelos podem ser
17
resolvidos por simulao ou analiticamente (FRANCS, 1998). Muitas vezes usada uma
combinao dessas tcnicas.
A seguir sero explicados alguns fundamentos utilizados na avaliao desempenho.
3.2. Carga de trabalho

A carga de trabalho de um sistema se refere s solicitaes feitas pelos usurios,
entidades que fazem pedidos de servios no sistema. Exemplos de carga so instrues enviadas
a uma CPU, consulta feita a uma base de dados ou transaes num sistema bancrio. Uma carga
real aquela observada em operaes normais, no pode ser repetida de modo controlado e, em
geral, no adequada para uso como teste. Assim, freqentemente desenvolvida uma carga
sinttica (cujas caractersticas devem ser similares quelas da carga real) que pode ser aplicada
repetidamente e de forma controlada para estudos. Essa carga sinttica chamada benchmark e
se constitui de programas ou partes de programas relativos s aplicaes mais utilizadas (SILVA,
2005).
3.3. Mtricas
Mtricas de desempenho so medidas ou critrios para avaliao de desempenho (JAIN,
1991).
Do ponto de vista de um usurio, a principal mtrica o tempo de resposta, que o
intervalo entre o fim de um pedido e o fim da resposta correspondente, sendo essa a definio
usual, embora se possa considerar tambm o incio da resposta.
Do ponto de vista do sistema, a principal mtrica o throughput6: o nmero mdio de
pedidos processados por unidade de tempo.
Para CPU7s, o desempenho medido em MIPS (Milhes de Instrues por Segundo) ou
MFLOPS (Milhes de Operaes de Ponto Flutuante por Segundo). importante ressaltar que
Velocidade com que um computador processa dados. uma combinao da velocidade de processamento interno,
velocidade dos perifricos (I/O) e eficincia do sistema operacional e outros Software do sistema, todos funcionando
juntos.
7
Unidade central de Processamento.
18
no faz sentido comparar MIPS em diferentes arquiteturas de CPU, por exemplo, RISC 8e CISC
9
devido diferena entre as instrues utilizadas.

Para redes, o throughput medido em pps (pacotes por segundo) ou bps (bits por
segundo). Observa-se que o tempo de resposta obtido com o throughput mximo pode ser alto
demais para ser aceitvel. O ponto timo de uma aplicao encontrado com o clculo
throughput versus tempo de resposta. o ponto alm do qual o tempo de resposta aumenta
rapidamente com a carga, mas o ganho em thoughput pequeno. O throughput mximo
alcanvel sob condies ideais de carga de trabalho chamado de capacidade nominal do
sistema; para redes, isso denominado bandwidth10. A razo da capacidade utilizvel
(throughput mximo alcanvel sem exceder um limite de tempo de resposta pr-especificado)
para a capacidade nominal chamada de eficincia.
A taxa de utilizao de um recurso determinada pela porcentagem de tempo que o
recurso est ocupado, para determinada carga (SANTANNA, 2004). O recurso do sistema que
primeiramente atingir 100% de utilizao, o que ficar saturado em primeiro lugar, chamado de
gargalo. A otimizao no desempenho desse recurso a que oferece o maior retorno em termo de
investimento. Por isso, achar a utilizao de recursos no sistema uma parte importante na
anlise global.
Outras medidas de desempenho que devem ser citadas so:
Confiabilidade: medida pela probabilidade de erros ou tempo mdio entre erros;
Disponibilidade: frao de tempo que o sistema est disponvel para utilizao;
3.4. Mtodos de Avaliao de Desempenho Tcnicas de Aferio

3.4.1 Benchmarks
Benchmarks so programas ou partes agrupadas de programas, de diferentes tipos. Esses
programas podem ser relativos tanto para aplicaes comerciais quanto para aplicaes
cientficas por exemplo, e que devem representar a carga real a ser submetida ao sistema; so
usados em testes para comparaes ou em estudos de projeto ou planejamento.
8
Conjunto Reduzido de Instrues de Computador.

Conjunto de Instrues Complexas de Computador.
10
Largura de banda.
9
19
Os benchmarks possuem baixo custo, porm apresentam limitaes como influncia do

compilador, da biblioteca em tempo de execuo e tamanho do cache. Alm disso, no
representam em geral sistemas interativos. Alguns benchmarks podem abordar basicamente a
CPU, a Unidade de Ponto Flutuante e um subsistema de memria; outros podem ser direcionados
para comparao de I/O e outros subsistemas.
3.4.2 Monitoramento
Um monitor uma ferramenta usada para observar as atividades em um sistema (JAIN,
1991). Em geral, os monitores observam o desempenho de sistemas, coletam estatsticas de
desempenho, avaliam os dados, e mostram resultados. Alguns tambm identificam reas de
problemas e sugerem solues. Alguns exemplos de utilizao de monitores so:
Um gerente de sistemas pode usar um monitor para medir as utilizaes de recursos e
achar o gargalo, ou tambm para ajustar os parmetros do sistema visando melhoria
no desempenho.
Um analista pode fazer um monitoramento para caracterizar a carga de trabalho,
sendo os resultados usados para planejamento de capacidade ou para criar cargas de
trabalho para testes.
Um programador pode usar o monitor para achar os segmentos do software
freqentemente usados e otimizar seu desempenho.
Os monitores so classificados com base em caractersticas como nvel de
implementao, mecanismo de disparo e capacidade de apresentar resultados. Considerando o
nvel de implementao podem-se ter monitores de hardware, software, ou hbridos.
Os monitores de software so usados para monitorar sistemas operacionais e softwares de
nvel mais alto como redes e bases de dados. Em cada ativao vrias instrues so executadas
e em geral provocam sobrecarga maior que os monitores de hardware.
Os monitores de hardware so dispositivos de hardware especficos para coletar e
avaliar dados do objeto em estudo. No devem ser intrusos em relao ao sistema. Os monitores
de hoje so inteligentes e programveis contendo seu prprio processador, memria e
dispositivos de I/O. Consistem de vrios elementos, como por exemplo: probes para observar
20
sinais em pontos desejados do hardware do sistema; contadores incrementados quando um

certo evento ocorre e temporizadores para marcar o tempo ou disparar uma operao de
montagem.
3.5. Mtodos de Avaliao de Desempenho Tcnicas de

Modelagem
3.5.1 Simulao
Uma simulao um programa que representa o comportamento de um sistema real. No
caso de sistemas computacionais, um hardware ou software pode ser simulado. Para se construir
um programa de simulao relativo a um sistema em estudo, devem-se inicialmente especificar
os componentes e sub-componentes: hardware, software, aplicativos e todos os mecanismos e
dispositivos de interesse no caso. Em seguida se constri um modelo da estrutura do sistema.
Aps, transforma-se o modelo num programa, representando-se a ocorrncia de eventos
consecutivos, tais como: atualizaes, transaes, consultas, interrupes, retardos e esperas.
Nele se colocam as caractersticas pertinentes: taxas, prioridades, comprimento de mensagens,
origens e destinos entre outras. A verificao a etapa em que se analisa se o programa
implementa (representa) corretamente o modelo. E na validao se analisa se as suposies feitas
no modelo correspondem realidade (SANTANNA, 2004).
As variveis que definem o estado do sistema so chamadas variveis de estado. Se uma
simulao para na metade, pode ser reiniciada mais tarde, se e somente se os valores de todas
variveis de estado forem conhecidas. Um modelo no qual o estado do sistema definido em
todos instantes chamado um modelo contnuo no tempo. Se o estado do sistema for definido
apenas em instantes particulares do tempo, o modelo chamado de discreto no tempo. Um
modelo chamado de contnuo ou discreto em relao a estado se as variveis de estado forem
contnuas ou discretas. Um modelo de estados discretos tambm chamado um modelo de
eventos discretos (idem para estado contnuo). Observe-se que a continuidade do tempo no
implica na continuidade de estados e vice-versa, existindo assim 4 combinaes distintas
possveis.
Uma simulao pode ser seqencial ou distribuda. Numa simulao seqencial, os
eventos no podem ser executados eficientemente em sistemas paralelos ou multiprocessadores,
21
porque existem duas estruturas globais que so compartilhadas por todos processos: o relgio da
simulao e a lista de eventos.
Quanto escolha da linguagem de simulao, pode ser usada uma linguagem de
propsito geral, uma extenso dessa linguagem de propsito geral adaptada para simulao, uma
linguagem especfica para simulao ou ainda um pacote de simulao. Outras consideraes
comumente feitas em simulaes so verificar se a simulao atingiu um estado permanente, o
tempo total da implementao da simulao, gerao de nmeros aleatrios e escolha de
sementes.
3.5.2 Soluo Analtica (Teoria de Filas)

Em sistemas computacionais muitas tarefas compartilham os recursos do sistema tais
como CPU, discos e outros dispositivos. Em geral, apenas uma tarefa pode usar o recurso em um
determinado instante, e as outras tm que esperar em fila pelo recurso. A teoria de filas auxilia
em determinar o tempo que as tarefas gastam em vrias filas no sistema. Esses tempos podem ser
combinados para se prever o tempo de resposta.
O uso de modelos matemticos baseados em teoria de filas pode-se tornar difcil em
sistemas complexos, mas apresenta vantagens como baixo custo e tempo para a avaliao.
Algumas caractersticas que devem ser especificadas para avaliao com teoria de filas so:
processo de chegada (muitas vezes se considera como um processo de Poisson, onde os
tempos entre chegadas tm distribuio exponencial).
Tempo de servio: muitas vezes considerado como tendo distribuio exponencial;
nmero de servidores;
capacidade do sistema: mximo nmero de clientes que podem permanecer dentro do
sistema; tamanho da populao (de clientes);
disciplina de servio, sendo alguns exemplos: FCFS (First Come, First Served); LCFS-PR
(First Come, First Served with Preempt and Resume); RR (Round-Robin).
22
3.6. Consideraes Finais

De nada adianta um sistema ser confivel, consistente, econmico, entre outras
caractersticas desejveis, se o desempenho (por exemplo, tempo de resposta) no for
satisfatrio. Os componentes de um sistema distribudo trabalham em separado e
concorrentemente. Todos os componentes de um sistema distribudo devem ter bom
desempenho, quando considerados em separado, mas isso no garante o bom desempenho do
conjunto, j que h outros fatores que influem no conjunto, como a distribuio dos servidores de
arquivos, configurao correta de protocolos e um escalonamento adequado de processos. O
desempenho no se traduz apenas em termos de tempo de resposta e throughput, estando
tambm associado tolerncia a falhas, confiabilidade e consistncia. Para melhorar o
desempenho de um sistema comumente se procura o recurso que corresponde ao gargalo para
otimizao ou upgrade.
A avaliao de desempenho algo complexo, devido ao ambiente heterogneo, grande
volume de dados que se pode extrair, necessidade de conhecimentos sobre sistemas
computacionais e anlise estatstica. Na avaliao devem-se considerar os objetivos almejados,
ferramentas, oramento e tempo disponvel; e ainda integrao com o gerenciamento do sistema.
Para se avaliar protocolos de comunicao comum fazer uso de simulaes, tambm utilizadas,
juntamente com modelagem analtica (matemtica), para se avaliar desempenho de servidores.
Combinaes de diversas tcnicas em avaliao de desempenho so normalmente
utilizados. Por exemplo, pode-se considerar um modelo analtico para determinar a faixa de
parmetros juntamente com um simulador para analisar o desempenho na faixa considerada ou
validao de tcnica analtica com uso de simulao ou medies reais (monitoramento).
Com esse captulo foram introduzidos conceitos bsicos envolvidos na anlise de
desempenho e na simulao.
No prximo captulo sero apresentados os conceitos relativos aos servidores web como
caractersticas de funcionamento, arquitetura dos servidores e tipos de requisies atendidas.
23
24
CAPTULO
4. Servidores Web
Com o passar do tempo a World Wide Web tem sofrido um grande crescimento. No so
apenas milhes de novos navegando na Web a cada dia, tambm h centenas de novos web sites
que so adicionados diariamente (WELLS, 2001). Logo, h o crescimento no nmero de
servidores (i.e., HTTP) Web. Com isso, os vendedores de servidores web tem orgulho em
enaltecer os atributos de seus produtos, e caractersticas de fabricao baseadas em teorias em
como tornar o servidor web rpido. Entretanto, essas virtudes e teorias so geralmente baseadas
em evidncias erradas, instinto, ou limitadas evidncias empricas que so pouco teis
(SLOTHOUBER, 1995).
Por esse fato que necessrio conhecer todos os tipos de aplicaes possveis que um
servidor web pode receber e caractersticas importantes. A partir da ser possvel anteceder as
possveis requisies e obter o melhor rendimento possvel do hardware.
Ao longo deste captulo sero mostrados: as caractersticas tcnicas do hardware, em
especfico para suprir necessidades de requisies HTTP, tipos de arquiteturas de servidores
web; e caractersticas de aplicaes prprias para os servidores web.
4.2. Funes do Servidor Web

Com a Web se tornando a interface padro para acessar servios remotos de sistemas de
informaes, centro de hospedagem de dados e provedor de servios de aplicao h uma
crescente demanda no lado dos servidores web que esto sofrendo cada vez mais com este
aumento de requisies (CARDELLINI, 2002).
Graas complexidade da infra-estrutura da Web, problemas com a performance podem
surgir em diversos pontos durante a interao com os servidores web. Por exemplo, eles podem
25
ocorrer na rede devido ao congestionamento dos roteadores da Internet, tanto como na Web e nos
servidores de banco de dados, ou pior ainda, por causa da capacidade limitada de atendimento ou
surgimento de uma requisio inesperada. A soluo do problema das redes tem sido mais
facilmente resolvido, tendo em vista a velocidade com que as capacidades de banda crescem, j
os problemas relacionados aos servidores web tornam-se mais difceis pela menor velocidade de
desenvolvimento de seus componentes (COFFMAN, 2001). O aumento da capacidade das redes
por si s no resolve o problema de QoS,mas comumente transfere o problema para dentro dos
servidores web, uma vez que eles se tornam o gargalo.
A seguir sero apresentados alguns tipos de documentos suportados pelos servidores web
e sua particularidades.
4.3. Arquitetura dos servidores web

A WWW pode ser considerada, em uma viso de alto nvel, sendo composta por trs
elementos principais: os browsers, a rede e os servidores (TEIXEIRA, 2004). Tais elementos se
relacionam atravs do modelo cliente-servidor (TANENBAUM, 2003). Sendo que, esse modelo
pode ser ordenado em diferentes arquiteturas. Na figura 4.1 so mostradas as ramificaes
possveis que um sistema distribudo pode utilizar.
Figura 4.1 - Tipos de arquitetura de servidores web
26
As diferentes arquiteturas dos servidores web so motivadas especialmente pelo upgrade

necessrio pelos servidores web devido o aumento de demanda. No incio, os servidores web
eram constitudos de apenas uma mquina que, ao no suportar a demanda era substituda por
outra mquina mais veloz e com maior armazenamento, tcnica conhecida como hardware
scale-up (DEVLIN, 1999). Outra opo utilizada era melhorar o software, tcnica conhecida
como software scale-up (BANGA et al., 1998). Essas tcnicas, apesar de melhorar o
desempenho por um certo tempo, tornaram-se impraticveis com o aumento sofrido pela
Internet. A sada encontrada foi a utilizao de mais de um n em cada servidor web, ou
servidores web distribudos para fazer o compartilhamento da carga recebida. Os sistemas web
distribudos, como pode ser visto na figura 4.1, podem tanto ser subdivididos em global scale-out
e local scale-out. Em global scale-out os ns so separados em distintas localidades geogrficas,
j em local scale-out esses ns servidores esto residentes em uma nica rede.
Apesar das diferenas estruturais, os componentes internos e o funcionamento dos
servidores web no diferem, ou seja, as requisies so atendidas da mesma maneira em todas as
arquiteturas. A diferena observada na variao da capacidade total entre diferentes
arquiteturas e servidores web.
Apesar das requisies no serem tratadas de maneira diferente por diferentes
arquiteturas, h diferenas entre requisies como as requisies dinmicas e estticas.
4.3.1 Requisies Estticas

As pginas estticas tm a caracterstica de apresentar textos planos e acompanhados de
imagens e no mximo algum recurso multimdia como vdeos e udios. Essas pginas so
desenvolvidas atravs da linguagem HTML (HyperText Markup Language). O maior recurso de
tais pginas fica por conta dos links para outras pginas Web.
At meados da dcada de 90, a Web era constituda apenas por documentos hipertexto
interligados. Devido baixa atualizao no contedo dos documentos, as pginas estticas eram
uma boa soluo (SILVA, 2005).
27
Figura 4.2 - Esquema cliente-servidor nas requisies estticas
As requisies estticas seguem o esquema mostrado na figura 4.2, 1) cliente faz

requisio de um documento utilizando um browser; 2) a requisio enviada atravs do
middleware (Internet); 3) o local onde o documento se encontra (servidor web) responde a
requisio enviando o documento. Para o envio da requisio utilizado o protocolo URL.
Atravs de um browser o cliente requisita um documento. O browser, por sua vez, produz uma
requisio HTTP ao servidor, que analisa o pedido e se possvel envia as informaes no padro
HTML ao browser cliente, que apresenta as informaes ao usurio.
Nesse tipo de requisio a interao fica por conta do pedido e do prprio documento
retornado. Apesar da baixa interatividade, esse tipo de documento ainda muito popular
(SILVA, 2005).
4.3.2 Requisies Dinmicas

A caracterstica das pginas dinmicas que elas so geradas em tempo de
processamento da requisio. Essas pginas possuem efeitos especiais como: controle de
formulrios e janelas entre outros recursos. Entretanto, para a gerao de tais pginas
necessrio utilizar outras linguagens de programao, alm do HTML.
Pginas dinmicas podem ser obtidas atravs de aplicativos rodando no cliente ou no
servidor. Algumas tecnologias utilizadas no lado cliente so: Java, ActiveX e Dynamic HTML,
esses recursos so executados diretamente pelo navegador. Nessa abordagem, h a vantagem de
reduzir o tempo de resposta e evitar o uso excessivo de recursos de rede (MENASC;
28
ALMEIDA, 2003). Outra abordagem possvel gerar as pginas dinmicas diretamente no

servidor, que pode ocasionar um consumo do recurso do processador do servidor web, gerando
uma sobrecarga no mesmo caso as aplicaes forem muito complexas. ASP (Active Server
Pages), PHP (Hypertext Preprocessor) e JSP (Java Server Pages) so alguns exemplos de
tecnologias de criao de pginas dinmicas no servidor.
As requisies dinmicas ocorridas nos servidores seguem o esquema mostrado na figura
4.3. A seqncia : 1) o cliente faz uma requisio de um documento atravs de uma requisio
HTTP; 2) a requisio enviada atravs da Internet at o servidor web, 3) o servidor web verifica
que se trata de uma requisio dinmica e a envia para ser processada; 4) a requisio
processada por um sistema de processamento de transao e faz o caminho de volta at o cliente.
No passo 4 possvel haver a integrao com um sistema de gerncia de banco de dados.
O protocolo HTTP e a linguagem HTML fornecem recursos dinmicos como o protocolo
CGI (Commom Gateway Interface) que permite a execuo de programas e marcadores para
definio de formulrios (SANTANNA, 2004). Dessa forma, os servidores so configurados
para reconhecer nomes de arquivos como chamadas para aplicativos que devero ser executados.
Toda a comunicao continuar sendo realizada em formato HTML, garantindo nenhum vnculo
a plataforma. O que o CGI faz transferir o pedido de execuo de uma aplicao para o
programa apropriado, agindo como um tradutor entre o cdigo HTML e os requisitos de
aplicaes.
O CGI nasceu em 1995 oferecendo uma interao maior sobre o modelo cliente-servidor
utilizando 3 nveis (ou camadas), esses permitem ao servidor web rotear o contedo de
formulrios HTML para aplicaes de servidores back-end.
29
Figura 4.3 Esquema cliente-servidor das requisies dinmicas
A partir do CGI foi possvel ampliar as aplicaes na Internet, realizando atualizaes,

inseres e delees em bases de dados, o que tornou o comrcio eletrnico possvel. Pelo fato
do protocolo CGI no manter informaes de um formulrio para o seguinte (stateless) foram
criados os cookies, pequenas pores de informaes que ficam nos clientes. Essas informaes
ficam a cargo da aceitao do cliente mediante o browser.
4.4. Sesses HTTP

Com o incentivo dado pelas requisies dinmicas e segurana no atendimento das
aplicaes, houve o crescimento da utilizao da Internet como meio de compra e venda de
produtos. Os clientes que fazem compras na Internet so atrados pela velocidade e conforto em
realizar compras sem sair de casa fatos que contribuem com o crescimento do nmero de
usurios que fazem uso desse recurso. Entretanto, o aumento de demanda nos servidores web
causados pelo comrcio eletrnico pode ser extremo e comprometer a qualidade dos servios
(garantia de atendimento) disponveis no servidor web (WEI et al, 2003).
Tipicamente, um acesso ao servidor web ocorre na forma de uma sesso, sendo essa,
constituda 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 prover informaes necessrias, uma para estabelecer um acordo de
pagamento e finalmente uma ltima requisio para receber uma confirmao (MOURO,
2005). Para garantir o atendimento de todas as requisies pertencentes a uma transao
30
comercial necessria uma qualidade de servio em nvel de aplicao. Ou seja, uma transao
de sucesso aquela que atende toda a seqncia de requisies.
4.5. Estrutura interna dos servidores web

Alm da importncia do meio de comunicao da requisio (Internet), como j foi dito
anteriormente, os componentes internos de um servidor web so diretos responsveis pelo
desempenho final do servidor web.
A seguir sero explicados o funcionamento e a importncia de alguns componentes que
sero simulados neste projeto.
4.5.1 Tratamento de Requisies TCP

Aps ser estabelecida a conexo TCP entre cliente e servidor, as requisies HTTP so
redirecionadas pelo daemon 11TCP para uma fila onde essas requisies ficam aguardando serem
atendidas.
4.5.2 Pool de Threads HTTP

Os servidores web primitivos utilizavam cpias de um novo processo para atender cada
uma das requisies HTTP (figura 4.5). Entretanto, a sobrecarga gerada tornou-se um problema.
Como soluo, foi criado um conjunto de processos que eram previamente gerados, um desses
processos era o processo mestre que gerenciava os pedidos e os demais processos.
11
Programa em execuo num computador servidor e est sempre pronto para receber solicitaes de outros
programas, executar determinada ao e retornar a resposta adequada.
31
Figura 4.4 - Um servidor HTTP de um processo por conexo com um processo mestre.
Figura 4.5 - Um servidor de um nico processo com mltiplas threads.
Como tempo, foi utilizado apenas um processo por servidor web, mas esse processo era
composto por mltiplas threads, como pode ser visto na figura 4.5 (TANENBAUM, 1995).
Nessa abordagem, como visto, as threads ao estarem prontas utilizam o mtodo accept para
tratar uma requisio que fica em uma fila de espera de requisies TCP. Essa abordagem a
mais usada atualmente.
4.5.3 Envio de Arquivos Requisitados

Aps a requisio ser interpretada por uma thread, o arquivo procurado tanto no
sistema de arquivos quanto em memria. Caso encontrado esse documento armazenado em um
32
buffer de rede, se disponvel, para ser enviado ao cliente. importante dizer que se o arquivo for
maior que o buffer a ser utilizado, deve ser fracionado com o tamanho do buffer o nmero de
vezes necessrias e todas as partes devem ser enviadas pelo mesmo buffer, dessa forma alocando
um buffer at o trmino do envio.
nessa fase que as requisies dinmicas so redirecionadas ao script engine para
execuo dos scripts. Os scripts engines so servidos por threads e tem o desempenho atrelado
implementao do servidor web e do sistema operacional.
Aps o processamento no script engine, as requisies sofrem o mesmo procedimento de
carregamento de buffers que as requisies estticas.
4.5.4 Descarga de Buffers de Sada

Aps estar com os dados de sada nos buffers necessrio fazer o esvaziamento dos
mesmos. Esse esvaziamento feito atravs de um controlador de I/O que envia o contedo dos
buffers pela conexo TCP aberta como cliente. Para esvaziar os buffers o controlador de I/O
pode utilizar, por exemplo, a poltica de round-robin.
A unidade de transmisso em redes baseadas no TCP/IP o MSS (Maximal Segment
Size), ou seja, o tamanho mximo de dados que o TCP consegue enviar para o cliente em um
segmento. Em outras palavras, o contedo do buffer particionado em pores de tamanho MSS
e so enviados seguindo o mecanismo de janelas (SANTANNA, 2004).

Neste captulo foram mostradas as interaes e um pouco do funcionamento de
elementos internos de um servidor web, alm de mostrar as estruturas externas que os servidores
web podem assumir.
Tambm foram mostrados alguns modelos de servidores web encontrados na literatura,
sendo que alguns desses modelos, que tentam mapear e modelar os passos que as requisies
sofrem at retornar aos clientes serviro de base para esse projeto.
No prximo captulo ser apresentado o projeto a ser desenvolvido, o plano de trabalho e
o cronograma a ser seguido.
33
34
CAPTULO
5. Modelo de Servidor Web com

Quatro Mdulos de Atendimento de
Requisies (SWMAR)
Neste captulo sero apresentados trabalhos relacionados a modelagem de servidores
web, e fundamentos utilizados para a construo do SWMAR. Tambm sero apresentados: a
biblioteca utilizada para controlar as redes de fila (SimPack) e o gerador de logs (W4Gen)
utilizado como carga inicial para o modelo desenvolvido. Caractersticas de implementao do
SWMAR tambm so apresentadas. Esse captulo est organizado da seguinte maneira, na seo
5.2 so apresentados os trabalhos relacionados a analise e modelagem de servidores web. A
gerao de logs (W4Gen) e a biblioteca de manipulao de redes de fila (SimPack) so
apresentadas nas sees 5.3 e 5.4, nessa ordem. E na seo 5.5 so apresentadas caractersticas e
particularidades de implementao do SWMAR, modelo e simulao de um servidor web
desenvolvido nesta dissertao de mestrado.
5.2. Trabalhos Relacionados

Apesar da grande necessidade de se avaliar os servidores web, visando oferecer aos
usurios um melhor servio ou qualidade de servio (QoS), poucos trabalhos so encontrados na
literatura descrevendo modelagens de servidores web. Dentre esses trabalhos poucos apresentam
abstraes de componentes internas, muitos so baseados em benchmarks de servidores web e/ou
analise dos gargalos e nem todos utilizam cargas sintticas para carga inicial, utilizam
distribuies estatsticas para esse papel. A seguir so apresentados alguns destes trabalhos
separados em dois grupos: os que modelam servidores web e os que analisam o desempenho de
um servidor web.
35
5.2.1 Modelos de Servidores Web

Existem diversos modelos de servidores web na literatura (ABDELZAHER; LU, 2000),
(ALMEIDA, 2000), (ROBERTSOON, 2003), (WELLS, 2001), (GANDHI, 2002), (REESER,
2000) e (DILLEY, 2000). Entretanto, nem todos possuem caractersticas de modelar todas as
etapas e estruturas de um servidor web, ou seja, que modele desde uma requisio HTTP,
passando por todo o processo de anlise e tratamento dessa requisio at o envio da resposta ao
cliente. O mais comum tratar os servidores web como caixas-pretas, utilizando uma viso em
alto nvel e tirando o peso que o servidor web possui no desempenho total da Internet.
As modelagens de servidores web sempre focam na anlise do potencial de uma ou mais
mquinas, considerando a mudana de configuraes tanto em hardware quanto software. Mas, a
forma como os modelos so desenhados que mostra o quanto esses modelos so aplicveis no
ambiente real.
Geralmente esses modelos so testados com o auxlio de uma carga que pode vir tanto de
logs gerados em servidores reais quanto atravs de programas de benchmark como: WebStone,
SPECWeb, S-clients. Esses programas de benchmark geram o que conhecido como carga
sinttica.
Os vrios trabalhos citados anteriormente esto mais relacionados anlise comparativa
de vrios servidores web ou at mesmo aos resultados de alteraes em caractersticas de
hardware e/ou software de um servidor existente. Essas abordagens, apesar de importantes para
o conhecimento aprofundado das caractersticas dos servidores web, no so de grande utilidade
ao se simular um ambiente do qual os servidores web fazem parte. Para essa finalidade, existem
alguns modelos que se aproximam em maior ou menor grau de um servidor web real.
Em (DILLEY et al., 2000) apresentado um modelo em alto nvel de um servidor HTTP.
Esse modelo recebe vrias requisies de browser clientes. Essas requisies eram atendidas
pelo daemon HTTP (httpd) e so despachadas a um processo do pool de server, o nmero de
processos no pool pode variar para anlise dos resultados. Esse modelo tambm prev a
requisio de pginas dinmicas. Nesse processo, criado um processo filho que executar o
script CGI e retorna a informao requerida ao server pool. No final da requisio tanto de
pginas dinmicas quanto estticas so retornadas ao cliente.
36
As deficincias analisadas nesse trabalho so: a falta de detalhes ao modelar o mdulo

httpd (considerar os componentes internos) e a maneira como foi tratado o meio de comunicao
(no foram considerados eventuais problemas com a rede).
Em van der MEI et al, (2001) e tambm em SANTANNA et al, (2004), devido o
trabalho ser baseado no trabalho de van der MEI et al, (2001), h a preocupao em modelar
algumas abstraes de componentes internas e o meio de comunicao. Em van der MEI, foi
feita a diviso dos processos que ocorrem dentro dos servidores web em trs fases:
Estabelecimentos de conexo TCP so modeladas desde a requisio entre cliente e
servidor at o envio da requisio HTTP.
Processamentos do HTTP nessa fase so modeladas da aceitao das requisies at
o carregamento dos buffers de sada.
Processamento de I/O a modelagem aqui relacionada ao esvaziamento dos buffers
e a entrega do resultado requerido ao cliente.
Apesar de todo o cuidado tomado para que o modelo se parea com um servidor real, o
protocolo utilizado foi o HTTP 1.0 e no h tratamento de requisies dinmicas.
SANTANNA (2004) baseou-se no trabalho de van der MEI (2001), mantendo a mesma
estrutura das fases anteriormente mostradas, fazendo a atualizao do protocolo HTTP para a
verso 1.1 e inserindo o tratamento de requisies dinmicas atravs de um script engine.
5.2.2 Anlise de Servidores Web

Em (Hu et al., 1999) estudado o comportamento o servidor APACHE executando sobre
o sistema operacional AIX da IBM. Nesse estudo feita a identificao dos gargalos e so
fornecidas informaes detalhadas a respeito dos eventos ocorrendo no ncleo do sistema
operacional. As cargas sintticas so geradas pelas ferramentas SPECWeb e Webstone. O
trabalho fornece dados sobre as porcentagens de tempo gastas executando em nvel de usurio,
em chamadas de sistema no ncleo e em manipulao de interrupes. Com relao aos
gargalos, a concluso no trabalho que para sistemas com memria principal (RAM) de pequeno
tamanho, o desempenho limitado pela largura de banda do disco. Para sistemas com memria
principal de tamanho razoavelmente grande, os gargalos so os softwares que processam os
37
protocolos TCP/IP e o manipulador de interrupes da rede. O comportamento semelhante para

os sistemas uniprocessador e SMP (Symetric Multiprocessor). Aps identificar gargalos, so
propostas e implementadas diversas tcnicas, com as quais se consegue um aumento de cerca de
60% no desempenho do servidor, conforme relatado.
(Hu et al. 1997a e b) estudam diversos servidores web: APACHE, Roxen, Jigsaw,
Netscape Enterprise, PHTTPD e Zeus, executando sobre redes ATM de alta velocidade em
plataforma UNIX. O autor estuda o desempenho relativo entre esses servidores e identifica
tambm os gargalos em questo. A concluso no trabalho que, quando as sobrecargas relativas
rede e I/O de disco so diminudas para fatores constantes desprezveis (por exemplo, atravs
de caches de memria), os principais fatores determinantes no desempenho so as estratgias de
concorrncia e de despacho de eventos usadas no servidor web; alm disso, verifica-se que
nenhuma dessas estratgias funciona de modo timo para todas condies locais e tipos de
trfego. So descritas otimizaes para desenvolver os servidores web que devem ser
adaptativos, escolhendo diferentes mecanismos para manipular requisies de arquivos grandes e
pequenos distintamente. As caractersticas consideradas so portabilidade e flexibilidade. O
servidor proposto pode se autoconfigurar em tempo de execuo ou instalao para usar a
estratgia de concorrncia mais eficiente, para uma dada plataforma de sistema operacional;
pode ser tambm configurado para dar suporte a mltiplos protocolos de transporte.
(ALMEIDA et al. 2000) descrevem a concepo e implementao de uma ferramenta
para gerar uma carga sinttica. A carga de trabalho utiliza uma distribuio de tamanho de
arquivos de cauda pesada para representar a caracterstica da carga de um servidor web, que deve
ser capaz de manipular concorrentemente algumas requisies para grandes arquivos (por
exemplo, udio e vdeo) e um grande nmero de requisies para documentos pequenos
contendo texto ou imagens. Nesse estudo verificado que em um servidor web saturado por
requisies, 90% do tempo para manipular essas requisies HTTP gasto no kernel. Manter as
conexes abertas, conforme requerido pelo protocolo TCP, provoca um aumento de fator dois no
tempo decorrido para atender uma requisio HTTP. Os resultados do estudo mostram o
importante papel da implementao do sistema operacional e do protocolo de rede para
determinao do desempenho.
(WALLACE & JR. 1997) apresentam um estudo que mostra algumas formas simples
para instrumentar um servidor web, usando recursos e/ou mecanismos existentes, j
implementados em sistemas de gerncia da rede ou no sistema operacional, para obter
38
estatsticas. Esses dados coletados e analisados, so usados em alguns modelos simples e

genricos de dimensionamento para componentes do servidor web, descritos pelos autores. Os
modelos so genricos de dimensionamento para componentes do servidor web descritos pelos
autores. Os modelos so centrados em quatro gargalos comumente considerados: rede,
memria, disco e CPU. Segundo os autores, o throughput de rede pode ser descartado j que isso
no , em geral, uma preocupao do servidor web em si, pois a largura de banda de rede pode
ser aumentada, configurando o servidor web com mais ,ou mais rpidas, placas de rede.
5.3. W4Gen
O W4Gen resultado do estudo de (SILVA, 2006) do comportamento de vrios logs de
servidores web. No trabalho foram utilizados logs disponibilizados na internet e logs que j
foram objeto de estudo como: Cdmil (2005), Tum (2005), Copi (2005), Stanford (2005), Veenet
(2005) e Connectmed (2005). Alm desses, foram utilizados os logs do CISC (Centro de
Informtica de So Carlos) e Prefeitura de Londrina e do Br10, estes foram obtidos atravs de
intermediaes com pessoas responsveis pela administrao de servidores web da instituio e
da empresa.
Esses logs foram classificados em trs categorias: acadmico, notcia/informativo e
tradicional. Um site acadmico possui registros de usurios, servios de biblioteca por meio de
gerao de pginas dinmicas, reas estatsticas com informaes da instituio, alm das
pginas pessoais de professores e alunos. Os sites do tipo notcia/informativo incluem
informaes periodicamente atualizadas, como temperatura do dia, dados financeiros, notcias da
regio ou do mundo, uma rea restrita aos usurios cadastrados, propagandas por meio de
banners, download de arquivos, entre outras. J um site tradicional possui poucas atualizaes e
utiliza muitos recursos estticos. Essa ltima categoria inclui pginas pessoais e de empresas de
pequeno porte cujo objetivo simplesmente apresentar o seu perfil e os produtos aos clientes.
Atravs dos logs foi possvel fazer analises do intervalo de chegada dos diferentes tipos
de requisies12 e foram selecionadas distribuies que mais se aproximassem do intervalo de
chegada para esses tipos de requisies. Essas distribuies so: Weibull, Gamma e Lognormal.
12
Arquivos que foram requisitados: html, imagem, arquivos dinmicos, textos, documentos, scripts, udio, binrio e
vdeo.
39
Como resultado desse estudo o W4Gen capaz de gerar logs baseados nos trs tipos
definidos com intervalos de chegadas e nos tipos de requisies e tamanho dos arquivos
requeridos baseados nos logs estudados. A seguir so apresentadas as possveis configuraes
para a gerao da carga de trabalho da sees 5.3.1 at 5.3.5.
5.3.1 Cdigo de Resposta

O W4Gen possui uma interface grfica que permite ao usurio configurar o cdigo de
resposta (cdigo de status) retornado pelos servidores web. H trs tcnicas diferentes para gerar
o cdigo de resposta. So elas:
Usar somente requisio do tipo 20013. Ativando a caixa de checagem, o W4Gen no
utiliza nenhuma distribuio ou qualquer informao para gerar os cdigos de respostas. Ele,
simplesmente, acrescentar o cdigo 200 a todas as requisies (Figura 5.1).
Figura 5.1 Gerao de requisies com cdigo 200 W4Gen.
Outra forma de gerar cdigo de resposta segundo uma distribuio. No caso do

primeiro item no estar selecionado, o W4Gen permite ao usurio gerar os cdigos de resposta
segundo a distribuio geomtrica. Neste caso, preciso definir o valor do parmetro que
configura a funo de distribuio. A barra de exibida na figura 5.2 permite essa modificao.
13
Requisies com sucesso.
40
Figura 5.2 - Gerao de cdigo de status baseado em distribuio W4Gen.
Como resultado da gerao de cdigo de resposta por distribuio so gerados quatro

tipos diferentes de cdigos: 2xx, 3xx, 4xx e 5xx, que so distribudos no arquivo de log gerado
pelo W4Gen.
5.3.2 Classe de Objeto

H a opo de customizar os objetos de acordo com as necessidades de cada usurio. No
W4Gen so disponibilizadas duas tcnicas para gerar os tipos de objetos. So elas:
Segundo Distribuio de Probabilidade

Ao usar a distribuio de probabilidade, o W4Gen permite gerar as classes de objetos
segundo a distribuio geomtrica. Para isso, preciso definir o valor do parmetro que
configura a funo de distribuio. A barra de rolagem que aparece na figura 5.3 permite
modificar esse parmetro.
Figura 5.3 Gerao de classes objetos segundo distribuio geomtrica.
41
Segundo Valores de Porcentagem

Outra forma de gerar os objetos segundo valores de porcentagem. O W4Gen permite
gerar as classes de objetos segundo os valores de porcentagem. Para isso, o usurio deve
configurar a porcentagem de cada um dos nove tipos diferentes de objeto: Imagem, HTML,
Dinmico, Texto, Documento, Script Cliente/Animao, udio, Binrio/Compactado e Vdeo.
Esses valores so modificados atravs da barra de rolagem, como mostra a figura 5.4. A
seqncia de requisies segue o comportamento de uma funo de nmeros aleatrios.
Figura 5.4 Gerao de classes de objetos segundo valores de interface.
5.3.3 Intervalo de Chegada

O usurio pode ainda escolher os intervalos de chegada. Esta funcionalidade atingida
atravs de funes de distribuies para cada tipo de objeto. Com isso o usurio pode escolher as
caractersticas que mais se adaptam as suas necessidades. Alm disso possvel fazer uma
sobrecarga no servidor web, que aumenta o nmero de requisies por tempo.
possvel escolher doze diferentes distribuies para a gerao das classes do objetos.
Conforme ilustrado na figura 5.5.
42
Figura 5.5 Intervalo de chegada das classes.
5.3.4 Tamanho de Objeto

O tamanho do objeto (figura 5.6) segue o mesmo princpio do intervalo de chegada, onde
o usurio utiliza distribuies para gerar o tamanho dos arquivos. Alm de escolher as funes
preciso definir os valores de seus parmetros. A mudana desses valores pode distorcer a
realidade da Web e reproduzir um comportamento diferente, gerando concluses falsas na
anlise, j que a carga de trabalho influencia diretamente no desempenho global do sistema
(MENASC; ALMEIDA, 2003).
Figura 5.6 Tamanho de objeto das classes.
5.3.5 Arquivo Resultante

Com todas as opes de configurao apresentadas possvel gerar a carga sinttica de
duas maneiras diferentes (figura 5.7). Por intervalo de tempo em minutos ou por nmero de
requisies da carga.
43
Figura 5.7 Gerao de carga de trabalho.
A figura 5.8 mostra um exemplo de um arquivo reproduzido pelo W4Gen. O arquivo

contm quatro campos: timestamp da requisio, contendo o instante que a requisio chegou ao
servidor web; tipo de objeto que foi requisitado; cdigo de status retornado pelo servidor web e o
tamanho do objeto requerido. Na figura 5.8, todas as requisies chegaram no mesmo instante,
ou seja, no tempo zero. Observa-se tambm a presena de diversos tipos de objetos, tais como,
imagem (image), texto (text), entre outros e dois grupos de cdigo de resposta, a 2xx
(Successful) e a 3xx (redirecionamento). Tambm se podem observar os tamanhos dos arquivos
das requisies que em alguns casos zero, o que significa que os arquivos so menores que
1KB.
Figura 5.8 Exemplo de carga sinttica gerada pelo W4Gen.
44
5.4. Simpack
SimPack originalmente uma coleo de ferramentas C++ (rotinas e programas) para
simulao de computadores. O propsito do SimPack prover a pessoas com uma idia inicial
simular um sistema. O propsito principal que atravs de uma viso ou uma idia se consiga
gerar um programa de simulao. SimPack foi utilizado em diversos estudos e trabalhos como:
BARBATO et al. (2005) e TEIXEIRA et al. (2004).
SimPack um conjunto de ferramentas que suportam eventos discretos de simulao.
SimPack era originalmente escrito na linguagem C, e atualmente existe a verso na linguagem,
Java. Atualmente a verso C foi depreciada e s ha atualizaes na verso Java. SimPack
disponibilizada via a licena Gnu Public License (GPL).
A biblioteca oferece 3 conjuntos de mtodos:
Escalonamento de eventos: Ncleo do SimPack lidam com a lista de eventos
futuros
o Sim.init inicia uma simulao discreta;
o Sim.schedule escalona um evento para ocorrer no futuro;
o Sim.next_event requisita o prximo evento da lista de eventos futuros;
o Sim.next_event_dup requisita todos os prximos eventos, com o mesmo
tempo, da lista de eventos futuros;
o Sim.cancel_event remove o primeiro evento com um item especificado
pelo evento da lista de eventos futuros;
o Sim.cancel_token remove o primeiro evento com um item especificado
pelo identificador token;
Alocao de recursos mtodos que tratam com as filas e os servidores que a
atendem
o Sim.create_facility cria uma fila e os servidores que a atendem
o Sim.request requisita um servio a uma fila;
o Sim.preempt causa preempo em uma fila;
o Sim.release libera a fila para um evento que est no topo da fila;
45
Estado da simulao e rastreio retorna os dados relacionados a lista de eventos

futuros, s filas
o Sim.state retorna os dados da simulao a qualquer ponto da simulao;
Geradores aleatrio de nmeros gera nmeros aleatrios em diferentes funes
de densidade
o Sim.random gera distribuio aleatrio;
o Sim.uniform gera distribuio uniforme;
o Sim.normal gera distribuio de normal;
o Sim.expntl gera distribuio exponencial;
o Sim.erlang gera distribuio erlang;
Algumas peculiaridades da biblioteca so: o tipo de estrutura das requisies que pode
ser LINKED ou HEAP (diferena relacionada a estrutura de dados utilizada pela biblioteca) e
tipo de simulao sncrona (SYNC) e assncrona (ASYNC). A simulao sncrona feita
utilizando os tempos de simulao atravs do relgio fsico do computador, ou seja, o relgio do
computador dispara o atendimento das requisies. J o modo assncrono as requisies so
atendidas o tempo atual sempre 0 (zero) e os demais tempos so calculados pelo decremento
baseado no antigo tempo atual, ou seja, se a fila de requisies so 10, 20, 20 e 32 o SimPackj
atualiza os tempos para 0, 10, 10 e 22.
O SimPack apresenta algumas limitaes, dentre elas cabe ressaltar que. Alguns valores
so fixos no arquivo Const.java. Por exemplo, o nmero de eventos suportados pela biblioteca
fixado em 100 eventos. Esse valor pode ser alterado para mais eventos mas, o novo valor
escolhido pode ser limitado por: (1) pela quantidade de memria disponvel na mquina onde a
simulao executada e (2) limitaes da maquina virtual Java (JVM) que interpreta a
simulao.
5.5. Modelo de Servidor Web com Quatro Mdulos de Atendimento

de Requisies (SWMAR)
Esta seo apresenta um modelo para servidor web baseado em redes de filas,
representado uma abstrao dos componentes internos de um servidor web dividida em quatro
46
mdulos diferentes, cada mdulo responsvel por uma etapa do atendimento da requisio.
Neste modelo so levados em considerao: impactos de diferentes caractersticas de carga
inicial (gerada pelo W4Gen) e configurao de hardware e software do servidor. O modelo
baseia-se principalmente no trabalho de van der MEI et al., (2001). Para auxlio na simulao foi
utilizado do SimPack para manipular as filas e as requisies. Como parmetros do SimPack
foram utilizados como estrutura de dados LINKED e tipo de simulao ASYNC, assncrona.
No SWMAR so analisadas requisies dinmicas e estticas. O fluxos de transaes no
servidor web so descritos por um modelo de filas de sries, que consiste de quatro sub-modelos
que sero aqui denominados mdulos de 1 a 4. A forma como esses mdulos se integram
apresentada na figura 5.9.
A seguir os mdulos so apresentados individualmente de maneira detalhada.
Figura 5.9 Fluxograma do SWMAR.
47
5.5.1 Mdulo 1: Atendimento de Requisies HTTP

Este mdulo responsvel pela manipulao da requisio HTTP. Aps o
estabelecimento de conexo o pedido de transao est apto a ser filtrado e interpretado pelo
subsistema HTTP, que consiste de uma fila de escuta HTTP servida por um ou mais daemons
HTTP. O fluxo normal de atendimento por esse mdulo descrito na figura 5.10.
Cada daemon HTTP possui um pool de threads que responsvel pelo atendimento das
requisies. Se uma das threads do pool de threads HTTP est disponvel ento a thread busca o
arquivo requisitado e encaminha o pedido para o mdulo seguinte, mdulo 2.
Figura 5.10 Esquema de atendimento no mdulo 1.
Nesse mdulo h apenas uma maneira de haver recusa de requisio, atravs do

preenchimento total da fila de escuta HTTP. No caso de que todas as threads do pool de threads
estejam sendo utilizadas a requisio fica esperando na fila at que se desocupe um das threads.
Como valor padro para o tamanho dessa fila utilizado o valor padro do APACHE de no
mximo 511 requisies na fila e de 5 a 10 threads no pool de threads.
5.5.2 Mdulo 2: Transferncia de Arquivos Memria Principal

Nesse mdulo feita a transferncia do arquivo requisitado para a memria atravs do
DMA. Ao utilizar o DMA o gerenciamento da transferncia fica a cargo da controladora da
placa-me e dessa forma no utilizado o processador. Sendo assim, para calcular o tempo
utilizado para executar a tarefa de transferncia so utilizados o tamanho do arquivo requisitado
e a velocidade do disco. utilizada a velocidade do disco por se tratar do recurso computacional
mais lento nessa operao e, portanto, ser o fator que limita a velocidade da transferncia.
48
Nesse mdulo podem ser inseridos parmetros relativos a software e hardware. Os

parmetros de software so o tamanho de fila de requisio (modulo2.length) e o nmero de
threads (modulo2.threads) que atendem as requisies em fila. J os parmetros de hardware so
o tamanho da memria principal disponvel e o tamanho de swap que utilizado. Nesse mdulo
h a possibilidade de recusa de requisies por memria cheia. O seguinte clculo efetuado
para analisar se a memria est cheia.
Nesse clculo so utilizados parmetros de hardware. So eles machine.memo.size

(tamanho de memria principal disponvel para uso na transferncia de arquivos) e
machine.disk.size (tamanho de memria swap disponvel para uso na transferncia de arquivos).
Se o valor da memria disponvel for positivo ento efetuada a alocao da memria para a
requisio. Caso contrrio a requisio recusada e retorna ao cliente.
Uma particularidade do SWMAR que se pode utilizar o tamanho de fila infinito. Desta
forma as requisies que chegam ao mdulo 2 so atendidas desde que haja memria disponvel.
Nesse mdulo o parmetro de nmero de threads tem a funo de simular o nmero de recursos
que atende a operao de transferncia de arquivos memria. Por exemplo, se o sistemas contar
com mais de um disco possvel que simule esse cenrio utilizando mais de uma thread.
O fluxo da requisio no mdulo 2 apresentado na figura 5.11.
49
Figura 5.11 Fluxo de requisies no mdulo 2.
Aps executar a transferncia do arquivo para memria possvel 2 diferentes fluxos:

1) a requisio no dinmica e segue ao mdulo 4 que faz o envio do arquivo at a
interface de rede para ser entregue ao requisitante.
2) a requisio do tipo dinmica e necessita de um processamento que executado pelo
mdulo 3 ou Script Engine.
5.5.3 Mdulo 3: Script Engine Execuo de Requisies Dinmicas

Esse mdulo responsvel pela execuo de requisies dinmicas. Para simular o
tempo de execuo de cada requisio foi utilizada uma distribuio exponencial, que segundo
(JAIN, 1991) a distribuio mais indicada para simular o funcionamento do processador
(recurso computacional utilizado nesse mdulo) uma vez que, no possuir interdependncia entre
as tarefas executadas (Memoryless), ou seja, no existe relao entre as tarefas executadas e,
portanto, no h memria entre as tarefas. Na figura 5.12 mostrado o fluxo das requisies do
mdulo 3.
Neste mdulo tambm existe os parmetros de tamanho de fila (modulo3.length) e de
nmero de threads (modulo3.threads) que atendem esse mdulo e seguem o mesmo princpio
50
dos parmetros do mdulo 2, onde o tamanho de fila pode ser adotado como infinito e o nmero
de threads referente ao nmeros de processos que atendem as requisies dinmicas. H
variaes de cenrios para este mdulo. Pode-se simular o script engine na mesma mquina onde
o servidor web est operante ou possvel que o processamento de requisies dinmicas
ocorram em outra mquina.
Figura 5.12 Fluxo de requisies no mdulo 3.
5.5.4 Mdulo 4: Envio de Dados

O mdulo 4 responsvel pelo envio do arquivo requisitado para a placa de rede. Os
componentes de hardware envolvidos so a memria principal, o barramento principal e o
barramento PCI. Nesse mdulo ocorre o mesmo problema de limitao de velocidade que ocorre
no mdulo 2. Aqui a velocidade mxima de transferncia no superior a menor velocidade dos
componentes envolvidos, nesse caso a menor velocidade a do barramento PCI.
Na figura 5.13 exibido o fluxograma do mdulo 4. A diferena neste mdulo a
existncia, alm dos parmetros de tamanho de fila e do nmero de threads que atendem essa
fila, do parmetro de tamanho de buffer, que impacta na operao de transferncia de arquivos
para a interface de rede.
51
Figura 5.13 Fluxo de requisies do mdulo 4.
Neste estgio o arquivo requisitado j est na memria e deve ser enviado para o buffer
de dados e depois, ser enviado para a interface de rede, como mostrado na figura 5.14. Nesta
operao importante notar que o tamanho do arquivo pode ultrapassar o tamanho do buffer de
dados. Sendo assim, deve haver um trabalho extra em dividir esse arquivo em tamanhos iguais
ao tamanho do buffer e calcular o checksum destas partes para que o arquivo enviado seja
exatamente o arquivo que foi requisitado. Essa operao de diviso descrita a seguir.
Esvaziamento
de Buffer
Documento
Requerido
Nmeroenvios
Quebra
arquivo
Buffers
Nmero envios
Tamanhoarquivo
.
.
.
Tamanhobuffer
Figura 5.14 Funcionamento do esvaziamento de buffers.
Um fato importante que ao eleger um buffer para enviar o arquivo, o mesmo deve ser
enviado todo utilizando o mesmo buffer. Dessa forma, o buffer fica dedicado a um mesmo
arquivo enquanto o mesmo est no sistema. O nmero de vezes que o arquivo precisa ser
particionado obtida por meio da equao apresentada na figura 5.14. Isto , o nmero de envios
necessrios igual ao topo da diviso do tamanho do arquivo pelo tamanho do buffer.
52
5.5.5 Estimativa e Tempos de Servio

Talvez a maior dificuldade do projeto foi encontrar dados para serem aplicados no
clculo de tempo gasto em cada um dos mdulos. Para que a simulao se baseia em dados reais
foram pesquisados na literatura benchmarks de servidores web que analisassem separadamente o
tempo em diferentes passos que as requisies atravessam. O que mais se aproximou desse
resultado foi o trabalho de (ALMEIDA, 2000). Nesse trabalho e feita uma anlise em uma
mquina com um processador Intel Pentium 75MHz, 16 MB de memria RAM, uma interface de
rede Ethernet de 10 Mbps e 36MB de memria swap. Uma instrumentao no servidor APACHE
realizada para que se obtenha tempos de diferentes passos que a requisio percorre. De acordo
com esse trabalho h trs etapas que, quando tem os tempos somados, so responsveis pelo
processamento da requisio. So essas etapas:
Manipulao da requisio
Nessa etapa as requisies so manipuladas e encaminhadas para o processamento. Esse
tempo iniciado aps o estabelecimento com o usurio e termina quando a requisio foi tratada
e est pronta para ser processada.
Processamento da requisio
o tempo gasto com o processamento da requisio. Esse tempo envolve o tempo gasto
com a leitura da URL14 e o tempo gasto para mover o arquivo requerido da memria principal ou
do disco para a interface de rede.
Escrita em log
Para toda operao realizada gerado um log com os dados relativos ao cliente e a
requisio efetuada. Essa etapa a que captura o tempo gasto para tal tarefa. O log escrito logo
aps a transferncia do arquivo para a interface de rede.
Toda a vez que uma requisio passa por um mdulo preciso calcular qual o tempo
gasto no mesmo. Para isso foi implementado um mtodo que calcula esse tempo baseado nos
parmetros de hardware, do software (servidor web) e tamanho do arquivo que foi requisitado.
14
Uniform Resource Locator
53
Baseado nesses dados foi possvel estimar os tempos para os quatro mdulos propostos
nesta dissertao. A seguir so apresentados os clculos de tempo de servio em cada mdulo.
Mdulo 1
Dos parmetros iniciais utilizados para gerar uma simulao no SWMAR o CPU o
nico recurso computacional utilizado, para gerar o tempo de utilizao. Por se assemelhar muito
com a etapa de manipulao de requisio de Almeida et al, (2000) foram utilizados os
resultados do trabalho para gerar os tempos para a simulao.
Almeida et al, (2000) executa requisies divididas em trs classes de requisies
estticas feitas por 30 clientes. A diferena entre essas classe baseada no tamanho dos arquivos
requisitados. Em seu trabalho foram obtidos os seguintes tempos:
Tamanho de arquivos
Classe 1
At 12,1KB
Classe 2
Entre 12,1KB e 2,3MB
Classe 3
Maiores 2.3MB
Tempo (ms)
6,20
21,80
23,45
Tabela 4 Classificao de tempos de acordo com as classes de objetos.
Entretanto, esses tempos tm fundamentos apenas se aplicados no mesmo processador

utilizado no trabalho. O que limitaria muito a gama de testes a serem executados no SWMAR
para resolver esse problema foi feito o clculo do FatorCPU que calculado utilizando uma
medida da capacidade do processador realizado pelo benchmark Dhrystone. Nesse benchmark o
processados utilizado no trabalho de (Almeida et al. 2000) pontuou 102Mips15 atravs dessa
pontuao feito o clculo:
Nesse clculo o MipsBase possui o valor de 102 Mips e o valor de MipsAtual um valor
inserido pelo parmetro machine.cpu com esse valor de FatorCPU e os tempos obtidos no trabalho
de Almeida et al, (2000) possvel obter os tempos de utilizao no mdulo 1. Esses tempos so
obtidos com os clculos abaixo.
15
Milhes de instrues por segundo.
54
Com esse clculo possvel encontrar os tempos gastos no mdulo 1 de acordo com o
tamanho dos arquivos requeridos.
Mdulo 2
Neste mdulo utilizado apenas o tempo de transferncia do arquivo do disco para a
memria principal. Como dito anteriormente, no foram considerados outros recursos de
hardware porque essa operao utiliza o DMA. Para o clculo desse tempo utilizado o tempo
de transferncia de disco pois, apesar de ser mais lento que a memria um limitante da
transferncia (BINKERT, 2003). O clculo do tempo dado por:
No clculo, o tamanho do arquivo o tamanho do arquivo requerido na requisio e a

velocidade de disco um parmetro inserido pelo usurio em machine.disk.speed. O tempo de
utilizao do mdulo 2 dado em segundos.
Mdulo 3
Em nenhum dos trabalhos analisados h uma medida baseada nas requisies dinmicas.
No entanto, em (SantAnna et al. 2004) dito que em mdia esse tempo de 2ms. Mas esse
tempo pode variar muito dependendo do processador utilizado no sistema. Por se tratar de uma
operao que no possui interdependncia com outras operaes foi utilizada uma distribuio
exponencial que segundo (JAIN, 1991) modela bem a utilizao de um CPU. Esse tempo foi
encontrado segundo a frmula abaixo:
55
e x,x
0 ,x
f ( x, )
0
0
Um exemplo de distribuio exponencial apresentado na figura 5.15. Nessa figura

possvel verificar o comportamento da distribuio com diferentes valores de lamda.
Figura 5.15 Exemplo de distribuio exponencial.
Mdulo 4
Devido a caracterstica de separao do arquivo em tamanhos de buffers para envio para
a placa de rede utilizado a CPU para fazer o particionamento do arquivo quanto o barramento
de PCI para o envio das partes para a interface de rede. Esse mdulo descreve a operao de
processamento de requisio de Almeida et al, (2000). Em Almeida o tempo gasto para essa
etapa dado pela tabela.
Classe 1 Classe 2 Classe 3
Tempo de CPU no
Processamento de
Requisio
0.01875
0.15056
2.23135
Tabela 5 Tempos de utilizao do CPU no processamento de requisies.
No trabalho de (Almeida et al. 2000) dito que as requisies de classe 1 so menores

que o tamanho do buffer. Logo, no h clculo de checksum. Apenas gasto de processamento
para envio do arquivo para o barramento PCI e o tempo gasto pelo barramento para levar o
arquivo para o interface de rede. Com essa informao se obteve o valor do tempo gasto pelo
CPU apenas para enviar um arquivo para a interface de rede e calcular o checksum. A partir
56
disso, foi possvel calcular o tempo gasto para enviar mltiplas partes de um mesmo arquivo at
a interface de rede segundo a frmula abaixo:
Na frmula, o topo da diviso entre o tamanho do arquivo e o tamanho do buffer encontra

o nmero de partes que o arquivo ser dividido, o tempo de checksum obtido no trabalho de
(Almeida et al. 2000) e tem o valor de 0.01875 segundos e o fator CPU compensar a diferena
da simulao de diferentes CPUs, com esses dados possvel encontrar o tempo que o CPU
gasta para dividir os arquivos. Alm disso, necessrio obter o tempo gasto com a transferncia
das partes do arquivo para a interface de rede, para isso utilizado o nmero de partes que o
arquivo ser dividido multiplicado pelo tamanho do buffer para encontrar o total de bytes que
sero transferido dividido pela capacidade de transferncia do barramento PCI.
5.5.6 Entrada de Dados

Para gerar a simulao necessrio introduzir alguns dados relativos a configuraes de
software (servidor web) e valores que so do hardware Alguns destes parmetros j foram
apresentados durante o decorrer da dissertao. Esses valores so todos inseridos em um mesmo
arquivo de propriedades chamado Configuration.properties. Nesse arquivo existem 15
parmetros de entrada sendo nove para software:
modulo1.lenght=511
modulo1.threads=10
modulo2.lenght=infinity
modulo2.threads=1
modulo3.threads=1
modulo4.threads=128
modulo4.buffer-size=40960
Os parmetros de software so na maioria de dois tipos: length que insere o valor da fila
de requisies de cada mdulo e o parmetro threads que insere o nmero de threads que
57
atendem cada mdulo. No mdulo 1 esses valores so utilizados com os valores padro do
APACHE que so 511 espaos na fila de requisio e 10 threads no pool de threads. Nos
mdulos 2 e 3 h uma diferena no parmetro de length que infinito. O motivo de ser infinito
que garante que, uma vez que a requisio foi atendida no mdulo 1, essa requisio no ser
rejeitada por falta de espao na fila de requisies. Alm do parmetro length h o parmetro
threads que nos mdulos 2 e 3 tambm diferenciado porque h apenas um recurso
computacional que atende esse mdulos, o DMA, e porque apenas um operador que executa as
requisies dinmicas.
O mdulo 4 possui, alm dos parmetros length e threads o parmetro buffer-size que
controla o tamanho do buffer que utilizado para transferir os arquivos para a placa de rede.
Os parmetros de hardware so aqueles que influenciam diretamente no quesito mquina
a ser simulada. Esses parmetros influenciam diretamente nos tempos gastos na execuo de
tarefas em cada um dos mdulos. So eles:
machine.mips=102
machine.pci.speed=104857600
machine.disk.speed=16777216
machine.memo.size=16777216
machine.disk.size=37748736
O parmetro machine.mips relativo CPU do computador e para represent-lo,

utilizada uma mtrica MIPS que comumente utilizada em benchmark para processadores.
Neste projeto foi utilizado os resultado baseados no benchmark Dhystone.
Os parmetros que envolvem a velocidade dos dispositivos so machine.disk.speed,
machine.memo.size e machine.pci.speed. Essas velocidades foram obtidas baseadas nos dados
disponibilizados pelos fabricantes dos respectivos dispositivos.
O ltimo tipo de parmetros que representa os tamanhos da memria principal e a
memria swap. Esses valores influenciam no tamanho disponvel para transferncia de arquivos
no mdulo 2. Se esse recurso for totalmente utilizado gerar recusa de requisies. Toda vez que
um arquivo passa pelo mdulo 2 ele, necessariamente, precisa ser carregado para a memria que
s liberada aps o envio do arquivo (efetuado pelo mdulo 4). Caso o arquivo requisitado no
possa ser carregado para a memria por falta de espao ento a requisio recusada (retorna ao
cliente com erro).
58
5.5.7 Sada de Dados

Como resultado da simulao gerado um arquivo com os dados resultantes. Para o
arquivo de relatrio foi escolhido o padro CSV16 por facilitar a importao e manipulao dos
dados .Nesse arquivo h o resultado da simulao gerado pelo SimPackj e estatsticas relativas a
requisies que foram atendidas e recusadas. A estrutura do arquivo de resposta ser exibida a
seguir.
No incio do arquivo h um relatrio de simulao que gerado pela biblioteca Simpackj.
Nessa parte do arquivo de resposta encontra-se:
O tempo total de simulao;
Total de requisies utilizadas no sistema;
Total de requisies atendidas;
Utilizao do sistema;
Taxa de chegada;
throughput;
Nmero mdio de requisies no sistema;
Tempo mdio de permanncia para cada requisio;
Porcentagem de utilizao de cada mdulo;
Outras informaes que so relevantes para a compreenso do funcionamento do ciclo de
simulao foram adicionadas esse relatrio. Dentre elas pode-se citar a porcentagem de
requisies que foram recusadas e que tiveram sucesso. e uma relao com todas as requisies
que foram atendidas e dados dessas requisies. Tais dados so:
Nmero que a representa a ordem que a requisio foi atendida;
dados da requisio como: tempo, tipo de requisio e tamanho do arquivo;
tempo de utilizao;
Tambm existem dados quanto as requisies que foram recusadas, por exemplo o
nmero de recusas e a porcentagem de recusas nas seguinte ocasies:
16
Comma Separed Values
59
Fila cheia do mdulo 1;

memria cheia;
Falta de buffers;
Alm dos arquivos no formato apresentado so gerados arquivos com as mdias da
simulao. Nesses arquivos so apresentados: o tempo de utilizao, motivo de recusa de
requisio e throughput do cenrio.

Neste captulo foram apresentados os trabalhos relacionados a modelagem de servidores
web alm da biblioteca utilizada para a gerao das simulaes que foram importantes na
implementao e funcionamento do SWMAR um modelo de servidor web com 4 mdulo de
abstraes de atendimento das requisies.
A seo 5.5 discutiu detalhes do simulado, a seo 5.3 apresentou o gerador de cargas
utilizado como carga inicial e na seo 5.4 foram fornecidas informaes sobre a biblioteca
utilizada na implementao do simulador.
O prximo captulo desta dissertao apresenta os testes realizados com cargas de
trabalho fornecidas pelo W4Gen e faz comparaes entre os resultados ao se alterar os
parmetros de simulao, sejam eles de hardware ou de software.
60
CAPTULO
6. Anlise de Resultados
No captulo anterior foi discutido o SWMAR, um simulador de servidor web que possui
quatro mdulos de abstraes de componentes internos. Foram mostradas caractersticas de
implementao e outros trabalhos que auxiliaram no desenvolvimento (W4Gen e SimPack). O
objetivo desse captulo validar o simulador proposto e verificar a sua adequao para a
avaliao de desempenho. Alm disso, pretende-se com este captulo mostrar quais as possveis
formas de se utilizar o simulador desenvolvido. Diante disso, neste captulo sero apresentados
os cenrios e os testes realizados.
6.2. Caractersticas Gerais de Simulao

As simulaes que sero apresentadas neste captulo consideram diferentes cenrios onde
so alteradas algumas caractersticas tanto do hardware a ser utilizado quanto do nmero de
threads e tamanho de fila. O primeiro cenrio utilizado na simulao considera 10 threads no
pool de threads e tamanho de fila de requisies de 511 posies para o servidor web. Os
parmetros de hardware foram obtidos no trabalho de (ALMEIDA et al, 2000) que considera os
seguintes valores: um processador Intel Pentium de 75MHz, 16MB de memria RAM, 36 MB de
memria swap. Entretanto, h certas caractersticas de hardware que no foram descritas no
trabalho de Almeida, para esses valores foram utilizados valores obtidos em pesquisas onde
foram selecionadas placas-me que eram compatveis com o processador. Desta forma, foi
possvel obter a velocidade do barramento PCI (100MBps) e a velocidade do disco (16MBps).
Alm desses dados foram utilizadas caractersticas dos mdulos (abstraes de
componentes internos). No mdulo 2 (transferncia de arquivos para memria principal) foi
61
simulado um disco rgido logo, nesse caso foi utilizado apenas uma thread no parmetro
machine.threads e o tamanho da fila (machine.length) infinito porque uma vez que a requisio
atendida por esse mdulo no h recusa. Os mesmos valores foram utilizados no mdulo 3. No
mdulo 4 foram utilizados, alm do valor do tamanho da fila, valores relacionados a buffer, o
tamanho do buffer e a quantidade de buffers que atendem esse mdulo, respectivamente infinita,
128 buffers de tamanho de 40KB (SANTANNA, 2004).
Para testar o simulador com os parmetros descritos acima foram utilizados logs com
2000 requisies com sobrecarga de 20%. A opo de parada por nmero de requisies foi
escolhidas porque, se escolhida a gerao de logs por tempo haveria uma diferena no nmero de
requisies consideradas em cada cenrio simulado e a comparao do throughput obtido para os
diferentes tipos de logs (tradicional, acadmico e informativo/notcias) ficaria prejudicada. Na
figura 6.1 so apresentadas as caractersticas das cargas iniciais baseadas nos nmeros de objetos
existentes em cada log.
Caractersticas dos Logs
1200
Requisieses
1000
800
Tradicional
600
Academico
Informativo
400
200
0
image
html
binary
dynamic document
video
text
script
audio
Figura 6.1 Caractersticas das diferentes cargas iniciais.
Na figura 6.1 os objetos foram ordenados de acordo com o maior nmero de objetos do
tipo tradicional, foi feita essa ordenao para que se observe a caracterstica de cauda pesada
nesse tipo de log e tambm para que se possa analisar as diferenas entre os demais tipos de logs.
Por exemplo, possvel observar que h mais imagens no tipo tradicional seguindo a lgica
explicada anteriormente (possui muitas pginas estticas com informaes e figuras). No tipo
acadmico o nmero de documentos requisitados muito superior aos outros tipos de logs, j no
62
tipo informativo/notcias as requisies dinmicas e de scripts so maiores devido a agilidade em

que as informaes so atualizadas.
Para uma primeira anlise dos resultados gerados pelo SWMAR foi feita uma primeira
bateria de testes utilizando os parmetros do trabalho de Almeida e se obteve os resultados
apresentados na figura 6.2. Nessa figura, possvel verificar o nmero de requisies atendidas e
o motivos de recusa de requisies. Como se pode observar, apesar dos trs logs possurem o
mesmo nmero total de requisies o nmero de atendimentos, de recusas e motivos de recusas
diferem graas as diferenas entre tipos, tamanhos e distribuies dos objetos.
Caractersticas dos Logs
1600
1421
1369
1400
1275
Requisies
1200
Atendimento
1000
800
memria cheia
724
631
Fila cheia mdulo 1
578
600
falta buffers
400
200
1
0
Tradicional
Acadmico
Informativo
Figura 6.2 Caractersticas dos trs tipos de logs.
Tambm possvel analisar a porcentagem de utilizao de cada um dos mdulos atravs

da figura 6.3. Nesse grfico possvel verificar que no mdulo 1 a utilizao de menos de 4%
na maior utilizao.
Com os dados de porcentagem de utilizao (figura 6.3) e os dados de recusas (figura
6.2) possvel gerar duas baterias de testes: (1) fazendo alteraes visando aumentar o nmero
de requisies atendidas ou (2) tentar aumentar a capacidade computacional aumentando
parmetros de hardware, dessa forma tenta-se aumentar a velocidade em cada um dos mdulos
para aumentar a capacidade de atendimento do simulador simulado. Partindo dessas duas opes
foram gerados cenrios que ataquem o ponto que est gerando mais recusas, no caso dos testes, o
mdulo 1.
63
Sendo assim foram feitas provas com a alterao dos parmetros do mdulo 1 para
analisar quais so os resultados obtidos. Para essas novas provas foram criados mais trs
cenrios.
Utilizao dos mdulos
Porcentagem de Utilizao
100,00
90,00
80,00
70,00
60,00
Tradicional
50,00
Acadmico
40,00
Informativo/Notcia
30,00
20,00
10,00
0,00
Utilizao
Mdulo 1
Utilizao
Mdulo 2
Utilizao
Mdulo 3
Utilizao
Mdulo 4
Figura 6.3 Utilizao dos mdulos.
Os cenrios so descritos na tabela 6.1. Os 3 cenrios adicionais que extrapolam os

valores reais, como no caso do tamanho da fila de requisies alterado para infinito e o nmero
de threads do pool aumentado para 500 threads.
modulo1.length
modulo1.threads
Cenrio 1 Cenrio 2 Cenrio 3 Cenrio 4

511
Infinito
511
Infinito
10
10
500
500
Tabela 6 Cenrios de simulao com alterao de parmetros do Mdulo 1.
Como resultado dos cenrios foram obtidos os seguintes resultados:

Log Tradicional
2500
1999
1999
Requisies
2000
1500
1000
Atendimento
1334
1275
memria cheia
Fila cheia mdulo 1
724
falta buffers
665
500
1
1 0 0
Cenrio 1
Cenrio 2
1 0 0
Cenrio 3
Cenrio 4
Figura 6.4 Resultado de alterao de parmetros do mdulo 1 - Tradicional.
64
Log Acadmico
2500
2000
2000
Requisies
2000
1530
Atendimento
1369
1500
memria cheia
Fila cheia mdulo 1
1000
falta buffers
631
470
500
0
0 0 0
Cenrio 1
Cenrio 2
0 0 0
Cenrio 3
Cenrio 4
Figura 6.5 - Resultado de alterao de parmetros do mdulo 1 Acadmico.
Log Informativo/Notcias
2500
1998
Requisies
2000
1998
1720
Atendimento
1421
1500
memria cheia
Fila cheia mdulo 1
1000
falta buffers
578
500
280
1
2 0 0
Cenrio 1
Cenrio 2
2 0 0
Cenrio 3
Cenrio 4
Figura 6.6 - Resultado de alterao de parmetros do mdulo 1 Informativo/Notcias.
Nas figuras 6.4, 6.5 e 6.6 so apresentados resultados que, a princpio , provam que
aumentar o tamanho da fila de requisies a melhor sada para aumentar o nmero de
requisies atendidas por esse servidor web. Entretanto, mesmo aumentando o tamanho de fila
no possvel garantir que todas as requisies sejam atendidas, como pode ser observado ,
comea a surgir recusas por falta de memria.
Outra caracterstica que, devido os valores de hardware no serem alterados, os valores
de tempo total (medido em segundos) de atividade das simulaes no sofrem grandes alteraes
e o troughput (medido em KBps) s recebe um ganho porque esto sendo atendidas mais
requisies at o fim da simulao, como pode ser observado nas figuras 6.7, 6.8. Na figura 6.9
65
observado um comportamento diferente. Por possuir muitas requisies dinmicas, o servidor

carregado com o log informativo/notcias j apresentava uma alta utilizao (veja figura 6.3)do
mdulo 3.. Sendo assim, o aumento de requisies nesse mdulo j saturado gera impacto no
desempenho do servidor simulado (throughput). Pode-se observar que ao aumentar o nmero de
requisies no sistema com o aumento de fila a utilizao do mdulo 1 aumenta o nmero de
requisies com sucesso, mas o tempo de simulao continua o mesmo uma vez que o sistema
no estava sobrecarregado. Esse caso vlido tanto para os logs do tipo tradicional quanto o
acadmico. Entretanto, ao analisar o log informativo/notcias, que j tinha o mdulo 3 muito
carregado, verifica-se que com o aumento do nmero de requisies no sistema o nmero de
atendimentos mas com uma degradao da qualidade de servio. O mdulo 3 que j estava muito
carregado sofre uma super utilizao que gera diminuio do throughput.
Throughput - Tradicional
600,00
500,00
495,44
495,44
449,63
400,00
throughput
307,32
300,00
tempo total
200,00
132,03
100,00
132,03
132,03
132,03
0,00
Cenrio 1
Cenrio 2
Cenrio 3
Cenrio 4
Figura 6.7 Throughput e tempos de simulao Tradicional.
Throughput - Acadmico
1200,00
1085,75
1071,87
1000,00
816,76
800,00
throughput
600,00
tempo total
400,00
325,37
200,00
0,00
53,04
Cenrio 1
58,38
Cenrio 2
59,06
Cenrio 3
58,08
Cenrio 4
Figura 6.8 Throughput e tempos de simulao Acadmico.
66
Throughput - Informativo/Notca
600,00
500,00
495,60
486,18
400,00
300,00
200,00
338,09
323,92
throughput
tempo total
248,30
226,03
179,95
176,37
100,00
0,00
Cenrio 1
Cenrio 2
Cenrio 3
Cenrio 4
Figura 6.9 Throughput e tempos de simulao Informativo/notcia.
Outra maneira de se obter um aumento no nmero de requisies atendidas atravs de

alterao dos valores de hardware, dessa forma, aumentando o poder computacional dos
mdulos. Para escolher quais valores devem ser alterados, mais uma vez foram utilizadas as
informaes de porcentagem de utilizao dos mdulos obtidas no cenrio 1.
Com as informaes obtidas atravs dos testes anteriores, foram criados 4 cenrios
apenas com alterao de alguns parmetros de hardware. Como pode ser visto na tabela 7:
Cenrio 4 Cenrio 5 Cenrio 6 Cenrio 7
machine.cpu
2472Mips 102Mips 102Mips 2472Mips
machine.disk.speed
16MBps 300MBps
16MBps 300MBps
machine.pci.speed
100MBps 100MBps 533MBps 533MBps
Tabela 7 Cenrios de testes com alteraes de parmetros de hardware.
Nesses novos cenrios os parmetros foram escolhidos atravs de dados de recursos

computacionais reais. Por exemplo, o valor de machine.cpu baseado em resultados
apresentados em testes sobre um processador Intel Pentium 4 de 1,3GHz. O valor de
machine.disk.speed foi baseado em dados de fabricantes de discos rgidos SATA17 2 ou SATA
300 que obtm 300 MBps de taxa de transferncia. E por fim, o parmetro machine.pci.speed
tambm foi extrado de dados de fabricantes sobre o barramento PCI que alcana 533 MBps.
Aplicando esses cenrios foram obtidos os resultados apresentados nas figuras 6.10, 6.11 e 6.12.
Nas figuras possvel analisar que no houve grandes ganhos em nmero de requisies
17
Serial ATA.
67
atendidas. Foi inserido o cenrio 1 para que fosse feita uma comparao com os resultados
obtidos nos outros cenrios.
Log Tradicional
1400
1275
1275
1266
1275
1266
1200
Requisies
1000
Atendimento
800
733
724
724
733
724
memria cheia
Fila cheia mdulo 1
600
falta buffers
400
200
1
0
Cenrio 1
Cenrio 5
Cenrio 6
Cenrio 7
Cenrio 8
Figura 6.10 Resultado de alterao dos parmetros de hardware para log tradicional.
Log Acadmico
1600
1369
1400
1369
1368
1369
1368
Requisies
1200
Atendimento
1000
800
memria cheia
631
632
631
631
632
Fila cheia mdulo 1
600
falta buffers
400
200
0
0
Cenrio 1
Cenrio 5
Cenrio 6
Cenrio 7
Cenrio 8
Figura 6.11 Resultado de alterao dos parmetros de hardware para log acadmico.
Log Informativo/Notcia
1600
1421
1421
1411
1421
1411
1400
Requisies
1200
Atendimento
1000
memria cheia
800
600
588
578
578
Fila cheia mdulo 1
588
578
falta buffers
400
200
1
0
Cenrio 1
Cenrio 5
Cenrio 6
Cenrio 7
Cenrio 8
Figura 6.12 - Resultado de alterao dos parmetros de hardware para log informativo/notcias.
68
Apesar disso possvel verificar que sim houve uma diminuio dos mdulos com o
aumento da capacidade dos hardwares como pode ser observado na figura 6.13, 6.14 e 6.15. A
melhora mais expressiva no mdulo 3, nos cenrios que a capacidade da CPU aumentada.
35,00
33,10
33,00
40,00
34,25
Porcentagem utilizao dos mdulos - Log Tradicional
Util Mdulo 1
25,00
Util Mdulo 2
Util Mdulo 3
11,28
15,00
11,41
20,00
11,45
Porcentagem
30,00
Util Mdulo 4
0,08
1,89
1,46
0,73
2,00
0,10
2,00
1,88
0,08
0,06
1,64
0,55
5,00
2,00
1,88
10,00
Cenrio 1
Cenrio 5
Cenrio 6
Cenrio 7
Cenrio 8
0,00
Figura 6.13 Porcentagem de utilizao dos mdulos log tradicional.
92,61
91,73
100,00
92,99
Porcentagem utilizao dos mdulos - Log Acadmico
90,00
70,00
Util Mdulo 1
60,00
Util Mdulo 2
50,00
Util Mdulo 3
40,00
Util Mdulo 4
Cenrio 6
0,27
0,11
6,76
0,57
4,00
0,11
Cenrio 5
0,00
Cenrio 7
Cenrio 8
3,85
2,00
0,27
3,73
6,49
1,33
Cenrio 1
3,83
1,99
10,00
5,81
20,00
5,81
30,00
5,63
Porcentagem
80,00
Figura 6.14 Porcentagem de utilizao dos mdulos log acadmico.
73,80
80,00
74,20
75,99
Porcentagem de utilizao dos mdulos - Log Informativo
70,00
Util Mdulo 1
50,00
Util Mdulo 2
40,00
Util Mdulo 3
30,00
Cenrio 1
Cenrio 7
0,04
0,06
2,98
0,45
Cenrio 6
9,16
Cenrio 5
0,88
1,98
0,88
0,11
0,00
0,04
1,98
3,10
0,82
0,88
1,98
10,00
9,31
Util Mdulo 4
20,00
9,32
Porcentagem
60,00
Cenrio 8
Figura 6.15 Porcentagem de utilizao dos mdulos log informativo/notcia.
69
importante ressaltar que os logs de entradas foram sobrecarregados. Logo, apresentam

um cenrio onde uma grande parte de requisies possuem o mesmo tempo de chegada. Sendo
assim, essa uma simulao de um curto espao de tempo de um servidor web muito
requisitado. Dessa forma, uma grande parte das requisies rejeitada devido o tamanho da fila
de requisies e ao nmero de threads no pool que atendem o servidor web. Com isso foi criado
mais um cenrio que possui as mesmas caractersticas de hardware que o cenrio 8 mas com
alteraes no tamanho da fila de requisies e no nmero de threads do pool de threads, ou seja,
um melhor cenrio de hardware unido a melhora obtida com o aumento dos parmetros do
mdulo 1. Portanto, no cenrio 9 a fila possui tamanho de 1022 (100% a mais que o padro) e o
pool possui 20 threads (100% a mais que o padro).
Mesmo com as melhoras agregadas, o cenrio 9 no obteve 100% de requisies
atendidas (ficou entre 60% no pior caso e 75% no melhor caso).
Para verificar o resultado da alterao no tamanho da fila e nmero de threads no pool
foram feitas comparaes com os cenrios anteriores e levado em conta o throughput de cada
cenrio analisado nesse captulo em todos os cenrios testados.
Throughput - Log Tradicional
30
9,
18
30
7,
32
30
7,
32
44
6,
76
49
5,
44
30
9,
17
300,00
30
7,
32
400,00
44
9,
63
49
5,
44
500,00
throughput
200,00
100,00
0,00
Ce
n
rio
1
Ce
n
rio
2
Ce
n
rio
3
Ce
n
rio
4
Ce
n
rio
5
Ce
n
rio
6
Ce
n
rio
7
Ce
n
rio
8
Ce
n
rio
9
KBytes por segundo
600,00
Figura 6.16 Throughput Log Tradicional.
70
34
0,
24
200,00
throughput
32
7,
70
61
0,
98
600,00
61
0,
56
81
6,
76
800,00
400,00
10
47
,7
4
10
71
,8
7
1000,00
32
5,
37
KBytes por segundo
1200,00
10
85
,7
5
Throughput - Log Acadmico
Ce
n
rio
1
Ce
n
rio
2
Ce
n
rio
3
Ce
n
rio
4
Ce
n
rio
5
Ce
n
rio
6
Ce
n
rio
7
Ce
n
rio
8
Ce
n
rio
9
0,00
Figura 6.17 Throughput Log Acadmico.
Throughput - Log Informativo/Notcias

700,00
57
9,
84
500,00
100,00
32
4,
13
32
3,
92
32
3,
92
32
4,
13
throughput
17
9,
95
200,00
17
6,
37
300,00
24
8,
30
400,00
32
3,
92
KByte por segundo
600,00
Ce
n
rio
1
Ce
n
rio
2
Ce
n
rio
3
Ce
n
rio
4
Ce
n
rio
5
Ce
n
rio
6
Ce
n
rio
7
Ce
n
rio
8
Ce
n
rio
9
0,00
Figura 6.18 Throughput Log Informativo/Notcia.
Como resultado da anlise dos throughputs possvel observar as caractersticas que

realmente afetam o throughput. No casos dos logs testados o maior gargalo era mesmo a fila de
reaquisies e o nmero de threads no pool. Tendo em vista que a sobrecarga aplicada nos logs
aumentou o nmero de requisies com tempo de chegada igual a um ponto que o servidor web
no poder atender as requisies mesmo possuindo pouca utilizao dos mdulos.
Tambm possvel aumentar o throughput do sistema apenas alterando o hardware como
observado nos cenrios de 5 a 8.
71

O objetivo do presente captulo foi apresentar os resultados de uma avaliao de
desempenho utilizando o SWMAR com cargas de trabalho geradas pelo W4Gen. Para gerar
essas avaliaes foram considerados nove cenrios diferentes onde o cenrio 1 extrado do
trabalho de (Almeida et al. 2000), trs cenrios so alteraes de parmetros relacionados a
caractersticas do servidor web, quatro cenrios so alteraes visando melhoria de atendimento
modificando o hardware e um cenrio faz melhoria tanto de software quanto de hardware.
Houve casos que os resultados foram melhores devido a caracterstica da carga inicial.
No prximo captulo sero apresentadas as concluses obtidas com o desenvolvimento
deste trabalho, as contribuies e as propostas de trabalhos futuros relacionados avaliao de
desempenho.
72
CAPTULO
7. Concluso
A Web um sistema em crescimento que passou de um simples meio de publicao para
disseminar informaes, por meio do uso de pginas estticas, para uma infra-estrutura com
suporte a processamento de transaes, com uso de pginas dinmicas com acesso regular a
banco de dados e pginas personalizadas. Com essa evoluo, muitos esforos j foram e sero
dispendidos para melhorar o tempo de resposta das requisies dos usurios.
Dentre os diversos estudos, pode-se destacar o modelo de servidor web com
diferenciao de servios (SWDS), cujo objetivo oferecer uma arquitetura para o fornecimento
de servios diferenciados, integrando os princpios de QoS aplicados na camada de rede.
No entanto, a validao do modelo SWDS, executada por meio de simulaes usando o
trace da copa do mundo de 1998, no demonstrou sua viabilidade com base nas caractersticas
atuais, constituindo um comportamento antigo de uma poca onde o protocolo HTTP 1.1 e
requisies dinmicas eram pouco usadas. Ao longo desses ltimos anos, muitas tecnologias
mudaram, provocando uma mudana na demanda dos servidores web.
Com base nessa idia, a finalidade deste trabalho oferecer um modelo de servidor web
que possa integrar ao modelo do SWDS um modelo de servidor web que possui caractersticas
mais prxima de um servidor web real (SWMAR) substituindo o cluster de servidores web,
agregado as cargas de trabalho geradas pelo W4Gen. Assim, este trabalho proporciona a
integrao de vrios trabalhos j realizados e permite obter novos resultados mais confiveis e
mais realistas. Dentre os trabalhos desenvolvidos no grupo de Sistemas Distribudos e
Programao Concorrente do Instituto de Cincias Matemticas e de Computao da
Universidade de So Paulo que podem ser beneficiados, por meio de simulaes mais realistas,
utilizando-se o simulador desenvolvido neste trabalho vale ressaltar:
73
O trabalho de iniciao cientfica de Traldi et al. (2004) consistiu em transportar o

algoritmo Weighted Fair Queuing (WFQ), projetado para o nvel de rede, para o
nvel de aplicao, sendo includo, assim, no modelo de Servidor Web com
Diferenciao de Servios (SWDS).
O trabalho de iniciao cientfica de Barbato et al. (2005) consistiu em
implementar o algoritmo RSVAdap, cujo objetivo particionar dinamicamente o
cluster de servidores Web, de acordo com a carga de trabalho vigente no sistema,
a fim de melhorar o atendimento dos clientes de mais alta prioridade.
O trabalho de mestrado de Estrella (2006) estudou a validao de mecanismos de
negociao no mdulo de controle de admisso do modelo SWDS, verificando
uma melhoria no atendimento aos clientes pertencentes a uma determinada classe
de servio para que esses tivessem uma qualidade de servio garantida.
O trabalho de mestrado de Mouro (2005) tem como objetivo introduzir a
capacidade de reconhecimento de sesses HTTP no modelo do servidor SWDS,
caracterstica atualmente no contemplada.
O trabalho de mestrado de Messias (2006) teve como objetivo implementar um
prottipo de servidor web com diferenciao de servios e compar-lo com um
servidor web tradicional para avaliar os possveis ganhos em ambiente real.
7.2. Contribuies
A maior contribuio deste projeto de mestrado foi desenvolver um modelo e o
respectivo simulador de servidor web com abstraes de componentes internos que tratam as
requisies (SWMAR) cujo objetivo facilitar diversos estudo em andamento, visando
avaliao do desempeno da Web, aumentando a capacidade de anlise de diferentes cenrios com
diferentes configuraes de servidores web. O servidor desenvolvido flexvel e apresenta a
possibilidade de alterao no comportamento de um servidor web, por meio da alterao de
diferentes parmetros, tanto de software quanto de hardware do servidor. Por exemplo, pode-se
alterar a poltica de atendimento da fila de requisies de FIFO para uma poltica de prioridades
de maneira rpida graas aos mtodos disponveis pela biblioteca SimPack.
74
Alm do desenvolvimento do prottipo, tm-se a realizar diversas simulaes que

ilustram formas de utilizao de simulador desenvolvido. Por meio dos exemplos apresentados
pode-se verificar como detectar pontos de gargalo do sistema, quantificar como alteraes no
hardware e no software do sistema inferem em seu desempenho e analisar a influncia de cada
fator avaliado e a interao existente entre os fatores.
Como todos os parmetros utilizados no exemplo desenvolvido so realistas e foram
propostos fundamentando-se em dispositivos existentes, os resultados obtidos na simulao
podem ser utilizados para avaliar o comportamento de um servidor web.
7.3. Sugestes para Trabalhos Futuros

O projeto desenvolvido apresentou como motivao a integrao de diversos trabalhos
desenvolvidos no grupo de Sistemas Distribudos e Programao Concorrente. A continuidade
deste trabalho deve prever o desenvolvimento de novas funcionalidades para o simulados,
visando possibilidade de comportar todas as simulaes contidas nos trabalhos citados na seo
7.1. Desta forma, algumas sugestes de trabalhos futuros:
Atualizar as medidas de tempo de utilizao de cada mdulo do SWMAR atravs
de uma analise de desempenho feita pela monitorao de um servidor web real.
Gerar um cluster com vrios servidores web utilizando o SWMAR. Dessa forma,
pode-se gerar cluster heterogneos ou homogneos e verificar o comportamento
nesses diferentes cenrios.
Agregar ao SWMAR a abstrao do meio fsico de comunicao entre o cliente e
o servidor web, a rede.
Integrar ao SWDS as cargas geradas pelo W4Gen e como modelo de servidor web
SWMAR.
75
76
8. Referncias Bibliogrficas
ABDELZAHER, T. F.; LU, C. Modeling and Performance Controlo of Internet Servers. In.
Proceeding of the 39th IEEE, Dez. 2000.
ALMEIDA, J , M.; ALMEIDA, V.; YATES, D. Measuring the Behavior of a World-Wide Web
Server. 2000.
ARLITT, M. F.; WILLIAMSON, C. L. Web Server Workload Characterization: the search for
invaliants. In: Proceedings of ACM SIGMETRICS 96 . [S.I. : s.n.], 1996. p.126-37.
BANGA, G.; DRUSCHEL, P; MOGUI, J.C Better operating system features for faster network
servers. ACM Performance Evaluation Review, 1998, p. 23-30.
BERNERS-LEE, T.; MASINTER, L.; McCAHILL, M. Uniform Resource Locators, [S.I.], Dez.
1994. RFC 1738, IETF.
BINKERT, N. L., HALNOR, E. G., REINHARDT, S. K. Network-Oriented Full-System
Simulation using M5. In Workshop on Computer Evaluation using Commercial Workloads, Fev
2003.
CARDELLINI, V.; CASALICCHIO, E.; COLAJANNI, M.; YU, P. S. The State of the Art in
Locally Distributed Web-Server Systems. In: ACM Computing Surveys, 2002, v. 34, n. 2, p. 263311.
CERF, V. C.; KAHN, R. E. "A Protocol for Packet Network Interconnections", IEEE Transaction
on Communications, Vol. COM-22, No. 5, Mai 1974.
COFFMAN, K. G; ODLYZKO, A. M. Internet growth: Is there a Moores Law for data traffic?
In Handbook of Massive Data Set, 2001.
COMER, D. E. Internetworking with TCP/IP: Principles, Protocols and Architecture. 4.ed. [S.l.]:
Prentice Hall, 2000.
DEVLIN, B.; GRAY, J.; LAING, B.; SPIX, G. Scalability terminology: Farms, clones, partitions,
and pack: RACS and RAPS. Tech Rep. MS_TR-99-85, Microsoft Research, 1999.
DILLEY, J.; FRIEDRICH, R.; JIN, T.; ROLIA, J. Web server performance measurements and
modeling techniques, Performance Evaluation, 2000.
ESTRELLA, J, C,. Mecanismos de negociao no mdulo de controle de admisso da arquitetura
de servidor web com diferenciao de servios (swds). Qualificao (Mestrado) ICMC-USP, So
Carlos, 2005.
FIELDING, R. Hypertext Transfer Protocol -- HTTP/1.1, [S.I.], Jun. 1999. RFC 2616, IETF.
FRANCS, C. R. L. et al. Modelagem e Especificao Utilizando Redes de Petri e Statecharts.
Monografia (Notas Didticas) ICMC-USP, So Carlos, 2000.
FRANCS, C. R. L. Uma extenso estocstica para Statecharts. Dissertao (Mestrado), ICMCUSP, So Carlos, 1998.
GANDHI, N.; TILBURY, D. M.; DIAO, Y.; HELERSTEIN, J.; PAREKH, S. MIMO Control of a
Apache Web Server: Modeling and Controller Design. In Proceeding of the American Control
77
Conference, Mai. 8-10, 2002.

GILDER, G. Fiber keeps its promise: Get ready. Bandwidth will trple each year for the next 25.
Forbes, 7 abr, 1997.
GRAY, j.; SHENOY, P. Rules of thumb in data engineering. In Proceedings of the 16th IEEE
Internetional Conference on Data Engineering., IEEE Computer Soc. Press, 2000, p. 3-10.
HAREL, D. Statecharts: A Visual Formalism for Complex Systems, Science of Computer
Programming. [S.l.]: John Wiley, 1987.
HEIDERMANN, J.; OBRACZKA, K.; TOUCH, J. Modeling the Performance of HTTP Over
Several Transport Protocols. IEEE/ACM Transactions on Networking, v. 5, n.5. Out. 1997.
HUITEMA, C. Network vs. server issues in end-to-end performance. Keynote speech at
Performance and Architecture of Web Servers Workload. Disponvel em :
http://kkant.csswebhost.com/PAW2000/huitma_keynote.ppt. Acesso em: 13 Jan. 2006
JAIN, R. The Art of Computer Systems Performance Analysis: Techniques for Experimental
Design, Measurement, Simulation and Modeling. [S.l.]: John Wiley, 1991.
KUROSE, J. F.; ROSS, K. W. Redes de Computadores, 2 ed [S.I.]. Addison Wesley, 2003.
MENASC, D. A.; ALMEIDA, V. A. F. Planejamento de capacidade para Servios na Web. 1.
ed [S.I.]: Campus, 2003.
MOCKAPETRIS, P. Domain Names - Concepts and Facilities. Req. For Com. 1034, USC
Information Sci. Institute, Nov. 1987.
MOURO, h, C,. Reconhecimento de Sesses HTTP em um Modelo para Servidor Web com
Diferenciao de Servios. Dissertao (Mestrado) ICMC-USP, So Carlos, 2005.
POSTEL, J. Domain Name System, [S.I.], Fev. 1984. RFC 897, IETF.
POSTEL, J. Internet Protocol, [S.I.], Set. 1981. RFC 791, IETF.
POSTEL, J. Simple Mail Transfer Protocol, [S.I.], Aug. 1982. RFC 821, IETF.
POSTEL, J. Transmission Control Protocol, [S.I.], Set. 1981. RFC 793, IETF.
POSTEL, J; REYNOLDS, J. File Transfer Protocol, [S.I.], Out. 1985. RFC 959, IETF.
REESER, P.; HARIHARAN, R. Analtic Model of Web Servers in Distributed Enviroment
ROBERTSOON, A.; WITTENMARK, B.; KIHL, M. Analysis and design of a admission control
in web-server systems. In. Proceeding of the American Control Conference, Jun. 2003.
SANT ANNA FILHO, A. Modelo de servidor Web com conexes persistentes e carga orientada
a sesso. Tese (Doutorado) ICMC-USP, So Carlos, 2004.
SANTANA, R. H. C. et al. Tcnicas para Avaliao de Desempenho de Sistemas Computacionais.
Monografia (Notas Didticas) ICMC-USP, So Carlos, 1994. SPEC. SPECweb99 Benchmark.
2001. Disponvel em: <http://www.spec.org/osg/web99/>. Acesso em: 04 Nov. 2004.
SILVA, L. H. C. Um Gerador de Cargas de Trabalho Sintticas - Aplicao ao Modelo de
Servidor Web com Diferenciao de Servios, So Carlos, 2005. (Monografia de Qualificao de
Mestrado) - Instituto de Cincias Matemticas e de Computao - ICMC, USP.
SILVA, L. H. Caracterizao de carga de trabalho para testes de modelos de servidores web, So
Carlos, 2006 (Dissertao de Mestrado) Instituto de Cincias Matemticas e de Computao
78
ICMC-USP.
SIMPSOM, W. The Point-to-Point Protocol (PPP), [S.I.], JuL. 1994. RFC 1661, IETF.
SLOTHOUBER, P. A Model OF Web Server Performance, 1995.
SOCOLOFSKY, T.; KATE, C. TCP/IP Protocol, [S.I.], Jan. 1991. RFC 1180, IETF.
TANENBAUM, A. Distributed Operating Systems. 3 ed. [S.I.] Prentice Hall, 1995.
TANENBAUM, A. S. Computer Networks. 4 ed. [S.I.]. Prentice Hall, 2002.
TEIXEIRA, M. A. M. Suporte a Servios Diferenciados em Servidores Web: Modelos e
Algoritmos. Tese (Doutorado) ICMCUSP, So Carlos, 2004.
van der MEI, R.; HARIHARAN, R.; RESSER, P. K. Web Server Performance Modeling.
Telecommunications Systems, v. 16, n. 3, p. 361-378, 2001.
WELLS, L.; CHRISTENSEN, S.; KRISTENSEN, L. M.; MORTENSEN, K. H. Simulation Based
Performance Analysis of Web Servers In: Proceedings of 9th International Workshop on Petri
Nets and Performance Models, PNPM'01 Aachen, Sept. 11-14 , 2001, Reinhard German and
Boudewijn Haverkort (eds.), IEEE, pages 59-68. 2001.
79
This document was created with Win2PDF available at http://www.win2pdf.com.

The unregistered version of Win2PDF is for evaluation or non-commercial use only.
This page will not be added after purchasing Win2PDF.

Geraldo

Enviado por

Dados do documento

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

Geraldo

Enviado por

Direitos autorais:

Formatos disponíveis

Modelo de Servidor Web com Quatro Mdulos de

Atendimento de Requisies (SWMAR)

SERVIO DE PS-GRADUAO DO ICMC-USP

Data de Depsito: 28.02.2008

Modelo de Servidor Web com Quatro Mdulos de

Orientadora: Prof. Dr. Regina Helena Carlucci Santana

Dissertao apresentada ao Instituto de Cincias

Dedico este trabalho ao meu filho

Esta dissertao de mestrado apresenta a implementao e validao de

ANLISE DE DESEMPENHO E SIMULAO .......................................................17

SERVIDORES WEB ......................................................................................................25

ANLISE DE RESULTADOS ......................................................................................61

CONSIDERAES INICIAIS ..........................................................................................61

FIGURA 6.15 PORCENTAGEM DE UTILIZAO DOS MDULOS LOG INFORMATIVO/NOTCIA...69

Advanced Research Projects Agency

Informaes publicadas em tempo real.

Hoje na Internet trafegam, alm de documentos textuais, documentos multimdia (vdeos

1.4. Estrutura da Dissertao

A capacidade dos computadores dobra a cada 18 meses.

No captulo 2 sero apresentadas a Internet e a Web, conceitos importantes para situar o

2.2. Modelo de referncia ISO/OSI e Protocolo TCP/IP

Figura 2.1 - Camadas, protocolos e interfaces

Em 1997 a ISO (International Organization for Standardization) tomou o primeiro passo

Tabela 1 Camadas e funes do modelo OSI

Uma camada de protocolo pode ser implementada em software, em hardware, ou em uma

2.2.1 Camada de Aplicao

Na figura 2.2 exemplificada a comunicao entre as camadas de aplicao.

Figura 2.2- Camada de Aplicao (KUROSE; ROSS, 2003)

2.2.2 Camada de Transporte

Figura 2.3 - Camada de transporte (KUROSE; ROSS, 2003)

2.2.3 Camada de Rede

Figura 2.4 - Camada de rede (KUROSE; ROSS, 2003)

2.2.4 Camada de Enlace

dos variados protocolos de camada de enlace. Os pacotes de camada de enlace so denominados

Figura 2.5 - Camada de enlace (KUROSE; ROSS, 2003)

2.2.5 Camada Fsica

2.3. A World Wide Web

Figura 2.6 - Esquema do protocolo URL.

As pginas so referenciadas usando o URL (Uniform Resource Locators). O URL,

2.4. Protocolo HTTP

cliente-servidor. Os servidores produzem contedo (pginas HTML) independente da plataforma

O protoloco HTTP possui dois tipos de mensagens, as de requisio e as de resposta. Nas

Figura 2.8 - Requisio HTTP.

A tabela a seguir mostra alguns mtodos de requisio do protocolo HTTP.

As mensagens de resposta seguem o padro mostrado na figura 2.9.

Figura 2.9 - Resposta HTTP.

Na primeira linha tem-se a verso do protocolo e um cdigo de status, no exemplo, a

Tabela 3 Cdigos de resposta do protocolo HTTP 1.1.

2.5. Consideraes finais

3.2. Carga de trabalho

devido diferena entre as instrues utilizadas.

3.4. Mtodos de Avaliao de Desempenho Tcnicas de Aferio

Conjunto Reduzido de Instrues de Computador.

Os benchmarks possuem baixo custo, porm apresentam limitaes como influncia do

sinais em pontos desejados do hardware do sistema; contadores incrementados quando um

3.5. Mtodos de Avaliao de Desempenho Tcnicas de

3.5.2 Soluo Analtica (Teoria de Filas)

3.6. Consideraes Finais

4.2. Funes do Servidor Web

4.3. Arquitetura dos servidores web

Figura 4.1 - Tipos de arquitetura de servidores web

As diferentes arquiteturas dos servidores web so motivadas especialmente pelo upgrade

4.3.1 Requisies Estticas

Figura 4.2 - Esquema cliente-servidor nas requisies estticas