Análise e aperfeiçoamento de benchmark OLTP para avaliação de desempenho em SGBD

Texto

(1)&. #$ % &. %. /. 0. -. 1. !". RECIFE, OUTUBRO/2006. ' ()* + ,-..

(2) UNIVERSIDADE FEDERAL DE PERNAMBUCO CENTRO DE INFORMÁTICA PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO. FÁBIO ÁVILA RÊGO PESSOA. “Análise e aperfeiçoamento de benchmark OLTP para avaliação de desempenho em SGBD". ESTE TRABALHO FOI APRESENTADO À PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO DO CENTRO DE INFORMÁTICA DA UNIVERSIDADE FEDERAL DE PERNAMBUCO COMO REQUISITO PARCIAL PARA OBTENÇÃO DO GRAU DE MESTRE EM CIÊNCIADA COMPUTAÇÃO.. ORIENTADORA: ANA CAROLINA SALGADO. RECIFE, OUTUBRO/2006.

(3) Pessoa, Fábio Ávila Rêgo Análise e aperfeiçoamento de benchmark OLTP para avaliação de desempenho em SGBD. – Recife : O Autor, 2006. 99 folhas : il., fig., tab., quadros. Dissertação (mestrado) – Universidade Federal de Pernambuco. CIn. Ciência da Computação, 2006. Inclui bibliografia e apêndice. 1. Ciência da computação – Banco de dados – Análise de desempenho. 2. Benchmarks – OLTP (Online Transaction Processing) – TPC-C – Aperfeiçoamento e análise. 3. Proposta de classificação – Fatores de qualidade. I. Título. 004.65 004.24. CDU (2.ed.) CDD (22.ed.). UFPE BC2006 – 511.

(4) Sumário. ! " " # $. % % %. & & & # $. $. &. '. &. ' ( ( (. ). ' ' + +. *. ) &. $. ,. # $. &. ( & (. (. & $. ' ,. &. " !. & !. #. & & &. ' +. 2.

(5) &. ,. &. ' ' ' ' ''. ". '+. &. &. '. $. - *. .. -. '+ ". $. + + +'. $ $. .. # &. (/*. -. $. + +,. &0 $. &. ' '. $. '. '. &. '. +. &. +. *. %. *. &. ,. $. 1. %. &. " 2. ,3. ,. 1. %. &. " 2. +3. ,. %. 1. &. " 2. +3. ,. 1. %. &. " 2. +3. ,. 1. %. &. " 2. +3. ,. %. 1. %. 1 1 1. ++. &. " 2 " 2. &. +3 +3. ,' ,. %. &. " 2. +3. ,. %. &. " 2. +3. ,,. 3.

(6) 1. Introdução Medir o desempenho de ambientes de missão crítica é uma tarefa importante para consumidores e fornecedores de software e hardware. O desenvolvimento de metodologias (ou benchmarks [1]) que viabilizem a comparação do desempenho conjunto de software e hardware foi objeto de estudo na comunidade de Banco de Dados, principalmente nos anos 80 e 90. Nos últimos 20 anos, foram propostos benchmarks [2 a 10] que propõem métricas relevantes ao negócio do usuário final, tais como número de transações realizadas por intervalo de tempo e custo de cada transação. Muitas vezes, estes benchmarks modelam o funcionamento de uma aplicação completa, e têm destaque na mídia em anúncios de marketing dos fornecedores de hardware e software, com o objetivo de demonstrar desempenho superior ao de produtos concorrentes. A definição do Webster’s II dictionary diz que um benchmark é “um padrão para medida ou avaliação”. Um benchmark computacional é tipicamente um programa de computador que realiza um conjunto de operações (uma carga de trabalho) restrito e pré-definido e retorna um resultado em algum formato (uma métrica) descrevendo como os elementos testados se comportaram. Métricas de benchmark computacionais normalmente medem rapidez (em qual velocidade a carga de trabalho foi completada) ou vazão (quantas cargas de trabalho por unidade de tempo foram medidas). Ao executar o mesmo benchmark computacional em múltiplos computadores, é possível realizar comparações [11]. Benchmarks são importantes ferramentas para os consumidores; servem para auxiliar na decisão da compra do hardware e software com melhor desempenho para suas necessidades. Dessa forma, fabricantes de hardware e software usam resultados de benchmark como instrumentos de marketing, para divulgar vantagens de desempenho de seus produtos sobre os concorrentes. Os benchmarks também têm sido requisitados quando se deseja uma garantia de desempenho ou qualidade. O governo brasileiro introduziu um requisito em alguns pregões de aquisição de servidores [12], para que o benchmark TPC-C (Benchmark C da organização Transaction Processing Performance Council) [3] seja realizado pelo fabricante no servidor proposto, atingindo um patamar mínimo de desempenho. Inúmeras referências na mídia, não necessariamente produzidas pelos fabricantes, trazem afirmações comparativas de desempenho embasadas em resultados de benchmarks TPC-C [13 a 17]. 4.

(7) Há 13 anos, a TPC (Transaction Processing Performance Council) [18] publicou o TPC-C [3], um benchmark OLTP (Online Transaction Processing, ou processamento de transações online) amplamente conhecido e referenciado no mercado de servidores. Ele permite comparações entre o conjunto formato por SGBD (Sistema Gerenciador de Banco de Dados), hardware e Sistema Operacional. A TPC [18] é uma organização formada por um consórcio entre os fabricantes de hardware e software interessados nos resultados de benchmarks. Desde o final dos anos 80, os benchmarks ganharam mais credibilidade com a criação das organizações de benchmark, uma vez que cada empresa participante se empenha na produção de um benchmark mais justo, onde seu produto não saia prejudicado por uma avaliação tendenciosa ou muito específica. Outras organizações também foram criadas com finalidade de definir padrões de indústria de benchmark: SPEC [19], SPC [20], BAPCo [21] e EEMBC [22]. Estas organizações conduzem os trabalhos de criação de benchmarks em sigilo, mantendo áreas privadas nos seus sites para compartilhamento de informações entre seus membros. Depois da conclusão dos trabalhos e aprovação interna, novos benchmarks são disponibilizados para o público, com especificações detalhadas. Os benchmarks também auxiliam a detectar problemas em SGBD. Por exemplo, o Wisconsin Benchmark [2] mostra como um SGBD relacional responde a uma consulta específica em alguns segundos, enquanto outro SGBD leva várias horas, já que os otimizadores de consulta usam estratégias diferentes. O benchmark da Sun [23] descobriu problemas com o sistema de indexação para um produto de SGBD relacional [24].. 1.1. Motivação Carolyn Turbyfill, que participou da confecção dos benchmarks Wisconsin [2] e AS3AP [4], comenta na perspectiva histórica de sua publicação a respeito do AS3AP que percebeu rapidamente, deparada com a necessidade de comparar o desempenho de diferentes sistemas de SGBD, que uma metodologia apropriada de benchmarking era, por si só, um tópico de pesquisa. Este trabalho se concentra em benchmarks para SGBD, mais especificamente em benchmarks OLTP. Atualmente, o benchmark padrão de indústria para esta área é o TPC-C. Entretanto, o TPC-C demonstra vários sinais de obsolescência, tais como uma utilização pouco ampla das funcionalidades relevantes e um balanceamento pouco adequado de recursos de hardware, entre outros. Um novo benchmark OLTP para SGBD se faz necessário, como pode ser observado em duas iniciativas da própria TPC: (a) solici5.

