Treinamento em Análise Quantitativa & Planejamento de Capacidade. Virgilio A. F. Almeida

Transcrição

1 Treinamento em Análise Quantitativa & Planejamento de Capacidade Virgilio A. F. Almeida DATAPREV Rio de Janeiro 26 Novembro de 2009 Módulo #1 Departamento de Ciência da Computação Universidade Federal de Minas Gerais UFMG

2

3 Visão geral do processo de gerência de capacidade X transações/por segundo Y% de uptime Z,. Monitorar e Atualmente, Quaisas medir quão providências somos rápidos e para nos confiáveis são rápidos e Sim! mantermos nossos serviços confiáveis? assim? Não! Mudar, Adicionar, remover coisas: hardware software arquitetura SLA, etc.

4 Organização do Treinamento Aulas: Dia Módulos Trabalhos 26 1, 2 A 27 3 b 7 4,5 c 8 6,7 d 14 8,9 e 15 9,10 f Uso constante da página Web: MPS teaching&lingua

5 Módulo Organização do Treinamento Assunto 01 Introdução a análise experimental, métodos quantitativos e introdução a performance e planejamento de capacidade; d visãogeral iã dos problemas 02 Conceitos básicos em estatística e probabilidades 03 Monitoração e sumarização de dados coletados: média, mediana, moda, variância, desvio padrão, coeficiente de variação. 04 Comparando sistemas usando dados de amostragem e intervalos de confiança; 05 Métodos de regressão linear simples; Outros modelos: regressão múltipla e regressão curvo linear 06 Introdução ao projeto experimental (Design of Experiments); Apresentação gráfica de dados experimentais 07 Técnicas de avaliação de desempenho: modelos operacionais, redes de filas 08 Técnicas de avaliação de desempenho: caracterização de carga, benchmarks, RPI e load testing 09 Metodologia geral para planejamento de capacidade: estudos de casos, ROI, qualidade de serviço e datacenters.

6 Referência Básica

7 Referências Lista de Artigos p g g 5. References

8 O que é desempenho?

9 O que é desempenho? [Aurélio] desempenho. [Dev. de desempenhar.] s.m., 1. Ato ou efeito de desempenhar( se). 2. Mil. Conjunto de características ou de possibilidades de atuação de uma aeronave, tais como velocidade de cruzeiro, velocidade de pouso, capacidade de carga, autonomia de vôo, etc. 3. Teat. V. interpretação.

10 O que é desempenho? [Webster] per.for.mance n p*(r) for m*n(t)s\ 1. a: the execution of an action b: something accomplished : DEED, FEAT 2. : the fulfillment of a claim, promise, or request: IMPLEMENTATION 3. a: the action of representing a character in a play b: a public presentation or exhibtion 4. a: the ability to perform: EFFICIENCY b: the manner in which a mechanism performs 5. : the manner of reacting Virgilio Almeida, to stimuli: UFMG 2009 BEHAVIOR

11 O que é capacidade?

12 O que é capacidade? [Aurélio] capacidade. d s.f., 1. Potencial para conter, acomodar ou guardar algo; 2. Poder de produção de execução; rendimento máximo (aquela fábrica reduziu sua c. em 50%) 2. c. ociosa Econ. Diferença entre o volume efetivo de produção e o que seria capaz de produzir 3. Teat. V. interpretação.

13 Performance e capacidade 1. Performance 1. expectativa do usuário 2. requisitos das aplicações/negócios 3. monitoração externa do serviço 2. Capacidade 1. métricas do sistema 2. teto dos recursos

14 O que, como e por quê? O que é desempenho? Mdid Medida da capacidade eficiência d iê i de resposta de um sistema Como analisar o desempenho de um sistema? Medições, análise quantitativa Métricas de desempenho Por quê? Aspecto chave no projeto, compra e uso de um sistema de computação Ex: desempenho de sistemas da Web é chave no dia a dia contemporâneo, transações bancárias, serviços, etc

15 Para quê? Identificar pontos de contenção e/ou de desperdício de um sistema Avaliar múltiplas alternativas de projeto e/ou implementação de uma aplicação Determinar configuração ótima dos parâmetros de um sistema Fazer previsão de desempenho em função do crescimento da carga Planejamento de capacidade Validação (identificação de erros de implementação)

