OTIMIZAÇÃO DE DESEMPENHO EM AMBIENTES WEB: UMA ABORDAGEM
BASEADA EM MONITORAMENTO, CARACTERIZAÇÃO DA CARGA DE TRABALHO
E AJUSTE DE PARÂMETROS ARQUITETURAIS
Carlos Augusto P.S. Martins
Pontifícia Universidade Católica de Minas Gerais
[email protected]
João Paulo Coelho Furtado
Faculdade Infórium de Tecnologia - FIT
[email protected]
Marcílio Jr. de Andrade
Pontifícia Universidade Católica de Minas Gerais
[email protected]
Resumo:
A crescente necessidade de otimização de desempenho em ambientes web abre
espaço para uma enorme variedade de técnicas de otimização. Nesse artigo,
apresenta-se um estudo de caso real onde foi utilizada uma abordagem baseada em
monitoramento de indicadores de desempenho e caracterização de carga de trabalho
no intuito de evidenciar o comportamento geral do ambiente possibilitando a realização
de ajustes de parâmetros arquiteturais. Os resultados iniciais apresentados evidenciam
muitos dos benefícios de desempenho trazidos por esse tipo de implementação.
1. Introdução
A crescente utilização da rede mundial de computadores, conforme mostrado no gráfico 1 [1], faz
aumentar o interesse das corporações pelas potencialidades proporcionadas por esse meio de
comunicação. Contudo, ao utilizarem tecnologias web, as instituições acabam deparando-se com novas
questões relacionadas ao desempenho de seus sistemas. Senão pelo fato de uma degradação no tempo
de resposta poder gerar prejuízos em decorrência da diminuição do número de negócios e potencial
1
perda de clientes para empresas com plataformas mais velozes, pela simples possibilidade de eventos
dessa natureza poderem ser associados à imagem da instituição.
GRÁFICO 1 - Estações ligadas à Internet
Além disso, essa tecnologia tem sido utilizada também na implementação de soluções internas.
Nesses casos, a portabilidade dos sistemas, que passam a necessitar apenas de um navegador
(browser) instalado nas estações clientes, torna-se um dos principais atrativos para a adoção desse tipo
de solução. Dessa forma, qualquer tipo de instabilidade, passa também a comprometer a própria
produtividade interna da instituição.
Por isso, muitos são os esforços direcionados para a otimização de desempenho em sistemas web.
Em um desses, representado pela elaboração de um trabalho de mestrado ainda em desenvolvimento,
ficou evidente a necessidade de se conhecer alguns detalhes comportamentais específicos do ambiente a
ser trabalhado. Sem esse conhecimento, qualquer proposta poderia enveredar por soluções complexas,
caras e, em certos casos, com resultados abaixo das expectativas. Surgiu daí um problema: como
evidenciar, de maneira precisa e eficiente, as características comportamentais relativas aos indicadores
de desempenho e à carga de trabalho de ambientes computacionais complexos e voláteis, como os
disponibilizados através da Internet (Web), no intuito de otimizar o seu desempenho?
Nesse sentido, o presente artigo busca apresentar um estudo de caso real em que, através da
utilização de técnicas de monitoramento, buscou-se acompanhar a evolução de indicadores de
desempenho e caracterizar a carga de trabalho dos sistemas web de uma instituição de ensino. Os
resultados obtidos, ao exporem a demanda computacional requerida, trouxeram uma série de benefícios
diretos, como a possibilidade de atuação sobre parâmetros arquiteturais a fim de adequar o sistema para
o atendimento a eventos futuros, uma vez que disponibilizaram dados históricos de grande relevância.
Além disso, ao associar-se esse conhecimento ao constante acompanhamento de indicadores de
desempenho, alguns outros resultados preliminares relacionados à otimização de desempenho também
foram alcançados.
Para tanto, a seção 2 busca elucidar alguns aspectos fundamentais de sistemas computacionais web.
A seção 3 aborda os conceitos envolvidos com medição de desempenho descrevendo rapidamente
benchmarks, monitoramento e carga de trabalho. Na seção 4, apresenta-se uma proposta de solução
para o problema descrito e são discutidos os trabalhos correlatos. Já na seção 5, é apresentado o
ambiente real do estudo de caso. Os resultados obtidos são apresentados na seção 6 que é seguida das
conclusões, trabalhos futuros, agradecimentos e referências bibliográficas.
2
2. Sistemas Computacionais Web
Atualmente, a maioria dos sistemas web trabalha com geração dinâmica de páginas. Um sistema que
funcione dessa forma é composto por vários componentes: navegador (browser), servidor web, servidor
de banco de dados (SGBD), servidor de imagens, servidor de cache e elementos ativos de rede
(switches, hubs, cabeamento). Todos eles podendo, de alguma maneira, influenciar no desempenho geral
do sistema.
Esse tipo de implementação mostra-se, atualmente, bastante adequada para Intranets e para o
comércio eletrônico da Internet, onde a natureza da informação muda constantemente e a necessita de
atualizações imediatas e automáticas, normalmente executada por acesso a grandes bancos de dados, é
cada vez maior. Por outro lado, tais páginas exercem grande influência (possíveis degradações) no
desempenho do servidor web [2] de acordo com a quantidade de dados recuperados do SGBD para sua
geração.
É importante também entender que, solicitar uma página pode gerar uma ou mais requisições http,
dependendo do número de documentos envolvidos. Além do corpo html, normalmente existem vários
botões, gráficos, imagens, ícones e, cada um desses componentes, gera uma requisição que pode ser
registrada no arquivo de log de acessos do servidor web. Nesse registro, encontra-se um código de
resposta que indica se a solicitação foi bem sucedida ou não. As bem sucedidas são chamadas de hit.
Segundo Killelea [3], um site com baixo volume de acessos gera entre mil e dez mil hits por dia,
enquanto que um site médio atinge de dez mil a um milhão de hits por dia. Um site com mais de um
milhão de hits ao dia é considerado um site com alto volume de acesso.
3. Medição
Medição é uma técnica de avaliação de desempenho que utiliza normalmente ferramentas como
benchmarks e monitoramento.
3.1. Benchmarks
Benckmarcks são programas ou parte de programas comerciais ou científicos que tentam representar
uma carga de trabalho real que será submetida ao sistema a ser avaliado. No entanto, o termo é, por
vezes, utilizado como sinônimo de carga de trabalho.
Existem órgãos especializados no estudo e desenvolvimento desse tipo de aplicação, tais como: TPC
(Transaction Processing Concil) [4], que se especializou em benchmarks para sistemas baseados em
transações;
e
SPEC
(Systems
Performance
Evaluation
Cooperative)
[5],
desenvolvimento de diversos benchmarks para aplicações científicas e comerciais.
3
responsável
pelo
3.2. Monitoramento
O monitoramento é uma forma de medição que consiste em observar o desempenho de um sistema
através da utilização de diferentes instrumentos os quais observam o comportamento do sistema, coletam
estatísticas, analisam os dados, e mostram resultados. Alguns chegam até a identificar áreas de
problemas e a sugerir soluções.
Pode-se utilizar um monitor para medir a utilização de recursos. Com isso, torna-se possível encontrar
pontos críticos de degradação de desempenho (gargalos) e, a partir daí, ajustar os parâmetros do
sistema. O monitoramento serve também para caracterizar a carga de trabalho, sendo os resultados úteis
no planejamento de capacidade.
Dois dos principais instrumentos de monitoramento são os arquivos de registro de utilização (logs) e
ferramentas de monitoramento de desempenho embutidas nos sistemas operacionais.
3.3. Carga de Trabalho
A caracterização da carga de trabalho de servidores web permite um melhor entendimento dos
padrões de utilização de um sistema. Essa carga de trabalho é determinada tanto pelo fluxo de
requisições enviadas pelos clientes quanto pelas respostas do(s) servidor(es) para estas requisições.
Tal caracterização envolve a determinação e descrição das características fundamentais da demanda.
Para isso, é necessária a coleta de dados relevantes durante um período de tempo significativo, sendo os
mesmos armazenados para posterior análise. Dentre outras informações, devem estar presentes: horário
de chegada da requisição, rede de origem, tipo de requisição, demanda de recursos e tamanho da
resposta.
Com estes dados relativos a um período de tempo representativo do funcionamento do sistema,
através de técnicas estatísticas, são obtidas informações importantes sobre a carga de trabalho do
servidor web possibilitando caracterizações tais como taxa de requisições, distribuição dos tamanhos dos
objetos do servidor, tamanho médio dos documentos requisitados, concentração das referências, tipos de
objetos (HTML, imagem, etc), taxa de requisições bem sucedidas dentre outras.
4. Proposta e Trabalhos Correlatos
Visando a otimização do desempenho em sistemas web, propõe-se um esquema de constante
monitoramento dos servidores envolvidos no processamento de requisições. Acredita-se que, com esse
tipo de abordagem, alguns benefícios diretos podem ser obtidos tornando mais eficiente a administração
do ambiente.
4
Para tanto, não basta monitorar o desempenho computacional. Dados sobre a utilização dos sistemas,
tais como erros ocorridos, origem das requisições e tráfego gerado devem também ser observados. Temse, dessa forma, dois conjuntos de métricas: um referente ao desempenho e outro à carga de trabalho.
Como já mencionado, o primeiro pode ser obtido diretamente de ferramentas de monitoramento
embutidas no sistema operacional. Já o segundo é fornecido pelos servidores através dos registros de
utilização (logs).
Ao coletar e armazenar esse tipo de informação, algumas possibilidades passam a existir. Em primeiro
lugar, torna-se viável o acompanhamento dos indicadores de desempenho, sejam eles imediatos ou
históricos. Além disso, passa a ser possível caracterizar, de maneira bastante segura, a carga de trabalho
suportada.
Informações provenientes da análise dos indicadores de desempenho podem, por si só, trazer uma
série de benefícios ao administrador do sistema. Torna-se possível, por exemplo, a identificação de
pontos críticos de degradação de desempenho (gargalos) permitindo a rápida e correta atuação sobre o
problema. Além disso, ao disponibilizar-se uma linha histórica das métricas envolvidas, acaba gerando-se
um conhecimento sobre o comportamento normal do sistema. Assim, ainda que não haja um gargalo,
pode-se atuar sobre variações incomuns observadas de modo a antecipar um possível problema futuro.
Por outro lado, a caracterização da carga de trabalho, ao evidenciar o comportamento temporal do
ambiente, permite a atuação sobre parâmetros arquiteturais no intuito de melhor adequá-los à uma
demanda específica. Máquinas podem, por exemplo, ser adicionadas ao ambiente ou mesmo
remanejadas para o atendimento de um sistema específico. Pode-se ainda, com base nesse
conhecimento, projetar-se um ambiente computacional mais adequado, já que a escolha da arquitetura
passa a ser embasada em dados concretos de utilização. A decisão de utilizar-se um aglomerado
(cluster) ou um servidor multi-processado de grande porte passa a ser embasada em dados concretos.
Por fim, a caracterização passa a permitir um melhor planejamento de manutenções programadas.
Além de tudo isso, esse tipo de abordagem pode ser financeiramente muito atrativa, já que minimiza a
possibilidade de investimentos inadequados em equipamentos ao mesmo tempo em que diminui o
esforço necessário para a detecção de problemas.
Propostas de monitoramento para a coleta de indicadores de desempenho são encontradas no meio
científico com uma certa facilidade. Anderson [6] apresenta uma solução bastante interessante
denominada Digital Continuous Profiling Infrastructure que possibilita a coleta de dados em ambientes já
em produção. Proposta similar foi apresentada por Zhang [7].
Trabalhos enfocando a caracterização de carga de trabalho também aparecem já há algum tempo.
Jain [8], por exemplo, apresenta a teoria relacionada a esse tipo de tratamento. Além dele, apesar de
enfocar outros objetivos, Almeida [9] também discuti as características envolvidas com esse processo.
Apesar disso, não foram encontrados trabalhos que utilizassem os benefícios trazidos por essas duas
abordagens no intuito de possibilitar o ajuste de parâmetros arquiteturais e conseqüentemente otimizar o
desempenho de sistemas web.
5
Dessa forma, o presente trabalho busca apresentar e analisar os benefícios alcançados por esse tipo
de abordagem quando se faz necessária a otimização de desempenho em sistemas computacionais
disponibilizados através da web. Acredita-se, contudo, que implementações similares podem ser
expandidas e utilizadas em outros ambientes. O que deve ser abordado em trabalhos futuros.
5. Ambiente Real do Estudo de Caso
O estudo de caso a ser apresentado refere-se ao ambiente web de uma grande instituição de ensino
com cerca de 50 mil usuários diretos (alunos, professores e funcionários) e que presta diversos serviços
via internet tais como: inscrição e divulgação de resultados de concursos e vestibulares, acesso às
informações acadêmicas, prestação de serviços e informações financeiras, divulgação de estágios e
oportunidades de trabalhos, informações sobre seus cursos e respectivos currículos, apropriação de
horas de seus funcionários e etc.
Vale dizer que o número de usuários do sistema pode ser muito maior que o de usuários diretos de
acordo com os serviços disponibilizados à comunidade. Por exemplo, durante inscrição e divulgação de
resultados de concursos ou vestibulares.
5.1. Infra-estrutura
Dados os objetivos específicos desse trabalho, tornou-se
possível focar a interação entre os
servidores que compõem o sistema sem considerar a influência dos componentes do lado cliente.
Portanto, trabalhou-se com um sistema web simplificado similar ao esquema mostrado na figura 1.
FIGURA 1 – Servidores de Aplicações Web e SGBD
A infra-estrutura final utilizada no estudo foi composta de: dois servidores IBM Netfinity 5100 com dois
processadores Pentium III de 650 MHz e 2 GB de memória RAM para servidores de aplicações web; um
IBM Netfinity 8500R com oito processadores Pentium III de 550 Mhz com 4 GB de memória RAM para
servidor de banco de dados.
Todos com sistema operacional Windows 2000 Server, sendo o sistema gerenciador de banco de
dados utilizado o Microsoft SQL Server 2000. Já o software servidor de aplicações utilizado foi o
Silverstream Application Server da própria Silverstream Inc® que foi adquirida em 2003 e atualmente
pertence a Novell®. Esse software é um servidor web com APIs para geração de páginas dinâmicas
através de JSPs, servlets e HTML. Uma característica importante do software é que ele não armazena
6
páginas como arquivos em disco. Todo documento disponibilizado é gerado dinamicamente a partir de
requisições SQL enviadas a um banco de dados relacional. Portanto, para que o sistema funcione, é
necessário que se tenha um SGBD para armazenar os documentos que serão disponibilizados para web.
Os dois servidores de aplicações e o SGBD foram interligados por uma rede 100Mbps sendo os dois
primeiros completamente dedicados aos sistemas web e o
de banco de dados compartilhado por
aplicações executando outros tipos de sistemas.
O cenário foi monitorado de novembro de 2001 a novembro de 2003, realizando-se uma coleta
continua de dados de acesso e de contadores de desempenho. Estes, atualmente, compõem uma base
com mais de cem milhões de registros.
6. Resultados
A abordagem utilizada possibilitou uma precisa caracterização da carga de trabalho do ambiente web.
Assim, inúmeras informações relevantes puderam ser obtidas tornando a administração do sistema muito
mais eficiente, já que as ações corretivas e preventivas, a partir daí, passaram a ser tomadas com um
embasamento histórico bastante efetivo.
Para isso, conforme dito anteriormente, a coleta de informações de log e contadores de desempenho
foi imprescindível. Essa coleta seguiu a abordagem descrita a seguir.
6.1. Arquivo de Log de Acesso
Foram examinadas as requisições dos clientes, concluídas, registradas no arquivo de log dos
servidores de aplicações. Cada requisição http gerava uma linha no log contendo as seguintes
informações:
-
LIPAddress: O endereço IP do sistema que realizou a requisição (cliente, firewall intermediário ou
servidor proxy);
-
Lhost: O servidor do aglomerado que recebeu a requisição;
-
Luser: Usuário que requisitou a página (na maioria das vezes: anônimo);
-
Ldate: Data e hora da chegada da requisição;
-
Lrequest: O tipo de requisição;
-
LURL: A URL alvo da requisição;
-
LreplyStatus: O status HTTP após o processamento da requisição;
-
Lbytes: O número de bytes retornados.
Como exemplo de linhas inseridas nesse arquivo de log, tem-se:
198.81.8.2 - SYS\\Anonymous [02/Nov/2003:12:10:32 +3]
"GET http://www1/index.html HTTP/1.0" 200 12630
200.11.1.7 - SYS\\Anonymous [02/Nov/2003:12:10:35 +3]
7
"GET http://www2/index.html HTTP/1.0" 200 12630
TABELA 1 - Linhas inseridas no log.
6.2. Contadores de Desempenho
Foram selecionados os contadores mais significativos para cada objeto (disco, memória, processador,
processo e sistema operacional). A escolha dos contadores foi modificada ao longo do processo de
monitoramento de acordo com as necessidades identificadas. Já a faixa de valores aceitáveis para cada
um desses contadores baseou-se nas especificações do fabricante do Sistema Operacional e do SGBD
que, no caso, foi a Microsoft [10]. A linha de base identificada nesse estudo de caso resultou de uma
análise contínua dos dados coletados, avaliações empíricas do desempenho e depoimentos dos usuários
do sistema. Essa linha de base difere para cada sistema, pois depende do hardware, software e
configurações que podem ser muito diferentes.
Os contadores com suas faixas de valores aceitáveis estão descritos a seguir:
Objet
Contador
Observação
o
MBytes
Valores abaixo de 5 MB
disponíveis
indicam falta de memória
Memória
física
para
executar
os
processos.
Páginas
Se estiver constantemente
por segundo maior que zero o SO estará
utilizando
arquivo
de
paginação.
% tempo
Deve sempre estar acima de
ocioso
10%.
Disco
Compriment Deve ser sempre menor que
o médio da
o dobro da quantidade de
fila de disco
acessos
possíveis
simultâneos
(dado
pela
configuração de discos -
Processo
RAID).
Falhas de
Números altos para este
Página por
contador
segundo
paginação excessiva.
indicam
uma
8
Área de
Valores abaixo de 5 MB
Trabalho
indicam falta de memória
sador
Proces-
para o processo.
% tempo
Deve estar sempre abaixo
de
de 90%.
processador
Alternâncias Não deve alcançar 8000,
de contexto
sobretudo
quando
o
por segundo percentual de utilização de
processador
ficar
Sistema
constantemente acima de
90%.
Compriment Se estiver constantemente
o
acima de 2, deve-se diminuir
da fila
a
do
eficiência de processamento
carga,
aumentar
a
processador ou adicionar mais poder de
Compriment Se superior a 2, indica que
rede
Interface de
processamento ao servidor.
o
se
está
da fila
atraso.
produzindo
um
de saída
TABELA 2 - Contadores de desempenho
6.3. Otimizações Realizadas
O primeiro benefício concreto alcançado foi o conhecimento temporal do acesso ao sistema. Os
gráficos 2, 3 e 4 exemplificam o conhecimento gerado por esse tipo de informação.
9
22:00
20:00
18:00
16:00
14:00
12:00
10:00
08:00
06:00
04:00
02:00
700000
600000
500000
400000
300000
200000
100000
0
00:00
Requisições
Requisições de Páginas por Horário
Horário
GRÁFICO 2 - Requisição de páginas por horário
Acessos por Dia da Semana
2500000
Acessos
2000000
SEG
TER
QUA
QUI
SEX
1500000
1000000
DOM
SAB
500000
0
Dia
Dia da Semana
GRÁFICO 3 - Requisição de páginas por dia da semana
Acessos por Mês
Acessos
8000000
6000000
4000000
2000000
0
01
2002
02
03
04
05
06
07
Mês
GRÁFICO 4 - Requisição de páginas por meses do ano
Com isso, decisões relativas a manutenções passaram a ser tomadas levando-se em consideração
tais informações. Isso aumentou significativamente a disponibilidade do sistema em horários críticos de
10
utilização. O que, conseqüentemente, elevou a satisfação dos usuários diminuindo o número de
reclamações causadas por manutenções programadas.
Além disso, ao conhecer a elevação de demanda ocorrida em determinados períodos do ano, passouse a realizar o aluguel de máquinas que, acrescentadas ao aglomerado (cluster), aumentavam o poder de
respostas dos sistemas envolvidos. Ao adotar-se essa solução, foi possível manter inalterado o
desempenho do sistema mesmo diante de um enorme aumento na demanda computacional. Essa
solução mostrou-se bastante adequada, já que dispensou a compra de servidores de maior capacidade
que, por certo, ficariam ociosos na maior parte do ano.
Outro importante conhecimento gerado foi a distribuição de acesso por sistema, demonstrado no
gráfico 5.
400000
300000
200000
100000
21:00
18:00
15:00
12:00
09:00
06:00
03:00
0
00:00
Requisições
Requisições de Páginas por Sistema Horário
Horário
Sistema1
Sistema2
Outros
Sistema4
GRÁFICO 5 - Requisição de páginas por sistema
O maior benefício trazido por essa informação foi a possibilidade de distribuição dos sistemas por
máquinas específicas. Com isso, foi possível minimizar a influência provocada por um sistema que
estivesse em período de alta utilização sobre aqueles que mantinham um comportamento inalterado
nesse mesmo intervalo de tempo. Ou seja, a divulgação do resultado de um vestibular passou a não mais
ter qualquer influência sobre o lançamento de horas dos funcionários da instituição de ensino. Isso foi
conseguido após o desenvolvimento de uma solução interna de balanceamento de carga baseada no
sistema a ser acessado.
Seguindo com os resultados alcançados, pode-se citar a mudança de infra-estrutura de rede
provocada pela descoberta de que quase 50% das requisições, no período de divulgação de notas, partia
da rede de um dos campi da instituição. Com essa informação, foi possível aumentar o link de
comunicação com o Centro de Processamento de Dados provocando um alívio do tráfego e conseqüente
melhoria no acesso ao sistema acadêmico.
Também através da caracterização obtida, foi possível direcionar esforços da equipe de
desenvolvimento no sentido de melhorar o desempenho geral do sistema. Observando-se a tabela 3,
pode-se verificar a relação do tamanho médio dos documentos mais acessados.
11
Tamanho
Documento
Médio
(Bytes)
Nº de
Acessos
PgAln_OfertaEstagios.html
6525
1416366
PgAlOfertaEstagios.html
4498
934496
PgAlLogin.html
3079
469593
PgAln_Apresentacao.html
2414
389658
Login.html
737
275046
ml
7601
252638
PgInicialCanal2.html
20030
235926
PgLimpaRefresh.html
390
212915
DetalhesSGA.css
125
209541
Mng_DefCurricular01.gif
636
206119
Mng_NotasFreq01.gif
608
199857
12360
192900
Mng_SolicServ01.gif
715
192810
PgInsObjeto.html
4650
192530
PgAln_OfertaEstDetalhe.ht
PgAln_NotaFrequencia.html
TABELA 3 - Tamanho médio dos documentos mais acessados
De posse dessa informação, equipes foram constantemente formadas no intuito de otimizarem as
páginas que apresentavam maior volume de acesso ou maior tamanho médio. Não foram poucos os
casos em que tais equipes diagnosticaram falhas de programação e mesmo falhas (bugs) do servidor de
aplicação onde, em certos casos, consultas gigantescas eram desnecessariamente submetidas ao
servidor de Banco de Dados.
Além dessas ações tomadas com base na caracterização da carga de trabalho, alguns outros
resultados preliminares relativos à otimização de desempenho puderam ser alcançados. Um dos mais
importantes foi a descoberta e ajuste em uma falha de configuração de memória do servidor de banco de
dados.
Apesar desse servidor possuir 4,0GB de memória física, observou-se que apenas 1,2 GB era, em
média, utilizado. Ainda assim, com memória física disponível, o sistema apresentava paginação
excessiva. Com base nessa observação e em estudos realizados após esse levantamento, descobriu-se
a necessidade de ajustar um parâmetro do sistema operacional para que o mesmo permitisse uma maior
utilização de memória por parte do SGBD. Incluiu-se então o parâmetro /3gb ao arquivo de configuração
do Windows 2000 (boot.ini).
Após a configuração, o sistema operacional liberou três gigabytes de memória RAM para o banco que
passou a utilizá-los diminuindo sensivelmente a paginação e falhas de página. Um acompanhamento
12
semanal do monitoramento realizado antes e depois dessa alteração pode ser observado nos gráficos a
seguir:
MB Disponíveis
2000
Valor
1500
1000
500
0
SEG
TER
QUA
QUI
SEX
Dia da Semana
Antes
Depois
GRÁFICO 6 – MB Disponíveis antes e depois das
alterações no boot.ini
Pode-se observar que a quantidade de memória livre, que era em média 1774 MB, passou para 893
MB. Isso indica que o servidor trabalhava, antes da alteração, com uma demanda reprimida de memória o
que, por certo, degradava o tempo de resposta dos sistemas atendidos.
Páginas por Segundo
100
Valor
80
60
40
20
0
SEG
TER
QUA
QUI
SEX
Dia da Semana
Antes
Depois
GRÁFICO 7 – Páginas por Segundo antes e depois
das alterações no boot.ini
Já o contador páginas/seg, o qual não se enquadrava nas recomendações destacadas na tabela 2,
teve sua média diminuída de 50,10 para 0,45. Sabendo-se que o acesso a disco eleva muito o tempo de
processamento de uma aplicação, pode-se perceber que valores médios, em certos momentos, próximos
a 80, ocasionavam sérios problemas de desempenho.
13
Falhas de Páginas / Segundo
200
Valor
150
100
50
0
SEG
TER
QUA
QUI
SEX
Dia da Semana
Antes
Depois
GRÁFICO 8 – Falhas de Páginas por Segundo
antes e depois das alterações no boot.ini
Outro indicativo de excesso de paginação era indicado pelo contador de falhas de páginas por
segundo. Também nesse caso, a melhora foi muito grande, saindo-se de uma média de 117,07 e
chegando em 7,64.
Sabendo-se que as semanas de monitoramento não apresentaram qualquer modificação no nível de
acesso que pudesse explicar a alta variação nos níveis dos contadores destacados, concluiu-se que a
variação observada foi quase que exclusivamente provocada pela alteração (ajuste) de configuração
descrita.
Assim, com uma simples alteração de configuração, foi possível provocar uma significativa melhora
geral no desempenho do servidor, o que pôde ser confirmado pelo retorno dado pelos usuários e
observação direta do comportamento dos sistemas. Contudo, esse resultado seria muito difícil de ser
alcançado se não houvesse um ambiente de monitoramento como o descrito. Nesse caso, muitas ações
ineficazes poderiam ser tomadas antes de se descobrir o verdadeiro motivo ou causa do problema. Ações
tão desastrosas e onerosas quanto a compra de novos equipamentos ou mesmo a substituição de
sistemas.
7. Conclusões e Trabalhos Futuros
Com base no estudo de caso apresentado, é possível perceber que muitos foram os benefícios
trazidos pela implementação de um esquema de monitoramento focado em indicadores de desempenho e
caracterização da carga de trabalho. Com essa abordagem, consegui-se aumentar a disponibilidade
geral dos sistemas, implementar uma arquitetura adequada para o atendimento sazonalmente variável da
demanda, desenvolver mecanismos de distribuição de carga, propor e executar modificações estruturais
adequadas, descobrir problemas relacionados a bugs apresentados pelos aplicativos utilizados, além de
permitir-se ações diretas de otimização como a descrita na alteração do arquivo de configuração do
Sistema Operacional.
14
Contudo, se muitos foram os benefícios, deve-se destacar todo o tempo e esforço gastos na
elaboração e implementação de um esquema como esse. Muitas foram as dificuldades encontradas na
operacionalização da coleta de indicadores e mesmo na estrutura de armazenamento dessas
informações. Por isso, trabalhos futuros serão elaborados no sentido de propor um mecanismo de coleta,
armazenamento e tratamento ainda mais adequado. Uma estrutura de banco de dados de processamento
analítico on-line (OLAP) pode ser proposta facilitando a consulta aos dados históricos e possibilitando até
a utilização de mecanismos de Data Mining para a descoberta de padrões e tendências dentro dos dados
armazenados. Além disso, a abordagem pode ser expandida para o tratamento de outras plataformas que
não apenas a web, aumentando as possibilidades relacionadas e esse tipo de solução.
Tendo-se em vista tudo isso, pode-se dizer que a proposta apresentada foi capaz de evidenciar com
exatidão e de maneira eficiente as características comportamentais relativas aos indicadores de
desempenho e à carga de trabalho do ambiente web em questão. Principalmente se for levado em
consideração que muitos outros resultados ainda poderão ser obtidos com base em análise que estão
ainda em andamento. Conclui-se então que a otimização de desempenho de sistemas web pode ser
alcançada pela implementação desse tipo de solução.
8. Agradecimentos
Agradecimentos ao DataPuc Processamento de Dados, por disponibilizar a infra-estrutura necessária à
realização do estudo de caso e aos colegas dessa instituição e do Programa de Pós-Graduação em
Engenharia Elétrica pela colaboração e incentivo demonstrados. Agradecimentos também aos familiares
pelo apoio sempre irrestrito.
9. Referências
[1] Internet Systems Consortium. Disponível em <http://www.isc.org/> Acesso em 12 de jun. 2004.
[2] M.A. Mendes, V.A.F. ALMEIDA, ”Comparação e Análise de Requisições Dinâmicas em Servidores WWW”, XXV
Seminário Integrado de Software e Hardware, 1998, Belo Horizonte.
[3] P. Killelea, Web Performance Tuning, 2nd Edition, O´Reilly & Associates, USA, 2002.
[4] Transaction Processing Concil. Disponível em <www.tpc.org> Acesso em 12 de jun. 2004.
[5] Systems Performance Evaluation Cooperative. Disponível em <www.spec.org> Acesso em 12 de jun. de 2004.
[6] J.M. Anderson, L.M. Berc, J. Dean, S. Ghemawat, M.R. Henzinger, S.A. Leung, R.L. Sites, M.T. Vandervoorde,
C.A. Waldspurger, W.E. Weihl, “Continuous Profiling: Where Have All the Cycles Gone?”, ACM Transactions on
Computer Systems, Vol 15, No. 4, Novembro 1997.
[7] X. Zhang, Z. Wang, N. Gloy, J.B. Chen, M.D. Smith, “Operating System Support for Automated Proffiling and
th
Optimization”, 16 ACM Symposium on Operating Systems Principles, New York, 1997.
[8] R. Jain, The Art of Computer Systems Performance Analysis, Wiley, New York, 1991.
[9] V.A.F. Almeida, D.A. Menascé, Capacity Planning for Web Performance, New Jersey, Prentice Hall Inc., 1998.
[10] Aministering a Microsoft SQL Server 2000 Database, Microsoft Training and Certification, 2000.
15
16