(8) tando propostas para um novo benchmark OLTP [25] e (b) em fase final de aprovação do TPC-E [5;26;27]. O TPC-E deverá substituir o TPC-C como benchmark OLTP padrão de indústria para SGBD. Há uma série de requisitos relacionados que determinam a qualidade de um benchmark. Muitos destes requisitos são conflitantes. É um grande desafio propor benchmarks que atendam de forma ampla aos requisitos, de forma balanceada. Na literatura, não há um consenso em relação à definição dos requisitos e classificação dos fatores de qualidade. Nos dias atuais, continua existindo um obstáculo importante que impede que muitos trabalhos de análise e comparação de desempenho sigam adiante. O motivo principal é que algumas afirmações de desempenho não são bem vindas pelos fabricantes. David DeWitt propôs em 1983 o Wisconsin Benchmark [28]. No trabalho, são feitas comparações experimentais do desempenho de SGBD existentes. Naturalmente, o mau desempenho divulgado não agradou os fornecedores que haviam se saído mal nos resultados experimentais [29]. Pouco depois, foi introduzida uma cláusula na maioria dos produtos comerciais [30], que acabou sendo conhecida como “cláusula DeWitt” [29 a 32]. A cláusula DeWitt proíbe que sejam realizados benchmarks sem prévia autorização do fabricante. O contrato de licença de uso do Microsoft® SQL ServerTM (EULA) [33] possui uma cláusula1 como esta, que tem o intuito de proteger os fabricantes contra trabalhos mal conduzidos e erroneamente configurados de avaliação de desempenho que terceiros possam vir a realizar sobre seus produtos. A cláusula restritiva desencorajou que trabalhos similares ao conduzido por DeWitt fossem realizados depois de sua introdução, embora até juizados estaduais tenham concluído que tal restrição não podia ser feita [34]. A restrição não afeta o trabalho feito pelas organizações de benchmark, já que os fabricantes são participantes diretos das mesmas. A Neal Nelson & Associates [35] descreve 5 diferentes segmentos que geram demanda para benchmarks na arena dos SGDB: fabricantes de SGBD, fabricantes de computadores, revistas e jornais, universidades e clientes. O raciocínio pode facilmente ser estendido para outras áreas, com segmentos e interesses similares. Fabricantes de SGBD e computadores conduzem benchmarks para mostrar as vantagens de seus produtos, e persuadir clientes a comprá-los. Nem sempre existe um 1. Benchmark Testing: You may not disclose the results of any benchmark test of either the Server Soft-. ware or Client Software to any third party without Microsoft’s prior written approval.. 6.

(9) compromisso em avaliar todos os aspectos do produto e, em geral, são escondidas algumas limitações. Revistas, jornais e outras publicações ocasionalmente financiam benchmarks para a confecção de artigos. Os produtos selecionados são de escolha dos responsáveis pela publicação e pode acontecer de um produto relevante e de interesse do consumidor ser sumariamente excluído da avaliação. Uma desvantagem desse tipo de publicação é que não há espaço nos artigos para incluir detalhes importantes de como o ambiente foi configurado ou os testes conduzidos. Universidades e outras instituições acadêmicas ocasionalmente publicam resultados de testes de benchmark. Em geral, esses testes são bem mais detalhados, mas podem excluir completamente áreas de funcionalidade que não interessem à área de pesquisa de interesse. Por último, clientes podem conduzir seus próprios benchmarks de SGBD antes de uma decisão de compra. Esse pode parecer um processo simples e mais orientado à necessidade particular do cliente mas, em geral, o tempo reservado para este tipo de trabalho é bastante reduzido porque frequentemente o intervalo de tempo onde uma decisão de compra deve ser tomada é curto, pressionado pelas necessidades do cliente. No caso de revistas, universidades e clientes, a cláusula DeWitt pode se tornar um grande obstáculo para a divulgação e até mesmo realização dos benchmarks. A sexta alternativa proposta por Neal Nelson & Associates é realizar uma medição de desempenho através do auxílio de uma empresa especializada em benchmarks, que não seja comprometida com nenhum fornecedor de software ou hardware. Portanto, é bastante clara a importância de benchmarks para diversas comunidades de usuários de informática, principalmente em áreas diretamente relacionadas ao funcionamento de aplicações reais. Entretanto, não há trabalhos de pesquisa que realizem avaliações críticas de benchmarks, há poucos resultados experimentais mostrando possíveis melhorias nos benchmarks, e este trabalho fica sempre confinado nas organizações de benchmark. Mesmo com a abertura das especificações e resultados, uma análise mais crítica e minuciosa pode revelar pontos de melhoria nos benchmarks e nos seus processos de auditoria, execução e publicação. Um processo de “benchmark dos benchmarks” é importante para garantir a qualidade, credibilidade e aplicabilidade dos benchmarks ao longo do tempo. Um trabalho de pesquisa sem conflito de interesses com fabricantes dos produtos envolvidos mostra-se bastante adequado para este fim.. 7.

(10) Um bom benchmark deve ser popular, para que possa ser bastante referenciado e respeitado em comparações de desempenho. Entretanto, esse requisito deve ser atendido sem perder a semelhança com sistemas reais. Para tal, é importante que o custo financeiro e de tempo envolvido em sua execução seja alcançável por um público abrangente, o que aumenta o número de instituições capazes de executá-lo e verificar sua validade, reproduzindo sua execução com facilidade. Para isso, é importante que sua especificação e todos os detalhes da execução sejam abertos. Algumas características do benchmark TPC-C inviabilizam que muitos fabricantes tenham condições de executá-lo, porque o custo da execução é bastante alto e inadequado aos recursos de hardware tipicamente utilizados em ambientes OLTP, principalmente em relação ao sub-sistema de I/O. Nem todas os detalhes dos resultados TPC-C são realmente abertos, o que inviabiliza que ele possa ser verificado junto ao público em geral. Um trabalho de pesquisa pode revelar detalhes importantes em relação a potenciais violações destes importantes requisitos.. 1.2. Objetivo O objetivo deste trabalho de pesquisa é proporcionar uma análise crítica do TPC-C, benchmark OLTP padrão de indústria, assim como propor melhorias simples na implementação do benchmark, com o objetivo de torná-lo mais popular e adequado ao hardware tipicamente utilizado para sistemas OLTP na realidade atual. É proposta uma consolidação de conceitos em relação aos requisitos e qualidade de um benchmark, sugerindo um novo agrupamento e conceituação de termos para proporcionar um melhor entendimento dos termos utilizados. Também é relatado como ocorre uma publicação TPC-C de acordo com as especificações oficiais [3], sugerindo pontos de melhoria no processo de publicação e auditoria do resultado. O relato é baseado em uma publicação real conduzida por um projeto de pesquisa no Centro de Informática/UFPE.. 1.3. Estrutura geral deste trabalho O restante deste trabalho está organizado da seguinte forma: o capítulo 2 lista alguns benchmarks mais relevantes para SGBD, produzidos tanto no meio acadêmico quanto por organizações de benchmark. A intenção é descrever o estado da arte em benchmarks para SGBD, abordando os mais relevantes e mostrando uma visão geral das organizações de benchmark. A descrição das organizações de benchmark é feita para ilustrar a credibilidade do trabalho produzido pelas mesmas. 8.

(11) O capítulo 3 propõe uma classificação dos requisitos e fatores de qualidade de um benchmark para SGBD. Na literatura, não há consenso sobre estes pontos, é feita uma proposta que visa organizar alguns conceitos e classificações centrais para benchmarks para SGBD em geral, dando destaque para benchmarks OLTP. O benchmark TPC-C é o benchmark OLTP padrão de mercado na atualidade. O capítulo 4 irá documentar com detalhes a publicação oficial de um resultado deste tipo junto à TPC, e realizar uma análise crítica do processo de auditoria e publicação. Uma das contribuições mais relevantes deste capítulo é destacar diversos aspectos do processo da execução e publicação TPC-C que não são incluídos na sua documentação obrigatória disponibilizada para o público em geral. O capítulo 5 mostra algumas inadequações do benchmark TPC-C para os dias atuais. Alguns experimentos foram realizados, modificando detalhes de implementação do TPC-C. Os experimentos são detalhados e são mostrados seus resultados, sugerindo melhorias no benchmark TPC-C para torná-lo mais adequado e popular. O capítulo 6 consolida as conclusões deste trabalho, explicita suas contribuições e apresenta sugestões para trabalhos futuros.. 9.

