Avaliação de Desempenho

Roteiro do curso (a priori)

cont…
3. Aferição de Desempenho
3.1 Introdução
3.2 Protótipos
3.3 Coleta de Dados (Monitores)
3.4 Benchmarks

1
 Técnicas de Desempenho

Técnicas de AD

Aferição Simulação Modelagem

Benchmarks
Redes de Filas
Protótipos Redes de Petri

Coleta de Dados Statecharts

2
 Avaliação de Desempenho
Roteiro do curso (a priori) cont…

3. Aferição de Desempenho
3.1 Introdução

3
 Técnicas de AD: Aferição
Introdução

• Para responder a questões quantitativas sobre o

comportamento de computadores e redes, é
preciso medir (aferir).
• Aferir um sistema é o processo de observar a
operação deste ao longo de um período de
tempo (janela), armazenando valores referentes
aquelas variáveis quantitativas relevantes à sua
compreensão.

4
 Passos para o processo de
Aferição
Aplicações

Soft. Servidor

Sist. Operacioal

Hardware

Especificar Análise e Tratamento

pontos de Especificar Técnicas de de Dados
referência Medidas Instrumentação (estimar parâmetros)

Instrumentos de Medição
5
 Aferição
Especificar medidas

• A principal fonte de informação constitui-se do

conjunto de medidas de desempenho
coletadas nos próprios sistemas reais sob
estudo.

• Na ausência destes, dados de sistemas

semelhantes ou informações de vendedores e
fabricantes devem ser adaptadas.

• O maior problema é a falta de coincidência

entre o que é coletado e o que é necessário
aos modelos!
6
 Tipos de Aferição

1. Protótipos

– Simplificação de um sistema computacional;

– Possuir a mesma funcionalidade do sistema real;
– Custo relativamente elevado;
– Dificuldade para determinar quais características
são essenciais.

Conclusão:
Pouco utilizado em ambientes de produção.

7
 Tipos de Aferição
2. Coleta de Dados

• Especificar pontos de referência

8
 Tipos de Aferição

2. Coleta de Dados (ou Monitoração)

– Resultados mais precisos;

– A coleta deve ser não intrusiva;
– Realizada através de
• Monitores de Hardware;
• Monitores de Software;
– Pode ser utilizada para validar um determinado
modelo.
– Exp.: Rede de sensores.

9
 Aferição: Coleta de dados
Coleta de dados de sistemas reais, questões:
– Quais são as fontes de informações disponíveis
para a coleta de dados?
– Qual será a “janela de tempo” que irá definir a
sessão de medição? Ou seja, deve ser
identificado o ‘intervalo de tempo’ no qual o
sistema, a carga de trabalho e os índices de
desempenho serão observados.
• A determinação deste intervalo depende da natureza
do negócio e costuma ser definida pela observação
contínua do sistema por períodos que devem
compreender as horas de pico dos dias de pico de um
determinado serviço prestado.
10
 Aferição: Coleta de dados
Coleta de dados de sistemas reais, questões:
– Quais são as ferramentas de monitoração
disponíveis para coletas como: utilização de
recursos ou tempo de resposta?
• Estas ferramentas podem estar disponíveis no S.O.,
podem constituir monitores de rede (sniffers), além de
monitores de Hardware e Software desenvolvidos para
este fim.
– Que técnicas são empregadas para transformar
os dados coletados em números úteis e válidos
para servirem de parâmetros de entrada de
modelos?

11
 Aferição: Monitoração
O que se deve monitorar (terminologia)
• Eventos: qualquer mudança no estado do sistema é
considerado um ”evento”. Exp.: início de pesquisa em disco
rígido, chegada de pacotes em um roteador…
• Trace: um ‘log de eventos’ usualmente incluindo o tempo do
evento, o tipo de evento, etc.
• Overhead: Muitos monitores perturbam indiscriminadamente
o sistema operacional, consumindo recursos de sistema,
CPU, ou disco.
• Domain: Um set de atividades observadas pelo monitor é
considerado seu ‘domínio’. Exp.: “logs de accounting”
registram informações acerca de tempo de CPU, número de
discos, nº de caracteres transferidos através de terminais,
discos, rede. Isto se constitui no domínio do “log de
accounting”. 12
 Monitores - Classificação
Resumindo a classificação:
∙ Nível de Implementação
∙ Monitor de Software (MS): Implementados por software.
∙ Monitor de Hardware (MH): Equipamento separado.

∙ Mecanismo de Ativação:
∙ Orientado a Evento: Ativado quando ocorre um evento.
∙ Orientado ao Tempo (amostragem): Ativado a cada intervalo de
tempo.

∙ Apresentação dos Resultados

∙ On-line: Apresenta os resultados enquanto monitora.
∙ Batch: Guarda os resultados num log para apresentação posterior.

∙ Pode ser classificado pelas três características juntas.

