Sistemas OLTP são caracterizados por transações muito breves, mas muito freqüentes, que possuem poucas ou nenhumas operações de agregação e que envolvem pequenos grupos de linhas. Exemplos clássicos de OLTP são sistemas financeiros e de vendas no varejo.
A natureza dos ambientes OLTP é predominantemente de uso interativo com tempo de
resposta curto, que envolvam transações pequenas, mas de alta concorrência. Sistemas OLTP requerem tempos de resposta curtos para que os usuários possam permanecer produtivos. Devido à grande quantidade de usuários, curtos tempos de resposta, e as transações de pequeno porte, a simultaneidade em ambientes OLTP é muito alta.
Para realizar este experimento, foram feitas algumas tentativas de utilizar as ben-chmarks TPC-E [Council, 2010b] e/ou TPC-C [Council, 2010a], que são as cargas de trabalho OLTP com uma mistura de operações de somente leitura e atualização inten-sivas. O TPC-E modela a atividade de uma empresa corretora de valores que precisa gerenciar contas de clientes, executar ordens de compra e venda, e ser responsável pela interações dos clientes com os mercados financeiros. Já o TPC-C, simula o ambiente de shopping on-line, no qual os usuários executam transações de compra, entrada e entrega de pedidos, registro de pagamentos e acompanhamento do nível de estoque.
Infelizmente, as implementações destasbenchmarks não se adéquam ao ambiente e/ou sistema. Por exemplo, a carga de trabalho do TCP-E necessita de suporte a chave es-trangeira, uma funcionalidade que, por enquanto, não é contemplada neste trabalho. O TPC-C, por outro lado, não se adéqua ao ambiente de experimentos devido ao grande volume de dados necessário para executar a versão mais simples dabenchmark. Com um fator de escala 1, o TPC-C gera uma carga de dados em torno de 250 MB de dados, o que acaba resultando em uma carga total de 1000 MB por servidor em razão do fator de replicação. Devido a estes problemas, a solução encontrada foi utilizar uma benchmark alternativa chamada SysBench [MySQL AB, 2010a].
6.3.1 SysBench
O SysBench é uma coleção de programas (módulos) de benchmark destinados a avaliar o desempenho de cargas de trabalho relacionadas a OLTP. Os módulos existentes permitem avaliar diversos parâmetros de um sistema operacional (escalonador, sistema de arquivo, etc.), bem como o desempenho de um servidor de banco de dados. A arquitetura do Sys-Bensh é relativamente simples, sendo basicamente composta por dois módulos de função:
controlador e cliente. Os clientes são responsáveis pela criação das requisições especifica-das pelo usuário, enquanto que o controlador controla o início e o fim da benchmark. Os clientes são implementados usando threads para executar as requisições e se comunicam com um servidor MySQL usandosockets.
No módulo OLTP destinado a avaliar o desempenho de bancos de dados, as requisições podem ser de três tipos: transacional complexa, transacional simples e não-transacional.
O tipo transacional complexo inclui, em um contexto transacional, diversos tipos de con-sultas (de igualdade, abrangência, etc.), atualizações, inserções e exclusões. As requisições do tipo transacional simples e não-transacional contem um subconjunto da transacional complexa. Uma requisição transacional complexa é composta de 21 operações, sendo que a última operação é uma confirmação (commit) da transação iniciada para executar a requisição.
Para qualquer um dos tipos de requisição, o SysBench utiliza uma tabela de tamanho predeterminado. Esta tabela é composta por quatro colunas, sendo que as duas primeiras são do tipo inteiro e as restantes são do tipo seqüência de caracteres de comprimento fixo. A primeira coluna faz parte da chave primária da tabela. As threads cliente exe-cutam transações sobre esta tabela, sendo que cada transação pode conter uma série de comandos, de acordo com o tipo de requisição especificado pelo usuário. A lista completa dos tipos de requisição, bem como o esquema detalhado da tabela, estão disponíveis em [MySQL AB, 2010b].
6.3.2 Experimento
O tipo de requisição selecionada é a transacional complexa. Leitura e escrita são permi-tidas em uma única transação, sendo que 66% das operações da transação são de leitura, enquanto que 23% são de escrita. Todas as transações inserem, excluem, atualizam e selecionam na tabela única durante um período de 300 segundos. Apesar do intervalo de medição ser baixo, provas por amostragem com intervalos de duração de até 20 minutos não demonstraram diferenças relevantes. A fim de obter resultados estáveis, é realizado um aquecimento rápido antes de cada rodada. O tamanho da tabela é de 100 mil linhas.
A DHT é espalhada por quatro servidores, sendo que em um deles é executado o SysBench e o banco de dados MySQL. Os testes foram executados variando o número de clientes (threads) que acessam o banco de dados, de 1 a 128 clientes simultâneos, com incrementos de 16. A medida básica de desempenho é a taxa de transações durante o período de tempo supracitado. A escalabilidade é medida pela variação da taxa de transações quando da variação do número de clientes. Também é coletado o número total de operações de leitura e escrita e os tempos de execução mínimo, médio e máximo de
todas as requisições completadas durante uma rodada.
Os resultados do experimento são apresentados na tabela Tabela 6.3 e mostram o nú-mero máximo de transações por segundo que o sistema suporta, dependendo do núnú-mero de clientes (primeira coluna). Para cada rodada específica, a tabela também mostra os números totais, incluindo a taxa por segundo, das operações de leitura e escrita executa-das, os tempos de execução em milissegundos, e, por último, o percentil 95 dos tempos de execução. A Figura 6.1 apresenta a escalabilidade considerando os valores de TPS quando da variação do número de clientes.
Thrs. TPS Leitura Escrita L.E./s Min. Méd. Máx. 95%
1 213.06 894852 319590 4048.11 3.22 4.69 52.57 9.96 2 380.50 1598100 570750 7229.47 3.85 5.25 51.14 6.13 4 537.56 2257780 806350 10213.61 4.87 7.43 71.31 9.34 8 600.25 2521246 900437 11404.88 3.75 13.32 1817.00 17.88 16 595.47 2501100 893250 11314.02 10.42 26.86 306.18 37.97 32 560.34 2353652 840583 10646.58 20.68 57.09 1830.21 79.54 64 506.88 2129442 760497 9631.15 4.15 126.24 1960.06 159.19 128 76.09 320040 114297 1445.71 446.70 1681.76 11633.69 1935.99
Tabela 6.3: SysBench: OLTP transacional complexo.
0 100 200 300 400 500 600 700
0 20 40 60 80 100 120 140
Transações por segundo (TPS)
Threads
SysBench OLTP
Figura 6.1: Escalabilidade segundo o número de clientes.
6.3.3 Análise
Os resultados do experimento mostram que um número alto de clientes pode impactar negativamente a taxa de transações e os tempos de resposta do sistema. Observando os dados da tabela, é perceptível uma queda acentuada do desempenho após 64 clientes simultâneos. A 128 clientes, o tempo de espera por uma transação dura em média 1.9 segundos, podendo chegar até a 11 segundos. Essa queda acentuada pode ser explicada pelo fraco poder computacional dos servidores do ambiente, que contam com apenas dois cores de processamento. Essa competição por recursos (tempo de CPU) faz com que surjam problemas de bloqueio, o que acaba prejudicando demasiadamente o desempenho do sistema. Este comportamento também pode explicar o pico de tempo máximo com 8 clientes. Enfim, nesses casos se faz necessário limitar o número máximo de clientes simultâneos.
Ademais, é possível afirmar que o sistema é capaz de sustentar uma taxa estável de transações até para 64 clientes simultâneos, se desconsiderado requisitos de tempo de resposta. O ponto ideal entre taxa de transações e tempo de resposta está entre 4 e 8 clientes simultâneos. De 8 a 64 clientes as taxas de operações são similares, mas ocorre acentuada degradação dos tempos de execução.