(12) 2. Benchmarks padrão de mercado para SGBD Este capítulo traz um histórico de duas linhas de desenvolvimento de benchmarks para SGBD. É mostrada uma visão geral de algumas organizações responsáveis pela produção de benchmarks padrão de indústria. Em seguida, são detalhados alguns pontos principais de alguns benchmarks mais relevantes para SGBD: Wisconsin, AS3AP, TPC-C e TPC-E, com destaque para o TPC-C. Há múltiplos aspectos relativos ao desempenho. Cada benchmark mede aspectos diferentes do desempenho do sistema, abordando um segmento de mercado específico. Por exemplo, o TPC-H mede o desempenho de suporte à decisão em SGBD. TPC-W tem foco no desempenho do sistema fim-a-fim [36]. Benchmarks do SAP medem os vários aspectos de desempenho do ERP (Enterprise Resource Planning, ou Sistema de Planejamento de Recursos). O TPC-C mede o desempenho do SGBD em um ambiente OLTP.. 2.1. Breve histórico de benchmarks para SGBD Pelo menos duas linhas principais podem ser destacadas na evolução dos benchmarks para SGBD. Uma delas reflete o trabalho desenvolvido no meio acadêmico, com a criação dos benchmarks Wisconsin [2] e AS3AP [4]. Estes benchmarks são voltados para o desempenho de SGBD relacionais. O primeiro benchmark popular para SGBD foi o Wisconsin Benchmark [2], lançado em 1983 como um trabalho acadêmico produzido por David Dewitt. A intenção era testar algumas funcionalidades básicas de consultas e atualizações de SGBD a partir de comandos SQL. O teste ganhou popularidade rapidamente, pois era produzido por um órgão neutro, a Universidade de Wisconsin, era muito fácil de implementar e apesar de bastante simples, testava funcionalidades bastante relevantes para os SGBD da época. DeWitt incluiu em seu trabalho um comparativo experimental do benchmark proposto incluindo os SGBD Oracle®, DIRECT, Ingres e IDM 500. Nos resultados, alguns SGBD comerciais mostraram resultados decepcionantes em algumas etapas do benchmark, o que naturalmente desagradou seus fabricantes. Desde então, a maioria dos fabricantes de SGBD (por exemplo, Oracle, Microsoft e Sybase©) começaram a introduzir uma nova cláusula em seus contratos de licença de uso de SGBD, que ficou conhecida como “cláusula DeWitt” [29;30]. Esta cláusula proíbe testes de benchmark sem uma autorização explícita do fabricante. A cláusula representa atualmente um sério empeci10.

(13) lho para trabalhos de avaliação de desempenho, porque permite aos fabricantes autorizar apenas os trabalhos com resultados favoráveis ao seu produto, segundo critérios que não necessariamente precisam ser divulgados. Em 1987, Carolyn Turbyfill propôs o AS3AP [4] - A SQL Standard Scalable And Portable (escalável, portátil e baseado no padrão SQL) como resultado de sua tese de doutorado. O AS3AP define 93 operações (comandos SQL), e exercita formatos de saída diferentes (na tela, em tabela ou em arquivo), promovendo uma cobertura bem mais significativa das funcionalidades do SUT2 do que o Wisconsin Benchmark. Em 2001, foi produzido e disponibilizado no SourceForge [37] o OSDB (Open Source Database Benchmark) [38], uma implementação incompleta do benchmark AS3AP. A outra linha de trabalho que produziu resultados relevantes para os benchmarks de SGBD culminou na criação de órgãos sem fins lucrativos com a função exclusiva de definir e refinar benchmarks, além de auditar resultados. Em 1984, motivados em sanar deficiências do Wisconsin Benchmark, Jim Gray e colegas [39] definiam três testes padrões de desempenho para sistemas OLTP: um teste para processamento de transações online, o DebitCredit; e dois outros testes em lote, um sort (ordenação de um conjunto de dados) e um scan (varredura completa de um grande conjunto de dados). A intenção era caracterizar aspectos fundamentais de um sistema comercial real OLTP. Para o teste online, a proposta do DebitCredit era simular um sistema usado por caixas de um grande banco com múltiplas agências. O artigo não era claro o suficiente para que pudessem ser produzidos resultados. Mesmo assim, muitos fabricantes produziram resultados através de implementações incompletas da proposta do DebitCredit, naturalmente de credibilidade questionável. O DebitCredit foi a base para os dois primeiros benchmarks produzidos pela TPC, TPC-A e TPC-B. Muitos dos princípios básicos do TPC-A, tais como simplicidade, aplicabilidade a sistemas distribuídos, escalabilidade, comparabilidade e neutralidade de fornecedor já estavam presentes no DebitCredit. Cinco anos depois, a TPC divulgou o Benchmark TPC-C, com mudanças importantes em relação aos predecessores. 2. SUT (System Under Test) é um termo comumente utilizado nas especificações de benchmark. O SUT é. o conjunto de elementos avaliados no ambiente sob teste. Nem todos os elementos do ambiente fazem parte do SUT. Em alguns benchmarks, como é o caso do TPC-C, a maioria dos elementos responsáveis pela geração da carga de trabalho não devem ser incluídos no documento que representa o resultado final do benchmark.. 11.

(14) TPC-A e TPC-B, que se tornaram obsoletos com o lançamento do TPC-C. O TPC-C teve uma forte aceitação no mercado e ainda é o benchmark OLTP mais popular, conhecido e respeitado na atualidade. Treze anos após a divulgação do TPC-C, este benchmark vem mostrando vários sinais de inadequação para o hardware contemporâneo, tais como o número excessivo de discos necessário para sua execução e sua inadequação tecnológica e outros, detalhados no capítulo 5. Atualmente, a TPC vem trabalhando no que será o substituto do TPC-C, o TPC-E. É curioso observar que as organizações de benchmark foram criadas em épocas similares: TPC e SPEC nasceram ambas em 1988; BAPCo, SPC e EEMBC foram fundadas entre 1997 e 1998.. 2.2. Alguns benchmarks para SGBD Esta seção mostra uma visão geral de alguns benchmarks para SGBD, tanto criados por organizações de benchmark quanto produzidos por trabalhos acadêmicos. 2.2.1. O Wisconsin Benchmark O primeiro benchmark para SGBD que ganhou popularidade foi o Wisconsin Benchmark [2]. O benchmark rapidamente passou a ser utilizado como um padrão para avaliar o desempenho de SGBD. Entretanto, o Wisconsin Benchmark não era muito abrangente em relação aos recursos avaliados do SGBD, e definia uma carga de trabalho apenas mono-usuário. O Wisconsin Benchmark utiliza dados sintéticos, sem relação com aplicações reais, porque a escalonabilidade de dados reais é muito mais complexa, e a cobertura sistemática de um maior número de recursos do SGBD seria comprometida. Dessa forma, o Wisconsin define 3 tabelas: uma com 1.000 registros (ONEKTUP), e outras duas com 10.000 registros cada (TENKTUP1 e TENKTUP2). As tabelas TENKTUP1 e TENKTUP2 são compostas de 13 campos inteiros (de 2 bytes) e 3 campos char de 52 posições, conforme mostra o Quadro 1. É requerido que índices sejam criados em pelo vários campos dessa tabela, exercitando índices clustered, non-clustered e tanto em tipos inteiros quanto char. Uma crítica feita à primeira versão do Wisconsin Benchmark era a falta de escalonabilidade. Em resposta, uma mudança foi introduzida no benchmark, permitindo que o número de registros das tabelas fosse regulável.. 12.