∙ Exemplo: um monitor de software, orientado ao tempo e on-line
13
 Monitores de Hardware
• Monitores de Hardware (MH) consistem em
equipamentos separados que são conectados ao
sistema monitorado.
• Geralmente possuem baixo overhead, não consumindo
recursos do sistema monitorado.
• Os MH atuais são programáveis, possuem seu próprio
processador, memória e dispositivos de I/O.
Não são recomendáveis para a obtenção de dados
específicos, relacionados com as aplicações.

14
 Monitores de Software (MS)
• São usados para monitorar sistemas operacionais e
aplicações.

– Exemplo: tempo de execução de procedimentos em

aplicações, redes e bancos de dados.

• Geralmente possuem (características):

– baixa taxa de entrada (freqüência máxima de eventos que
podem ser observados);
– baixa resolução (período mínimo entre observações);
– alto overhead (comparado com o MH);
– Flexibilidade e facilidade de configurações (adaptações
quanto ao interesse).

15
 Componentes Principais
• Monitoração de Software
– Coletas nos clientes e no servidor

– Instrumentação de código

– Ferramentas de coleta
• Windows: Performance Monitor
• Unix: iostat, vmstat
• Linux: /proc

16
 Programas de Análise
• Programas de monitoração e análise, são ferramentas de
software designados para coletar informações sobre a execução
individual de programas.
• Monitores de transações ou os próprios monitores do sistema
operacional, monitoram apenas o uso geral dos recursos. Os
processos internos não são monitorados.
• Programas analisadores, fornecem informações internas:
– contagem de transações;
– tempo médio de resposta;
– tempo médio de CPU/transação;
– número médio de I/Os por transação;
– mix de transações.

17
 LOGS de Contabilização
• Os arquivos de Log contém informação sobre os serviços
requisitados, as respostas providas e a origem das
requisições.
– O NT Performance Monitor, por exemplo, disponibiliza
dados de desempenho num arquivo para serem utilizados
por outros aplicativos. O analista pode especificar que
dados e que intervalos devem ser monitorados.

• Os servidores Web, mantém informações sobre suas

atividades.
– Os logs de servidor Web são separados em tipos, tais
como: access, agent e error.

18
 LOGS de Contabilização
• O log access, é usado para analisar o comportamento do servidor
e contém linhas com as seguintes informações.
– Host: nome do host cliente ou endereço IP;
– Login name or authorization: contém a identidade e autorização
(código de acesso) a partes protegidas do site;
– Date, time and zone: data e momento no qual uma requisição é
completada;
– Request: contém o nome do arquivo requisitado e a operação
ou método utilizado (ex. “GET/HTTP/1.0”);
– Status: demonstra o estado da resposta de um servidor. Por
exemplo, requisição feita com sucesso, uma requisição sem a
devida autorização ou ainda, arquivo não existente;
– File size: indica o número de bytes transferidos por conta de
uma requisição.
19
 LOGS de Contabilização
• Exemplo: A tabela abaixo apresenta um log de acesso a um
Web site coletado durante um curto espaço de tempo. A partir
deste, deseja-se coletar medidas de desempenho, tais como
taxa média de chegadas e tamanho médio dos documentos
requeridos.

20
 LOGS de Contabilização
• Na primeira linha, por exemplo, o log indica que a requisição
originou-se de perf.xyz.com, as 13:41:41 (–0400: zona leste
de tempo) no dia 24/Jan/19xx. O documento requisitado foi
uma página índice. O código 200 indica que a resposta do
servidor foi um sucesso. O código 400, por sua vez, indica
requisição mal sucedida devido a erro no cliente. O tamanho
do arquivo transferido foi de 3185 bytes.
• Apesar de ajudarem na caracterização da carga de trabalho,
os logs não apresentam informações diretas sobre
parâmetros necessários aos modelos de desempenho.
• Por exemplo, não existe informação do tempo necessário
para a transferência de um documento.

21
 LOGS de Contabilização
• Algumas informações podem ser deduzidas.
– O intervalo de tempo de medição T [13:48:29–13:41:41] = 408 seg..
– O número de requisições ocorridas neste intervalo foi 11. Assim
pode-se definir a taxa de chegadas como: 11/408 requisições/seg..
– O tamanho médio dos arquivos transferidos foi de 188.117/10 =
18.811,7 bytes.
– O menor arquivo foi de 441 bytes.
– O maior 98.995 bytes.
• Uma vez que as diferenças são muito grandes, é recomendado
subdividir o tamanho em classes.
– Pode-se, por exemplo, criar duas classes: pequenos, com
tamanhos até 4000 bytes e, grandes. Assim, teremos na classe
pequenos, sete requisições com tamanho médio de 2.330,9 bytes e
a classe grandes, com três requisições de tamanho médio igual a
57.267 bytes. 22
 Aferição