16 Complexidade Ambientes complexos e dinâmicos Sistema = hardware + SO + aplicações Surgimento de novas aplicações Arquiteturas paralelas, multi core Dependência da carga: Comportamento de usuário é imprevisível Mudanças drásticas: flash crowds (india mumbai, novo decreto lei, etc) Requisitos (QoS) Service LevelAgreement (SLA) Tempo de resposta inferior a 1 segundo d õ ( Taxa de processamento superior a X transações por seg (quantos no google?)

17 Google: complexidade 3.1 million 2008 Worldwide searches on Google in July: 48.7 billion Worldwide searches on Microsoft in July: 2.3 billion Worldwide searches per hour on Google in July: 65 million Worldwide searches per hour on Microsoft in July:

18 Users really respond to speed. Marissa Mayer, google

19 +500 ms 20% Google +100 ms 1% Amazon

20 ``Do Web Measurements Measure Up?, Andrew Certain, Amazon, WWW 2002 o Web easu e e ts easu e Up?, d ew Ce tai, azo, WWW 00 Conference, May 2002

21 Speed matters!

22 Disponibilidade

23 23

24 24

25 Performance Metrics

26 Filas,,gargalos, g espera

27 Fila: queuing system

28 o modelo básico Tempo resposta: E[T] jobs λ: Taxa média μ: Taxa média ρ= λ/μ < 1: chegada de serviço Carga média (jobs/sec) (servidor) (utilização) roteadores processadores locks de bancos de dados Web servers pontos de acesso a wifi Virgilio Almeida, threads UFMG 2009.

29 real é diferente. e o QoS? SRPT Tempo de resposta médio E a gerência de energia? E a impaciencia do usuário E o conceirto de fairness? Usuários reais são E se os tamanhos interativos não são conhecidos? E os sistemas multi-core, multi servers?

30 Métricas de Desempenho Requisição para serviço i Tempo Corretamente Taxa Recurso Realizada Sistema Incorretamente Erro j Probabilidade Tempo entre erros Não Evento k realizada Duração do evento Tempo entre eventos

31 Métricas de Desempenho Tempode resposta (total, por componente) Taxa de processamento (throughput) Transações/s, HTTP requests/s, sessões/s, I/O/s, / etc. Utilização Disponibilidade (falhas ou sobre carga) Controle de admissão Disponibilidade vs. tempo de resposta Confiabilidade Custo (ROI: Return of Investment)

32 Métricas de Desempenho Segurança: confidencialidade, integridade autenticação Extensibilidade: fácil evolução para incluir novos requisitos funcionais e de desempenho A escolha da(s) métrica(s) mais adequada(s) é chave para o sucesso de umaavaliaçãodeavaliação desempenho Eliminar redundâncias (tempo de espera e tamanho da fila) Evitar métricas que têm alta variabilidade O conjunto de métricas deve ser completo As metricas devem ser realisticas e mensuráveis!!!!! Métricas devem ser possíveis de se obter!

33 Avaliação de Desempenho Modelagem analítica: Conjunto de fórmulas e/ou algoritmos que determinam as medidas de desempenho (métricas) em função de um conjunto de parâmetros de carga (entrada) Modelos determinísticos: análise de limites e de valores médios Modelos probabilísticos: processos estocásticos, modelos de filas Modelos de simulação Experimentação em sistemas it reais Instrumentação Monitoração

34 Por que é necessário o uso de modelos, prótotipos, instalações de homolgação para testar aplicações???

35 Testes com sistemas reais!!!

36 Visão geral do processo de gerência de capacidade X transações/por segundo Y% de uptime Z,. Monitorar e Atualmente, Quaisas medir quão providências somos rápidos e para nos confiáveis são rápidos e Sim! mantermos nossos serviços confiáveis? assim? Não! Mudar, Adicionar, remover coisas: hardware software arquitetura Como SLA, etc.

37 Trabalho A (exercícios Chapter 1)

38 Visão geral do processo de gerência de capacidade X transações/por segundo Y% de uptime Z,. Monitorar e Atualmente, Quaisas medir quão providências somos rápidos e para nos confiáveis são rápidos e Sim! mantermos nossos serviços confiáveis? assim? Não! Mudar, Adicionar, remover coisas: hardware software arquitetura SLA, etc.

39 Como??? Visão inicial 1. Dois conceitos básicos: modelos do sistema cargade trabalho (workload) 2. Abordagem sistemática para análisede desempenho e capacidade

40 Entender as situações futuras: Modelos do Sistema Carga Serviço Sistema (hw ou sw) Modelo: representação do comportamento do desempenho do sistema it Etapas principais: Caracterização do comportamento do usuário / carga: taxa de chegada, tempo de serviço Medições no sistema: utilização de recursos, nível de multiprogramação Medições no serviço: tempo de resposta, taxa de sucesso

41 Modelagem analítica responde: Exemplos de Aplicação Como o tempo de resposta de um banco de dados de transações varia com a taxa de transações? Qual o impacto no tempo de resposta de um upgrade de CPU? De disco? Em média, qual o número de processos que ficam bloqueados no semáforo X da aplicação Y? Simulação responde: Qual a política de replicação de conteúdo que resulta em maior byte hit ratio? Experimentação responde: Quais os principais componentes do tempo de resposta em um servidor Web? Qual o impacto da nova interface (ex: com vídeo) no desempenho de serviços na Web?

42 Seleção da Técnica de Previsão de Desempenho Modelagem dl analítica Podem ser razoavelmente precisas e simples Baixo custo: fornecem resultados rápidos Facilita projeto e configuração do sistema: melhora conhecimento sobre ele avaliação dos compromissos entre vários parâmetros impacto de cada parâmetro Responde perguntas do tipo what if Captura aspectos maisgerais do funcionamento do sistema não captura alguns aspectos do funcionamento.

43 Seleção da Técnica de Avaliação de Desempenho Simulação Custo mais elevado: simulação deve cobrir estado estacionário, várias execuções Captura detalhes do funcionamento do sistema Responde perguntas do tipo what if Experimentação Alta complexidade, muitas variáveis: alto custo Difícil avaliar impacto defatoresisolados: faltadecontrole Alta precisão se e somente se experimentação realizada corretamente

44 Seleção da Técnica de Avaliação de Critério Desempenho Modelagem Analítica Simulação Experimentação Estágio Qualquer Qualquer Após protótipo Tempo Pequeno Médio Variável necessário ái Ferramenta Análise Linguagem de Programação Instrumentação e Monitoração Precisão Variável Avaliação de Compromissos Fácil Médio Difícil Custo Pequeno Médio Grande

45 Abordagem Sistemática para Análise de Desempenho e Capacidade d 1. Definir objetivose e escopo (sistema/infraestrutura) 2. Listar serviços e saídas 3. Selecionarmétricasde desempenho 4. Medir, medir, medir 5. Especificar o estudo 1. Listar parâmetros 2. Selecionar fatores para estudo 3. Selecionar técnica de avaliação 4. Selecionar carga de trabalho 6. Projetar experimentos 7. Analisar e interpretar dd dados (resultados) 8. Apresentar resultados

46 1. Objetivos e Escopo do Projeto Definir objetivos do estudo é essencial para definir escopo Definir escopo é chave para as demais escolhas de métricas, cargas, técnica de avaliação Exemplos: Dd Dadas 2 servidores Objetivo 1: estimar impacto no tempo de resposta de usuários interativos ti Escopo: sistema de timesharing, resultado depende de outros fatores externos a CPU Objetivo 2: Servidores são similares com exceção das unidades de disco Escopo: somente componentes de armazenamento

47 3. Métricas de Desempenho Escolha específica para estudo, a partir da lista de serviços e possíveis saídas Execução correta: desempenho, escalabilidade tempo de resposta, taxa de processamento (serviço), utilização de recursos Execução incorreta: confiabilidade identificação das classes de erros probabilidade de cada tipo de erro, tempo entre erros Não execução: disponibilidade Identificação das possíveis causas Uptime (% tempo disponível), probabilidade de downtime, tempo entre falhas (MTTF = Mean Time To Failure)

48 Métricas System Statistics

49 Tempo de Resposta Intervalo de tempo entre requisição do usuário e a resposta do sistema Definição do intervalo tem que ser clara: Inclui tempo entre momento que usuário termina comando e sistema inicia execução? Inclui tempo entre início e término da geração da resposta? Pode conter vários componentes, com influência de vários subsistemas e da carga durante execução Ex: time <programa> (Unix) 3,5 real 0.2 user 0.9 sys real (user + sys) = 2.4 segundos gastos ONDE???

50 Causado por: Slowdown operações dei/o (leituras, escritas, paginação) tempo de rede tempo gasto em outros programas (escalonamento) contenção por recursos: filas dos recursos Tempo de resposta = tempo de serviço + tempo nas filas TR = TS + TF Slowdown = TF/TS : impacto do tempo de fila

51 Speedup Single_Core_App_Time Speedup_Factor = Multi_Core_App_Time Multi_Core_Mhz _ = Single_Core_Mhz _ * Speedup_Fac p_ tor Note: Multi_Core_App_Time assumes time to complete Single_Core_App_Time distributed among N cores plus communication time.

52 Taxa de Processamento Ou taxa de serviço: quantidade d de serviço executado por unidade de tempo (throughput) Capacidade nominal: capacidade especificada pelo fabricante Ethernet de 1 Gbps Disco com 40Mbps Capacidade útil: throughput máximo alcançável Ethernet 100: Mbps

53 Tempo de Resposta xtaxa de Serviço nominal Throughput joelho útil Joelho da curva = ponto ótimo de operação Tempo de Resposta Virgilio Carga Almeida, UFMG 2009

54 Outras Métricas Eficiência: capacidade útil / capacidade nominal Utilização : % tempo que recurso está executando serviço Tempo ocioso (idle time) Custo benefício = custo / desempenho custo por taxa de serviço US$/consultas/s, Métricas específicas % Perda de pacotes, tamanho das rajadas de perdas Qualidade do sinal

55 Escolha das Métricas Incluir métricas para Execução correta, incorreta e não execução Avaliar Média, mediana, percentis Variância, coeficiente de variabilidade (CV) Distribuições Medidas individuais, agregadas, por classes

56 4. Medições: se você não tem como medir sua capacidade atual, você não tem como conduzir um planejamento de capacidade!

57 5. Especificar o estudo: Metodologia do Ciclo de Vida de Projetos de Software e Desempenho Service Level Agreements SLAs provide a proven vehicle for not only capturing non functional requirements but also for monitoring and enforcing them. SLAs are special legal agreements that encapsulate multiple concerns, and symmetrically fuse the perspective of service supplier and customer.

58 5. Especificação de Requerimentos de Desempenho Especificação deve ser precisa e realista Problemas: Falta de especificação numérica o sistema deve ser eficiente... o sistema deve ser rápido... Métricas difíceis de avaliar Especificação não realista o sistema não deve produzir respostas com erros

59 5. Especificação de Requisitos de Desempenho Como fazer: 1. Escolha um serviço S 2. Escolha uma métrica M 3. Escolha um valor máximo X para a métrica M Opções: 1. média entre valores observados para M para o serviço S deve ser menor que X: SIM e NÃO! (variabilidade) 2. X%% (X grande) dos valores observados devem ser menores do que X: SIM!!!

60 5. Acordo de Nível de Serviço (SLA) Exemplos: RTT < 100 ms para conexões dentro dos EUA Sistemadeve estar disponível X% do tempo X = 99% 7.2 horas/mês downtime X = 99.9% 9% 43 minutos/mês downtime X = % 26 segundos/mês downtime Exemplos de SLAs de disponibilidade (Os 5x9 s) AT&T switches: 2hs de downtime em 40 anos Cisco, HP, MS, Sun: garantem % de disponibilidade (5 min /ano downtime)

61 5. SLA s Central para Performance 650ms no lado servidor 1.5s experiência do usuário Em 95 th percentile Em situações de pico 0% taxa de erro 61

62 5. Especificando Objetivos de Performance: algumas orientações Especificando SLA (service level agreement) Definir com os usuários finais a lista de serviços e seus requisitos de qualidade; Alguns critérios para estabelecer SLA: Custo x benefício Natureza da aplicação Índices de desempenho passados (histórico) Concorrência (ou competição de outros provedores de serviço)

63 SLA: Service Level Agreements

64 ROI: Disponibilidade Custos Downtime (US$/hora) Brokerage operations $ 6,450,000 Credit card authorization Ebay (1 outage 22 hours) Amazon.com Packageshipping services Home shopping channel Catalog sales center Ailine reservation center Clll Cellular service activation On line network fees $2,600,000 $225,000 $180,000 $150,000 $113,000 $90, $89,000 $41,000 $25,000 ATM service fees $14,000 Fonte: InternetWeek 4/3/ Fibre Channel: A Comprehensive Introduction, R. Kembel 2000, p Based on a survey done by Contingency Planning Research

65 6. Projetar experimentos: Carga de Trabalho Carga baseada na lista de serviços do sistema Deve ser representativa do sistema real Caracterização das cargas Cargas sintéticas vs. cargas reais Cargas reais: traces Cargas sintéticas: modelo baseado em distribuições estatísticas É importante definir nível de agregação g (classes)

66 6. Carga de Trabalho Carga baseada na lista de serviços do sistema Deve ser representativa do sistema real Caracterização das cargas Cargas sintéticas vs. cargas reais Cargas reais: traces Cargas sintéticas: modelo baseado em distribuições estatísticas É importante definir nível de agregação g (classes)

67 Exemplo das questões de sumarização de dados Agregação: Exemplo 1 Várias tarefas, demanda por CPU Tarefa Tempo médio de utilização de CPU (s) T1 10 T2 0.7 T T4 12 T5 0.8 T6 1 T7 0.5 T Média = 3.13

68 Agregação: Exemplo 1 Várias tarefas, demanda por CPU Tarefa Tempo médio de Classe utilização de CPU (s) T1 10 A T2 0.7 B T C T4 12 A T5 0.8 B T6 1 B T7 0.5 B T C Média A = 11 Média B = 0.67 Média C = 0.025

69 Agregação: Exemplo 2 Tempo entre chegada de requisições em um servidor de vídeo em um dia típico Período Taxa de chegadas (#reqs/min) Tempo médio entre chegadas (min) 3:00 6: :00 12: :00 20: :00 3: Agregação também pode ocorrer no tempo

70 Agregação: Exemplo 3 Tempo entre chegada de e mails no servidor central da UFMG em um dia típico Período Taxa de chegadas (# s/hora) 1:00 6: :00 18: :00 24: Agregação também pode ocorrer no tempo E se você dimininuir o intervalo, o que deve acontecer?

71 Agregação: Exemplo 4 % do vídeo assistido em cada interação de um usuário em um vídeo educacional (utilização de banda do servidor) Tamanho do % Vídeo assistido id por Vídeo (min) interação % % %

72 6. Parâmetros dos experimentos Listar parâmetros que afetam desempenho Parâmetrosdo sistema: software e hardware CPU, memória, disco, controladora, tamanho de buffer (cache), políticas de escalonamento Parâmetros de carga: usuário (imprevisível) Tamanho, tipo e frequência das requisições a serviços Eliminar parâmetros redundantes e/ou normalizar Ex: servidor devídeo: Taxa de chegada λ, Tamanho do arquivo T (minutos) Impacto no sistema: N = λt Não precisa variar λ e T isoladamente, mas apenas o produto N

73 Fatores Parâmetros que vão variar no estudo Variação = nível Escolha: parâmetros com maior impacto e controlável Começar com poucos parâmetros e níveis e estender a partir da avaliação dos resultados Controlar número de parâmetros e níveis (Por que???) Avaliação inicial do impacto relativo de cada um Refinamentos posteriores

74 A escolha depende: Técnica de Avaliação Escopo (aspectos gerais x detalhes) e estágio Tempo e recursos disponíveis Precisão desejada Sejaqual fora escolha, duvide... Analise resultados de simulação até que sejam validados por análises ou experimentos Analise resultados de modelos analíticos até que sejam validados por simulação ou experimentos Analise resultados de experimentos até que sejam validados por modelos analíticos ou simulação É NECESSÁRIO VALIDAR OS RESULTADOS!!!

75 7. Experimentos e Resultados Projeto dos experimentos a partir da definição dos fatores e níveis Análise de sensibilidade: E se premissas feitas não forem verdadeiras? Análise dos resultados Tratamento estatístico Duração da simulação e/ou experimento suficiente Número de repetições com sementes diferentes para capturar e/ou filtrar variabilidade Importante transformar números em conclusões Apresentação: gráficos significativos Reavaliar decisões tomadas e possivelmente refazer estudo: novo ciclo il

76 7. Apresentação dos resultados

77 7. Apresentação dos resultados

78 Prática das empresas (Dataprev?) O que é Engenharia de Software - ES (ou deveria ser?) Aplicação sistemática de princípios de computação e matemática ái ao projeto, manutenção e evolução de sistemas de software, de tal forma que todos os requisitos ii funcionais f i i e não funcionais i sejam satisfeitos.

79 Engenharia Tradicional

80 Engenharia Tradicional: Workloads Uso de workloads: 1) Avaliar sistemas it existentes it t 2) Avaliar projetos propostos e alternativas 3) de projetos para novos sistemas Workloads tem sido usadas nas áreas De ciência e engenharia: pontes são projetadas para suportar workload de tráfego e as cargas sismicas e aerodinâmicas A ponte Tacoma Narrows rompeu em 1940 devido a falhas referentes a cargas aerodinâmicas. A ponte do Brooklyn permanece intacta devido a projeto maciçamentesuperdimensionado superdimensionado. Seus projetistas sabiamque o conhecimento deles sobre a carga era impreciso e limitado 80