(15) Quadro 1 – Especificação de atributos das tabelas definidas pelo Wisconsin Benchmark [2]. Atributo. Faixa de valores. Ordem. Observações. unique1. 0 – (no. registros-1). Aleatório. Chave candidata. unique2. 0 – (no. registros-1). Sequencial. Chave primária. two. 0-1. Aleatório. (unique1 mod 2). four. 0-3. Aleatório. (unique1 mod 4). ten. 0-9. Aleatório. (unique1 mod 10). twenty. 0-19. Aleatório. (unique1 mod 20). onePercent. 0-99. Aleatório. (unique1 mod 100). tenPercent. 0-9. Aleatório. (unique1 mod 10). twentyPercent. 0-4. Aleatório. (unique1 mod 5). fiftyPercent. 0-1. Aleatório. (unique1 mod 2). unique3. 0 – (no. registros-1). Aleatório. unique1. evenOnePercent. 0,2,4,…,198. Aleatório. (onePercent * 2). oddOnePercent. 1,3,5,…,199. Aleatório. (onePercent * 2) + 1. stringu1. Aleatório. Chave candidata. stringu2. Sequencial. Chave candidata. string4. Cíclico. O Wisconsin Benchmak define consultas com o intuito de avaliar o desempenho da maioria dos operadores relacionais, incluindo seleção com diferentes fatores de seletividade, projeções com diferentes percentuais de atributos duplicados, junções simples e múltiplas, agregações simples, funções de agregação, inserções, exclusões e modificação de registros. Ao todo são definidos 32 procedimentos, e o tempo de resposta de cada um deve ser medido. As consultas devem criar uma tabela temporária com seu resultado. Dessa forma, não existe uma única métrica para definir o desempenho, que deve ser avaliado pelo tempo de resposta de cada procedimento separadamente. 2.2.2. O AS3AP Benchmark O AS3AP Benchmark [4] foi uma extensão do trabalho iniciado pelo Wisconsin Benchmark. O AS3AP promove uma boa cobertura dos recursos de um SGBD nos 93 procedimentos propostos, testando de forma abrangente diferentes métodos de acesso,. 13.

(16) tipos de dados, índices, junções, projeções, agregações, atualizações, bulk load, formato de saída dos comandos e testes multi-usuário. A sigla AS3AP significa ANSI SQL Standard Scalable And Portable (escalonável e portável baseado no padrão ANSI SQL). O AS3AP foi desenhado para prover um conjunto de testes para medir objetivamente o poder de processamento de SGBD relacionais. A definição permite a implementação em plataformas diferentes, para permitir comparações mais amplas entre um grande número de sistemas. Uma métrica primária uniforme é definida, o tamanho do banco equivalente (equivalent database size), que permite uma interpretação imediata e não-ambígua dos resultados. A métrica reflete o tamanho máximo do banco de dados capaz de executar todas as operações definidas em menos que 12 horas. É exigido também que o tamanho do banco de dados não seja menor do que a memória física disponível no servidor do SGBD. O custo por desempenho também pode medido baseado nesta métrica, dividindo o custo total do ambiente pela taxa do banco equivalente. É sugerido que o custo total seja computado conforme as especificações do TPC-B. Benchmarks anteriores ao AS3AP não exploravam amplamente os recursos do SGBD, tais como carga e restauração de backups, além de prover uma métrica simples e objetiva para permitir comparações. O Wisconsin não define essa métrica, e testa apenas recursos do Query Optimizer. Já o DebitCredit, apesar de definir uma métrica, testa apenas o poder de processamento concorrente de transações online curtas. Os procedimentos do AS3AP estão agrupados em três categorias de teste: (i) carga, população e indexação, (ii) mono-usuário e (iii) multi-usuário. Nos testes mono-usuário, são utilizadas consultas para testar métodos de acesso (de forma mais ampla que o Wisconsin) e otimização básica de consultas, explorando seleções, junções simples, projeções, agregações, atualizações de um registro, e atualizações em lote (bulk updates). Os conjunto de testes foi definido de forma a explorar os recursos definidos pelo padrão SQL ANSI 2 [40] e a explorar de forma mais ampla os tipos de dados providos pelo SGBD. Os testes multi-usuário modelam três tipos diferentes de cargas de trabalho tipicamente submetidas a SGBD: (a) cargas de trabalho tipicamente OLTP; (b) cargas de trabalho tipicamente de consultas ou extração de informações (IR – Information Retrieval); (c) cargas de trabalho mistas, havendo um balanceamento entre transações curtas, consultas de relatório, varredura completa em tabela, e transações longas.. 14.

(17) O banco de dados definido utiliza 4 tabelas de igual estrutura, cada uma com 11 campos. O Quadro 2 mostra os tipos de dados que devem ser utilizados em cada campo conforme definido pelo AS3AP. Quadro 2 - Especificação de atributos das tabelas definidas pelo benchmark AS3AP. Atributo. Tipo de dados. Tamanho. Key. Inteiro. 4 bytes. Int. Inteiro sem negativos. 4 bytes. Signed. Inteiro permitindo negativos. 4 bytes. Float. Ponto flutuante. 4 bytes. Doublé. Ponto flutuante. 8 bytes. Decimal. Decimal com precisão exata. 18.2 posições. Date. Data e hora. 8 bytes. Code. String de tamanho variável. 10 posições. Name. String de tamanho fixo. 20. Address. String de tamanho variável. 2 a 80 (20 em média). Fill. String de tamanho fixo. Conforme necessário. As quatro tabelas são uniques, hundred, tenpct e updates. Elas variam em relação à distribuição de dados de cada campo e uso de índices, e neste ponto há um conjunto mais rico de distribuições do que o Wisconsin. Para população dos dados sintéticos, são usadas distribuições estatísticas densas e esparsas, uniformes, normais, e zipf [41], que devem ser geradas pelo software DBGEN [42]. Foram definidos requisitos para o uso de três tipos de índice: clustered B-Tree, non-clustered B-Tree e hash. Para as tabelas uniques e hundred, são exigidos apenas dois índices, nos campos key e code. Para a tabela tenpct, devem ser criados nove índices de diferentes tipos, dois deles sobre o campo code. Para a tabela updates, devem ser criados 5 índices de diferentes tipos. Foi desenvolvida pela comunidade de código aberto uma implementação do AS3AP, o OSDB (Open Source Database Benchmark) [38]. 2.2.3. TPC-C Em 1993, a TPC publicou o TPC-C, tornando os resultados TPC-A e TPC-B obsoletos. Os resultados TPC-A, entretanto, ficaram válidos até dezembro de 1995.. 15.

(18) O TPC-C simula um ambiente OLTP multi-usuário, onde são executadas 5 transações que refletem as atividades principais de uma empresa atacadista. O benchmark explora consultas, transações curtas e concorrência. A execução das transações promove acesso não-uniforme aos dados, para não favorecer excessivamente o acesso seqüencial aos discos. O banco é composto por 9 tabelas. Oito delas têm o seu número de registros proporcionais ao número de warehouses (depósitos de mercadoria) definidas para a execução do benchmark. O número de usuários simulados é 10 vezes o número de warehouses. Dessa forma, é mantida uma proporção bastante clara entre o tamanho do banco de dados e a intensidade da carga de trabalho permitida para o SUT. O modelo lógico do banco de dados usado no benchmark é ilustrado na Figura 1. Por exemplo, se o número de registros na tabela warehouse for 10, a tabela district terá 100 registros; a tabela customer terá 300.000 registros; a tabela orders terá aproximadamente 300.000 registros. A tabela item é a única cuja cardinalidade independente do número de registros de warehouse. 10. Warehouse. District. W. W * 10 History. 100k. W * 30k+. 1+. Stock. Customer. W * 100k. W Item 100k. 3k. W * 30k. New-Order. 3+. W * 9k+. 0-1. Order-Line W * 300k+. 1+ Orders. 5-15. W * 30k+. Figura 1 - Modelo lógico do banco de dados usado no benchmark TPC-C [3].. Para exemplificar, um banco de dados com 115 warehouses teria os tamanhos de cada tabela e números de registros conforme mostra o Quadro 3. O tamanho deste banco de dados é de aproximadamente 12 GB, já incluindo todos os índices necessários para um melhor desempenho.. 16.