• Avaliação de sistemas reais
– Nível máximo de detalhamento: captura aspectos
bastante específicos do funcionamento do sistema!
• Quais os principais componentes do tempo de resposta de um
servidor Web?
• Qual o impacto da implementação de segurança a nível de análise
de pacote (em um firewall) no desempenho de uma rede local?

– Alta complexidade, muitas variáveis: alto custo

• Difícil avaliar impacto de valores isolados: falta de controle!

– Alta precisão se e somente se realizada corretamente

23
 Componentes Principais: Resumo
• Sistema alvo

• Infra-estrutura computacional e de rede

– Experimentação em ambiente controlado

• Geradores de carga / tráfego: benchmarks

– Ex: TPC : bancos de dados, sistemas de transação
Webstone, Surge, httperf : servidores Web
WPB, polygraph: servidores proxy
– Modelo de geração de cargas tem que ser realista
– Carga sintética tem que ser realista: caracterização
24
Caracterização de Cargas: Resumo
• Resultados principais
– Entendimento mais claro do comportamento
típico dos usuários
• Implicações projeto de sistemas mais eficientes e
escaláveis

– Prover dados para a geração de cargas sintéticas

realistas
• Passo importante para análise de desempenho
– Entrada para modelagem, simulação e
experimentação
25
 Exemplos de caso:

LOGS de Contabilização

26
Otimização de uma Ferramenta baseada na Análise de Logs
para Classificação, Caracterização e Correlação de Eventos.
Fabiane Cristine Dillenburg, Luciano Paschoal Gaspary
(Programa Interdisciplinar de Pós-Graduação em Computação Aplicada, UNISINOS).

O maior contato das organizações com a Internet evidenciou ainda mais a

necessidade destas protegerem seu maior patrimônio – suas informações –
de ataques. Uma das medidas de proteção mais adotadas é o firewall,
caracterizado como uma barreira de segurança entre duas redes; sua
principal função é bloquear todo o tráfego não autorizado oriundo de uma
rede a outra. Utilizar um firewall como mecanismo de segurança de borda
permite centralizar, em apenas uma máquina, todo tráfego que provém da
Internet com destino à rede privada e vice-versa. Assim, todo e qualquer
pacote que entra ou sai é inspecionado, podendo ser aceito ou rejeitado,
conforme as regras de segurança estabelecidas. Nesse contexto, os firewalls
armazenam todas as tentativas de conexão em um arquivo denominado log.
Dependendo do tamanho da rede e de seu tráfego, o log diário gerado pode
ser maior que 1GB. Para a gerência de segurança este log é rico em
informações, pois permite:
27
Otimização de uma Ferramenta baseada na Análise de Logs
para Classificação, Caracterização e Correlação de Eventos.
(a) mensurar e identificar os acessos à rede privada e à externa;
(b) acompanhar historicamente o crescimento do volume de acessos e as
aplicações utilizadas;
(c) depurar problemas de configuração de regras de filtragem e, sobretudo,
(d) reconhecer seqüências de eventos suspeitas que indiquem estratégias
utilizadas por invasores para tentar obter acesso indevido a estações e
serviços.
No entanto, apesar da importância desses indicadores, o crescimento da
quantidade e da complexidade das informações transitadas diariamente
entre as redes privadas e a Internet torna inviável o controle manual dos
arquivos de log. Algumas ferramentas foram desenvolvidas objetivando
auditar esses logs, mas a maioria não permite relacionar eventos e gerar
visões históricas. Para solucionar esse problema, foi desenvolvida pelo
nosso grupo de pesquisa uma ferramenta que classifica, caracteriza,
armazena históricos, correlaciona e visualiza os eventos do log de forma
amigável. Entretanto, dado o volume considerável de dados manipulados, o
protótipo apresenta limitações quanto ao seu desempenho na exibição da
grande quantidade de informações ao usuário, dificultando sua utilização.
O presente trabalho compreendeu a identificação e a solução de gargalos
existentes na ferramenta. Assim, foram feitas alterações nas estruturas de
dados e na manipulação dessas, permitindo que a ferramenta possa 28 ser
utilizada como apoio ao gerente de segurança.
Tipos de Aferição:
3. Benchmarks

29
30
31
32
33
34
• http://arstechnica.com/cpu/2q99/benchmar
king-2.html
• http://arstechnica.com/cpu/2q99/benchmar
king-3.html
• http://arstechnica.com/cpu/2q99/benchmar
king-4.html
• http://arstechnica.com/cpu/2q99/benchmar
king-5.html

35
36
37
38
39
40
• http://www.top500.org

41
42
43
44
45
46
47
48
49
http://www.spec.org/
50
51
52
53
54
55
56
• http://www.spec.org/osg/cpu/CPU2004/se
arch_program.html

57
58
59
60
61
62
63
64
65