81 Engenharia Tradicional Um projetista de uma ponte precisa saber: o tipo e a natureza do serviço na ponte(ex:. Estradadeferro de ferro, carros, caminhões, pedestres, ) os materiais de construção da ponte (ex: aço, concreto) forças aerodinâmicas,... A taxa de operação da ponte, i.e., máximo absoluto nível de carga permitida por veículo(ex, 44.1 tons). Tráfego médio diário (ex, 5,400 carros, 1,200 caminhões) O projetista da ponte necessita entdenr e quantificar a workload daponte: tipos de carga e níveis de carga 81

82 Engenharia de Software ES

83 Performance e ES (algumas causas) Mentalidade de usuário único. Concorrência é desconsiderada pelos programadores ao escrever código. Concorrência por recursos físicos: ex: múltiplos cores c Concorrência por recursos de software ex: databaselocks, seções críticas, e threads de software

84 Performance e ES (algumas causas)

85 Performance e ES (algumas causas) Mentalidade de pequenos bancos de dados Maioria dos programadores escrevem código de acesso a BD sem levar em conta o tamanho do banco. Mi Maioria i dos testes com pequenos BD para testar funcionalidade. A performance de um SQL call em um BD com 1,000 linhas pode ser significante diferente daquela em um BD com um milhão de linhas.