(19) Quadro 3 - Cardinalidade de banco de exemplo para o benchmark TPC-C com 115 warehouses.. Tabela. No. Registros. Tamanho. Warehouse. 115. 24 KB. District. 1.150. 184 KB. Customer. 3.450.000. 2.2 GB. Orders. 3.450.000. 221 MB. Order-line. 32.767.533. 3 GB. New-order. 1.035.000. 40 MB. History. 3.450.000. 290 MB. Stock. 11.500.000. 3.8 GB. Item. 100.000. 10.8 MB. Em um ambiente OLTP de um sistema atacadista, são bastante comuns transações curtas e de alta freqüência de execução em um ambiente multi-usuário. As transações do TPC-C são new-order (novos pedidos), payment (realização do pagamento de um novo pedido realizado anteriormente), delivery (entrega de um lote de pedidos), stock-level (consulta de nível de estoque) e order-status (consulta de situação de um pedido). A métrica de desempenho definida pelo TPC-C é tpmC (transações new-order executadas por minuto). A carga de trabalho do TPC-C é composta de 5 transações. Três delas são de escrita e leitura e duas são somente de leitura: new-order – (escrita e leitura) registra a entrada de um novo pedido. payment – (escrita e leitura) registra o pagamento de um pedido feito anteriormente pela transação new-order. delivery – (escrita e leitura) processa a entrega de um lote de 10 pedidos. Esta transação é assíncrona, e é executada como um job recorrente no servidor que processa 10 pedidos e pára. order-status – (somente leitura) retorna o status do último pedido de um cliente. stock-level - (somente leitura) retorna itens que têm nível de estoque abaixo de um limite específico. 17.

(20) A freqüência de execução das transações do TPC-C deve seguir o Quadro 43. As transações order-status, stock-level e delivery devem corresponder (cada), no mínimo, a 4% do total de transações executadas, totalizando pelo menos 12% do total de transações submetidas ao SUT. A transação payment, no mínimo a 43%. O restante das transações pode ser new-order. A métrica do benchmark corresponde ao número de transações new-order executadas por minuto. As outras quatro transações servem para gerar carga de trabalho adicional, mas não contribuem diretamente para a composição da métrica de desempenho do benchmark. Ou seja, quanto mais próximo de 45% do total de transações forem new-order, mais otimizado será o resultado.. Quadro 4 - Frequência de execução das transações do TPC-C. Transação. Freqüência de execução. Stock-level. 4% (mínimo). Order-status. 4% (mínimo). Delivery. 4% (mínimo). Payment. 43% (mínimo). New-order. 45% (máximo). A simulação de um usuário no TPC-C também precisa seguir um conjunto de regras. Devem ser simulados tempos dentro de um intervalo pré-definido para simular uma atividade próxima da realidade de um usuário comum. Os tempos simulam a digitação de dados pelo usuário, o intervalo de tempo que o usuário “pensa” antes de submeter a próxima transação, e o tempo de exibição do menu antes da escolha de uma transação. A Figura 2 ilustra os tempos envolvidos na simulação das atividades de um usuário.. 3. Ver cláusula 5.2.3 da especificação do TPC-C, listada no Apêndice A.. 18.

(21) 1 – Escolhe tipo da transação 2 – Tempo de resposta do menu (após exibição na tela). 3 – Tempo de espera (keying time). 4 – Tempo de processamento (após exibir dados na tela) 5 – Tempo de espera (think time). Figura 2 - Processo de simulação de um usuário no benchmark TPC-C. O TPC-C introduz exigências ACID, para garantir a consistência do SGBD. A auditoria precisa verificar se as propriedades ACID são mantidas corretamente pelo SGBD, juntamente com a alta disponibilidade do log do banco de dados e do subsistema de discos. Um fato que impulsionou a exigência obrigatória da auditoria pela TPC foi quando a empresa de consultoria Standish Group fez uma severa crítica à opção discrete transactions criada pela Oracle, alegando que esta opção não tinha relevância nos usos convencionais do SGBD, e foi criada com o único intuito de melhorar o desempenho do benchmark TPC-A. Em resposta, a TPC mudou a especificação do benchmark adicionando uma descrição para proibir benchmark specials, ou funcionalidades e/ou melhorias de desempenho criadas com o único intuito de melhorar o desempenho do benchmark. Atualmente, a definição de um benchmark special está na cláusula 0.2 da especificação do TPC-C4 [3]. O julgamento de um benchmark special é subjetivo, mas a especificação descreve critérios que pesam nessa avaliação. Como conseqüência, a Oracle removeu todos os seus resultados TPC-A até aquele momento. Entretanto, a Oracle continuou sendo membro da TPC e participando ativamente no seu trabalho. O episódio também serviu para que a TPC criasse um grupo de auditores certificados. A auditoria, que era um instrumento utilizado de forma opcional (embora recomendável) desde os tempos do DebitCredit, passou a ser obrigatória.. 4. A cláusula referida está listada no apêndice A.. 19.

(22) 2.2.4. TPC-E O TPC-E está em fase final de aprovação na TPC. Ele deve substituir o TPC-C como o benchmark OLTP padrão de indústria. Uma especificação preliminar encontrase disponível no site da TPC [5]. O TPC-E simula uma carga de trabalho OLTP gerada por uma corretora de ações [5]. O foco do benchmark é o SGBD central que executa transações relacionadas com as contas dos clientes da corretora. São definidos dois tipos de transação na carga de trabalho: B2B (Business-to-business) [43] e B2C (Business-to-consumer) [44]. No total, são definidas onze transações no TPC-E. O TPC-E define um ambiente bem mais complexo que o TPC-C. São definidas três entidades: mercado, corretora e cliente, com comportamentos individuais e peculiares a cada uma. A carga de trabalho se comporta como um sistema distribuído, onde cada entidade possui um comportamento paralelo às demais transações. As transações podem ser iniciadas pelo cliente, pela corretora ou disparada como conseqüência de um evento no mercado. Cada transação possui uma freqüência de execução pré-definida. A transação Trade-Result, disparada pelo mercado, produz a métrica primária de desempenho tpsE, em transações por segundo (em contraste com as transações por minuto do TPC-C). As demais transações compõem o restante da carga de trabalho. O TPC-E define 33 tabelas, bem mais do que as 9 tabelas definidas no TPC-C. As tabelas são divididas em 4 grandes grupos: há 11 tabelas de mercado, 9 de cliente, 9 da corretora e 4 de dimensões. A cobertura de tipos de dado é ainda mais abrangente do que a do TPC-C. A exigência do uso de constraints passa a ser mais rígida, principalmente chaves estrangeiras, que não eram aplicadas nos resultados TPC-C. Uma mudança importante do TPC-E em relação ao TPC-C é que não há mais requisitos obrigatórios de tempos de espera para os usuários que submetem a carga de trabalho. De fato, é razoável admitir que não seja necessário simular tempos de espera de usuários em um benchmark que visa esgotar os recursos do sistema sob avaliação. Uma carga de trabalho com mais usuários e tempos de espera maiores é bastante similar a uma carga de trabalho com menos usuários e tempos de espera menores ou nulos. Uma vantagem de definir tempos de espera no benchmark é impressionar a comunidade de usuários ao divulgar resultados com números artificialmente altos de usuários, dando uma impressão de um suporte a um maior número de usuários concorrente. Na verdade, o número de usuários que o sistema sob avaliação suporta é bastante relativo, depen-. 20.

(23) dendo do benchmark ao qual ele está submetido. Esta simples verdade pode facilmente passar despercebida em análises comparativas superficiais eventualmente feitas pela comunidade de usuários. Com o TPC-E, a TPC vai passar a fornecer uma parte do código do benchmark, ao contrário do que acontecia com o TPC-C. Um software chamado EGen será fornecido pela TPC junto com o TPC-E, e seu uso passa a ser obrigatório. O EGen cuida da população da base de dados e de uma parte do código das transações. Mesmo assim, uma parte do código das transações deve ser implementada pelos fabricantes. Em cada transação, a parte que deve ser implementada pelos fabricantes é chamada de frame. No corpo da execução de cada transação (implementado pelo EGen), são feitas chamadas a um ou mais frames. Nos frames, há espaço para os fabricantes introduzirem otimizações diversas, sempre obedecendo aos requisitos mínimos dos perfis das transações conforme definido na especificação. O motor de execução do benchmark ainda precisa ser produzido pelo fabricante, assim como os relatórios e gráficos exigidos pelo benchmark. O TPC-E não deverá substituir o TPC-C de imediato, mas possui características bastante atraentes para ganhar popularidade rapidamente. Uma das intenções do TPC-E é diminuir exigências de subsistema de I/O, o que deve tornar o benchmark mais fácil e financeiramente mais acessível. Mike Molloy, atual CEO da TPC, expôs a intenção de reduzir a exigência de quantidade de discos pela metade no TPC-E em relação ao TPCC [45]. Outro fato importante do TPC-E é que a TPC irá fornecer o EGen, o que simplifica o processo de implementação do benchmark. Não é necessário implementar todo o benchmark para uma plataforma, apenas os frames. As importantes exigências de auditoria ACID (Atomicity, Consistency, Isolation, Durability) foram mantidas no TPC-E. 2.2.5. Outros benchmarks A Neal Nelson & Associates [35] desenvolveu um benchmark para medir o desempenho de SGBD. Ele simula uma aplicação de funcionários e vagas de trabalho disponíveis em diversas empresas. Há outras ferramentas para medir o desempenho específico de elementos isolados, tais como o IOMeter (para medir desempenho de discos) [46] e SiSoft Sandra [47] (para medir o desempenho isolado do processador, subsistema de vídeo, memória, discos, entre outros). O resultado de muitas dessas ferramentas pode ser questionável, porque a carga de trabalho não necessariamente representa demandas realísticas. Outro 21.

(24) aspecto é a medição isolada de componentes, que pode ocultar importantes elementos da interação entre eles. Há outros benchmarks de domínios específicos, tais como o benchmark OO7 [48], para medir o desempenho de SGBD orientados a objeto, ou o Sequoia 2000 [49], para medir o desempenho de um SGBD com informações sobre dados geográficos e climáticos. O TEXTURE [50] exercita o processamento de texto no SGBD, forçando o uso de consultas com ranking e uso de junções. Em cada domínio, existe o argumento que benchmarks existentes não testam um conjunto de funcionalidades na proporção mais relevante para o domínio específico e, portanto, um benchmark específico de domínio é necessário. Algumas iniciativas de benchmark podem ser destacadas no meio acadêmico. Wisconsin [2] e AS3AP [4] foram os precursores dos benchmarks para SGBD. Dennis Shasha propõe o SpyTime [10], um benchmark para SGBD bi-temporais, onde o banco de dados armazena o histórico dos fatos e das mudanças nos registros ao longo do tempo. Este simples benchmark define uma única tabela com dados fictícios de observação da atividade de espiões em determinadas regiões. O benchmark define 10 consultas e computa o tempo de resposta. A métrica é a média geométrica dos tempos de resposta das 10 consultas executadas em seqüência, de forma mono-usuário. Uma interessante iniciativa dá um foco maior à razão custo/desempenho ao invés de focar apenas no desempenho. O PennySort [9] foi uma evolução do DatamarionSort e MinuteSort. No PennySort, o custo do sistema é depreciado ao longo de 3 anos e a métrica principal do benchmark é o tempo que o sistema consegue executar uma operação de sort por 1 centavo de dólar (um penny). Os autores propõem a evolução do PennySort em um Price/Performance sort, para melhor extensibilidade do benchmark (a definição de extensibilidade para o contexto deste trabalho é feita no capítulo 3). Um exemplo de benchmark neutro e aberto para SGBD é o PolePosition [51]. Ele mede o desempenho do SGDB para manipular objetos instanciados em Java. Apesar de não existir uma especificação documentada para o PolePosition, seu código em Java é aberto e disponível no SourceForge. A tecnologia de mapeamento objeto-relacional também faz parte da análise de desempenho. No PolePosition, os circuitos são uma representação dos testes que se deseja realizar. Esta abstração é feita através da implementação de uma interface de driver, com métodos (laps) que o circuito deve implementar. O método write implementa o algoritmo de população da base utilizado por cada circuito; o método delete retorna a base ao estado inicial; o método takeSeatIn é 22.

(25) responsável por criar a estrutura do banco de dados a ser avaliado, incluindo-se tabelas e índices. Diversos métodos executam as operações de avaliação desejadas, particulares a cada circuito. O PolePosition é um exemplo de benchmark neutro e analítico, que exibe o tempo de resposta para cada operação definida. Isso o torna menos popular, porque não define uma métrica única para caracterizar o desempenho global. Dessa forma, a comparação de produtos torna-se mais complexa e menos popular.. 2.3. Organizações de Benchmark Uma tendência na criação e evolução de benchmarks mais justos e bem projetados é a criação de organizações formadas pelas empresas interessadas nos resultados dos benchmarks. Nestas organizações, são formados grupos de trabalho compostos por integrantes de cada empresa para juntos trabalharem na confecção e aperfeiçoamento de benchmarks. Apesar de serem concorrentes, as empresas integrantes conseguem especificar benchmarks mais justos, já que dificilmente são introduzidas características de forma a favorecer injustamente o desempenho de um produto. Em geral, muitas especificações de benchmark procuram construir subconjuntos representativos de sistemas similares aos que são utilizados efetivamente no mundo comercial. O benchmark deve modelar ao mesmo tempo um sistema representativo das funcionalidades relevantes dos produtos avaliados, mas que também seja um subconjunto reduzido do sistema para formar um pequeno ambiente altamente regulado e controlado. Hoje, os resultados dos benchmarks produzidos por tais organizações são bastante respeitados, obtendo várias referências na mídia, tanto em anúncios de marketing das empresas-membro exaltando seus produtos [13;15;16], quanto em reportagens de revistas e jornais [14;17]. Nos últimos 20 anos, foram criadas pelo menos 5 organizações exclusivamente para a produção de benchmarks: TPC [18], SPEC [19], SPC [20], BAPCo [21] e EEMBC [22]. A TPC produz benchmarks voltados primariamente para SGBD. Há dois componentes primordiais que determinam o desempenho de um SGBD: I/O (leituras e escritas em disco) e CPU (processador). Neste trabalho, serão descritas duas organizações que produzem benchmarks padrão de mercado para estes dois segmentos. A SPEC ficou conhecida por produzir benchmarks para medir o desempenho de processadores, embora também tenha desenvolvido benchmarks com outros fins, como várias versões do jAppServer e do JBB, para Java. A SPC está focada em benchmarks para subsistemas de I/O (discos, SAN’s, entre outros). 23.

(26) Há também outras organizações de benchmark, que serão brevemente citadas. A BAPCo [21] produz o Sysmark 2004 [52], um benchmark de aplicação para medir o desempenho de desktops através de aplicações como clientes de e-mail, processadores de texto e planilha, navegadores (browsers), pequenos bancos de dados locais, manipuladores de imagem e construção de vídeos, dentre outras aplicações comuns a usuários de desktops. O Sysmark é bastante utilizado para comparar o desempenho de diferentes versões de Sistemas Operacionais Windows. A EEMBC produz benchmarks para software e hardware de sistemas embarcados. Os resultados produzidos pela EEMBC substituíram antigos resultados em Dhrystone [53] e mips [54] existentes anteriormente. 2.3.1. TPC – Transaction Performance Processing Council A TPC é uma organização que define benchmarks de SGBD e processamento de transações e fornece resultados confiáveis para a indústria [18;55]. Esta seção irá descrever o histórico da criação da TPC e detalhar um pouco do seu funcionamento e organização interna. No início dos anos 80, houve um grande interesse na caracterização do desempenho de sistemas OLTP, motivados pelo crescente automação de transações de negócio do cotidiano, de ATM (Automatic Teller Machine, ou caixas eletrônicos bancários) a postos de gasolina [35]. Surgiram então formas de mostrar que determinado sistema podia suportar a capacidade de transações esperada, muitas vezes sem divulgar os detalhes de como foram avaliados. Todos concordavam que formas tradicionais de medir desempenho, como Dhrystones [53] ou mips (million instructions per second) [54], não eram adequados para caracterizar o desempenho de sistemas OLTP, mas não havia um consenso de como sistemas OLTP deveriam ser avaliados. Mesmo assim, muitas divulgações de “tps” (transações por segundo) foram divulgadas, sendo nebulosa a forma de compará-los e com pouca ou nenhuma credibilidade pública. Jim Gray propôs o benchmark DebitCredit [39], que se tornou padrão de mercado [35], dando subsídio para fabricantes apresentarem números de desempenho alegando estar compatíveis com o “benchmark padrão da indústria”. Na verdade, o trabalho de Jim Gray não era detalhado o suficiente para permitir implementações não-ambíguas. Além disso, os fabricantes executavam variações do DebitCredit, que simplificavam o benchmark e tornavam os resultados artificialmente mais altos. Uma dessas variações foi a “TP1”, cujos resultados em tps (transações por segundo) eram bem mais altos do que na versão original do DebitCredit. Esses vários resultados não-padronizados mina24.