86 O que pode ser feito? Treinamento e educação Integraçãonatural dos conceitos de performance nos cursos de engenharia de software e nos programas de treinamento e formação de engenheiros de software emtodososníveis. Na indústra Desenvolvimento e adoção de ferramentas/metodologias para facilitar a integração de gerência de performance e instrumentação nas diferentes fases do ciclo de vida de desenvolvimento de software.

87 MENSAGEM

88 Questões práticas 1. Impactos da determinação de níveis de serviço no desenho arquitetural; 2. Boas práticas de Quality Assurance voltados à homologação de níveis de serviço; (pode se generalizar mais e trazer também para a área de testes de aceitação do sistema.) 3. Planejamento e implementação de práticas de performance e planejamento de capacidade; d 4. O problema clássico dos testes de performance não está em medir números de performance (isso é geralmente fácil) mas sim em determinar se esses resultados são bons ou ruins. Como estabelecer a expectativa de performance antes do teste (determinar a margens de aceitação) ligada ao planejamento e implementação de performance e capacidade? 5. Os temas performance e capacidade são abordados de maneira difusa em várias empresas, por isso é importante uma abordagem de aspectos genéricos que possam começar a criar a percepção da profundidade, criticidade e necessidade do tema: discussão sobre o perfil profissional comumente associado a essa disciplina, a abordagem das questões de determinação e homologação de níveis de serviço, etc.

89 TRABALHOS EM AULA: EXERCICIOS E EXEMPLOS

90 Opinião da Turma? Pontos importantes na Dataprev Dificuldades em tratarperformance e capacidade na Dataprev Exemplos interessantes de problemas de performance e capacidade ocorridos na Dataprev?