(27) ram a credibilidade do benchmark e tornaram os resultados incomparáveis. Como uma tentativa de dar mais credibilidade aos resultados de benchmark, se iniciou a prática de contratar um auditor para certificar os resultados de testes OLTP. Como resultado de trabalhos de auditoria, surgiram documentações detalhando como o benchmark foi realizado e configurações feitas no ambiente, similar ao Full Disclosure Report obrigatório para publicações da TPC e de diversas outras organizações de benchmark. Nos dias de hoje, qualquer resultado de benchmark da TPC precisa ter um relatório completo – o Full Disclosure Report, além de precisar ser aprovado pela auditoria antes que possa ser publicado. Tom Sawyer e Omri Serlin, envolvidos em esforços de auditoria de benchmarks DebitCredit, confeccionaram um documento de requisitos mínimos para compatibilidade com o DebitCredit [35]. Esse documento foi a munição para a criação de um órgão consensual para criar e por em prática padrões de medida de desempenho para OLTP. Assim, em agosto de 1988, oito empresas concordaram em se juntar ao então-formado Transaction Processing Performance Council (TPC). O primeiro benchmark produzido pela TPC foi o TPC-A (uma pequena variação do DebitCredit). Pouco tempo depois, a TPC produziu o TPC-B, uma variação do TP1. O trabalho na TPC é realizado através de teleconferências e reuniões bimestrais. As reuniões da TPC são eventos peculiares onde concorrentes sentam lado a lado para juntos alcançarem objetivos comuns e atingirem acordos sobre benchmarks. A TPC desde o início é formada pelos principais fabricantes mundiais de hardware, Sistemas Operacionais e SGBD. Os benchmarks produzidos pela TPC são abertos, auditados e todos os resultados podem ser reproduzidos através do relatório completo que acompanha a divulgação do mesmo. Dessa forma, a credibilidade dos resultados torna-se quase inquestionável. A criação de órgãos neutros para criação e manutenção de benchmarks tornou-se um hábito na indústria. No mesmo ano de criação da TPC, foi criada a SPEC (Standard Performance Evaluation Cooperative), que define um grande número de benchmarks, medindo desempenho de processadores (avaliando o processamento de números inteiros e de ponto flutuante separadamente), aplicações gráficas, servidores de aplicação, clientes Java, processamento paralelo, entre outros. Outras organizações foram criadas posteriormente, em moldes similares à TPC e SPEC: BAPCo (Business Application Performance Corporation) [21], SPC (Storage Performance Corporation) [19] e EEMBC [22] (Embedded Microprocessor Benchmark Consortium). 25.

(28) 2.3.1.1.. Benchmarks da TPC. A TPC mantém atualmente três frentes de trabalho concorrentes nos esforços de desenvolvimento de benchmarks – um OLTP, outro de suporte à decisão e um terceiro de aplicações Web. Para os benchmarks da TPC, em média, somente após um a dois anos é que um benchmark substituído por um mais moderno torna-se oficialmente obsoleto. O TPC-D foi o primeiro benchmark de suporte a decisão da TPC, e deu origem a outros dois benchmarks, o TPC-R e o TPC-H. O TPC-H é a especificação mais utilizada, e o TPC-R caiu em desuso. Já está sendo desenvolvido o TPC-DS, que será o sucessor do TPC-H. Recentemente, a TPC aprovou um rascunho preliminar do benchmark TPC-DS e disponibilizou para o público em geral no seu site [56]. Uma nova linha de benchmark foi desenvolvida para avaliar o desempenho de aplicações Web, mais particularmente de servidores e-Commerce. O primeiro benchmark da TPC nesta linha foi o TPC-W [6]. O sucessor do TPC-W, o TPC-App [8], já foi divulgado. Entretanto, há apenas um resultado TPC-App publicado atualmente [57]. Em outra frente de trabalho, a TPC iniciou com os benchmarks TPC-A e TPC-B, que são variações pequenas de um benchmark OLTP. Em 1993, o novo benchmark TPC-C trazia várias mudanças, uma carga de trabalho mais complexa e torna ambos TPC-A e TPC-B obsoletos. Atualmente, a TPC está desenvolvendo um novo benchmark OLTP, que será chamado de TPC-E [5;58]. O intuito é substituir o TPC-C com um benchmark mais adequado à realidade atual dos ambientes computacionais. O TPC-E simula um sistema do mercado de ações, com requisitos rigorosos de processamento de transações e segurança. No TPC-E, a taxa de usuários para cada tamanho de BD não é préfixada. Ao invés disso, o tamanho do BD deve ser proporcional ao número de processadores do servidor de banco de dados central. Além disso, o benchmark vai requerer um número bem menor de discos. Segundo Mike Molloy, CEO da TPC, o número de discos necessários deve reduzir pela metade [45]. Espera-se que a transição do TPC-C para o TPC-E encontre resistência, já que o TPC-C é bastante popular e difundido e está ativo desde 1993. Como uma versão preliminar da especificação já foi divulgada para o público [5], há indícios que esta iniciativa de mudança do TPC-C será bem-sucedida, ao contrário de iniciativas anteriores de mudanças estruturais significativas no TPC-C [59]. O número de resultados oficiais publicados indica a popularidade do benchmark. Atualmente, há aproximadamente 194 resultados TPC-C ativos contra 86 resultados. 26.

(29) TPC-H e apenas 1 resultado TPC-App. Além disso, é mais caro publicar resultados TPC-C do que TPC-H ou TPC-App. Portanto, fica evidente que os resultados TPC-C são os mais populares da TPC. Não é necessário adquirir uma licença da especificação do benchmark para executá-lo. As especificações estão disponíveis para download no site da TPC [18]. Entretanto, nem sempre é fornecida parte significativa do software necessário para a execução do benchmark; alguns acompanham parte do software necessário. Por exemplo, em relação ao TPC-C, não é fornecido nenhum software, embora haja uma definição detalhada de cada transação definida. Já o TPC-E terá uma parte do código fornecido pela TPC. De uma maneira geral, quanto mais abrangente for um benchmark em relação a plataformas distintas com particularidades de implementação, menor a chance de o código ser fornecido junto com a especificação do benchmark. Principalmente as empresas de SGBD têm interesse nas publicações TPC-C e, conseqüentemente, a maioria delas desenvolveu um software necessário para execução do TPC-C. Por exemplo, a Microsoft desenvolveu um kit que inclui software para o servidor SQL Server, o servidor Web, e um software chamado Benchcraft, que possui todas as funcionalidades necessárias para emular browsers, executar o benchmark e coletar as informações relevantes durante o teste para serem incluídas nos relatórios requeridos e fornecidas para a auditoria. O kit é proprietário, de código fechado e não pode ser utilizado com outro SGBD que não seja da Microsoft. A licença de uso do kit Benchcraft não é vendida, e só pode ser utilizada com autorização da Microsoft. Nem todos os fabricantes de SGBD implementaram o software necessário para a execução do TPC-C. Algumas iniciativas independentes para desenvolvimento de um kit similar foram iniciadas [60;61], mas não possuem todas as funcionalidades requeridas para viabilizar uma auditoria e publicação TPC-C. Mesmo assim, essas ferramentas são utilizadas para dar uma noção do desempenho, sem haver uma publicação oficial na TPC do resultado. Naturalmente, a TPC não endossa resultados de desempenho obtidos desta forma. Após a execução do benchmark, é obrigatória a realização da auditoria, através de um auditor certificado pela TPC. A auditoria verifica se a execução do benchmark foi realizada em conformidade com a especificação do benchmark e caso afirmativo produz uma carta de conformidade, que deve ser anexada ao relatório completo da publicação (Full Disclosure Report ou FDR) e enviado à TPC para divulgação oficial no seu site da Internet [18]. 27.

(30) 2.3.2. SPEC – Standard Performance Evaluation Corporation A SPEC foi fundada sob o nome Standard Performance Evaluation Cooperative, que depois mudou para Standard Performance Evaluation Corporation. Foi fundada em outubro de 1988, mesmo ano da fundação da TPC, pelas empresas Apollo, HP, MIPS Computer Systems e Sun Corporation, em conjunto com E. E. Times [62]. Assim como a TPC, a SPEC é composta pelos principais fabricantes de hardware e software de infra-estrutura, e possui também 28 universidades como membros associados. Nesse ponto, há uma sensível diferença entre a SPEC e a TPC, porque a TPC apenas possui uma instituição acadêmica como membro associado, o Centro de Informática da UFPE. Tanto na TPC quanto na SPEC, membros associados podem participar do desenvolvimento e aperfeiçoamento dos benchmarks. Propostas de mudanças ao benchmark devem ser encaminhadas para aprovação através de voto, e a única restrição para membros associados é que não podem votar. O objetivo da SPEC é bastante similar ao da TPC – “munir a indústria com “fitas métricas” realísticas para medir o desempenho de sistemas de computação avançados” e educar os consumidores a respeito do desempenho dos produtos dos fabricantes. A SPEC cria, mantém, distribui e endossa um conjunto de programas orientado a aplicações para serem utilizados como benchmarks. Um dos benchmarks mais conhecidos da SPEC é o que mede desempenho de CPU. De fato, havia uma forte motivação para um benchmark de CPU melhor do que MIPS (milhões de instruções por segundo) [54] e MFLOPS [63] (milhões de operações de ponto-flutuante por segundo), que eram dominantes até nas décadas de 60 e 70. Medidas de instruções de máquina como estas geram comparações irreais entre as plataformas CISC e RISC. Apesar de compartilharem a mesma missão, a abordagem dos benchmarks da SPEC é um pouco diferente da TPC, porque encoraja a análise de um benchmark analítico ao invés de sintético. Entretanto, como há muita pressão dos consumidores e da área de marketing, a SPEC mudou seus benchmarks para gerarem poucas métricas resumidas, mas continua desencorajando o uso indiscriminado da mesma, porque pode propiciar conclusões inexatas sobre a comparação do desempenho. A SPEC tem várias linhas no desenvolvimento de benchmarks: CPU, aplicações gráficas, arquiteturas distribuídas, aplicações industriais e paralelas, servidores de aplicação Java, máquinas virtuais Java em estações de trabalho, servidores Web, servidores. 28.

(31) de correio e sistema de arquivo em rede (NFS). Não há um benchmark OLTP específico, embora muitos benchmarks definam aplicações com algumas características OLTP, como o benchmark SPECjAppServer, que mede o desempenho de servidores de aplicação Java. O SPECjAppServer tem recebido várias versões nos últimos anos: o SPECjApp2001, SPECjApp2002 e mais recentemente o SPECjApp2004. O motivo é que o benchmark é aperfeiçoado para melhor avaliar cada versão do J2EE. O SPECjApp2004, por exemplo, foi adaptado para se adequar ao J2EE versão 1.3 [64].. 2.3.2.1.. Benchmarks da SPEC. Nesta seção, serão mencionados alguns benchmarks mais recentes definidos pela SPEC. Há também benchmarks mais antigos, com o mesmo objetivo dos que estão sendo mencionados, que tendem a ser substituídos pelos mais novos. Os benchmarks mais antigos não serão mencionados nesta seção. O CPU2000 [11], atualmente na versão 1.3, é a versão mais atual do benchmark para medir o desempenho de processadores. Ele fornece uma métrica comparativa do desempenho de cargas de trabalho com intenso uso de CPU em qualquer plataforma. É medido o desempenho do processador, memória e compilador no ambiente testado. O CPU2000 é dividido em dois componentes: (a) CINT2000, para medir o desempenho de operações com números inteiros, e (b) CFP2000, que mede o desempenho de números flutuantes. A SPEC provê outros benchmarks para medir o desempenho de aplicações gráficas. O SPECapc for 3ds max [65] (atualmente na versão 7) gera uma carga de trabalho típica de um usuário de aplicações gráficas, incluindo funções gráficas como modelagem de wireframe, sombreamento, texturas, iluminação, mistura, cinemática invertida, criação e manipulação de objetos, edição, criação de cenas, investigação de partículas, animação e renderização. O benchmark roda tanto implementações OpenGL e DX do 3ds max 7, e testa todos os componentes envolvidos na execução da aplicação. SPECapc for Maya 6.5 [66] é um benchmark similar, onde cada um dos quatro modelos tridimensionais (um lobisomem, uma mão humana, um inseto e uma lula) são renderizados e visualizados nos cinco diferentes modos utilizados no Maya 6.5. Os benchmarks de desempenho de aplicações gráficas utilizam um ambiente de referência, e os resultados devem ser referenciados a este ambiente. SPECapc for Maya 6.5 consiste de 30 testes individuais, 27 dos quais são executados 3 vezes. A nota final é baseada 70% em gráficos, 20% em desempenho de CPU e 10% em I/O. A SPEC ainda define outros ben29.

(32) chmarks para aplicações gráficas [67]: SPECviewperf 9 , SPECapc for Pro/ENGINEER Wildfire 2.0, SPECapc for Solid Edge V14, SPECapc for SolidWorks 2005 e SPECapc for UGS NX 3. A SPEC também define benchmarks baseados em Computação de Alto Desempenho (HPC – High Performance Computing) [67]: HPC2002, MPI2006 e OMP2001. A SPEC define outro benchmark para medir o desempenho de servidores de aplicação Java: O SPECjAppServer2004 [68]. Ele é definido em múltiplas camadas, e tem o intuito de medir o desempenho de servidores baseados na tecnologia Java 2 Enterprise Edition (J2EE). O benchmark exercita todas as tecnologias primárias implementadas por servidores de aplicação compatíveis, tais como o container Web, incluindo servlets e páginas JSP, o container EJB (Enterprise Java Beans) e sua persistência gerenciada, JMS e Beans ativados por mensagens, gerenciamento de transações e conectividade com SGBD. O SPECjbb2005 [69] é outro benchmark, que mede o desempenho da máquina virtual Java no servidor, através da simulação de um sistema de três camadas, com ênfase na camada intermediária. O benchmark exercita as implementações da Máquina Virtual Java (JVM – Java Virtual Machine), compilador JIT (Just-in-time), garbage collection, threads e alguns aspectos do sistema operacional. Ele também mede o desempenho da CPU, caches, hierarquia de memória e a escalonabilidade de processadores de memória compartilhada (SMP – Shared Memory Processors). A SPEC define também benchmarks para servidores de correio eletrônico, SPEC MAIL2001 [70] e SPECimap [71]. O SPEC MAIL2001 mede a habilidade de um sistema de se portar como um servidor de correio eletrônico respondendo a requisições, baseados nos protocolos padrões de Internet SMTP e POP3. O benchmark caracteriza vazão e tempo de resposta de um sistema servidor de correio sob avaliação com conexões de rede realísticas, armazenamento em disco, e cargas de trabalho de clientes, simulando aproximadamente a carga gerada por 10.000 a 1.000.000 usuários. SPECimap ainda está em desenvolvimento e aguarda sugestões. A intenção é medir o desempenho de servidores de correio eletrônico que utilizam os protocolos padrões de Internet IMAP4 e SMTP. O SFS 3.0 [72] é outro benchmark definido pela SPEC, que mede o tempo de resposta e vazão de servidores de arquivo NFS (Network File System). O SPEC 3.0 foi definido em 1997 para resolver problemas encontrados no SFS 2.0. O SFS 3.0 inclui uma melhor validação de servidores e clientes, requisitos reduzidos de memória do cliente, portabilidade para Linux e FreeBSD, dentre outros recursos. 30.