Os benchmarks são uma das atividades que os administradores de banco de dados executam. Você os executa para ver como seu hardware se comporta, você os executa para ver como seu aplicativo e banco de dados funcionam juntos sob pressão. Você os executa em muitas situações diferentes. Vamos falar um pouco sobre eles, quais são os desafios que você vai enfrentar, quais são os problemas que você deve evitar.
Tipos de benchmarks
Cada benchmark é diferente. Eles servem a propósitos diferentes e isso deve ser levado em consideração quando você planeja executar um. Em geral, você pode definir dois tipos principais de benchmark:benchmark sintético e, vamos chamá-lo, um benchmark do “mundo real”.
Os benchmarks sintéticos geralmente são ferramentas que simulam algum tipo de carga de trabalho. Pode ser uma carga de trabalho OLTP como no caso do Sysbench, pode ser algum benchmark “padrão” como em TPC-C ou TPC-H. Normalmente, a ideia é que esse benchmark simule algum tipo de carga de trabalho e pode ser útil se sua carga de trabalho do mundo real seguir o mesmo padrão. Ele também pode ser usado para determinar como sua combinação de configuração de hardware e banco de dados funciona em conjunto em um determinado tipo de carga de trabalho. Os prós dos benchmarks sintéticos são bastante claros. Você pode executá-los em qualquer lugar, eles não dependem de alguma configuração específica ou design de esquema. Bem, eles fazem, mas eles vêm com ferramentas para configurar tudo do servidor de banco de dados vazio. A principal desvantagem é que esta não é a sua carga de trabalho. Se você for executar testes OLTP usando o Sysbench, lembre-se de que seu aplicativo nunca será o Sysbench. Ele também pode executar a carga de trabalho OLTP, mas a combinação de consultas será diferente. Nunca, sob nenhuma circunstância, o benchmark sintético lhe dirá exatamente como seu aplicativo se comportará em uma determinada combinação de hardware/configuração.
No outro extremo do espectro, temos o que chamamos de benchmarks do “mundo real”. O que queremos dizer com isso é um benchmark que usa um conjunto de dados e consultas relacionadas ao seu aplicativo. Nem sempre tem um conjunto de dados completo e uma combinação completa de consultas. Você pode querer se concentrar em algumas partes do seu aplicativo, mas a ideia principal por trás disso é que você deseja entender as interações exatas entre o aplicativo, o hardware e a configuração do banco de dados, em geral ou em algum aspecto específico.
Como mencionamos acima, temos dois tipos principais e diferentes de benchmarks, mas, ainda assim, eles têm algumas coisas comuns que você deve considerar ao tentar executar os benchmarks.
-
Decida o que você quer testar
Em primeiro lugar, o benchmarking para executar benchmarks é inútil. Tem que ser projetado para realmente realizar algo. O que você quer obter com a execução do benchmark? Deseja ajustar as consultas? Deseja ajustar a configuração? Você quer avaliar a escalabilidade da sua pilha? Você quer preparar sua pilha para uma carga maior? Você quer fazer um ajuste genérico de configuração para um novo projeto? Deseja determinar as melhores configurações para o seu hardware? Esses são exemplos de objetivos que você pode querer alcançar. Cada um deles exigirá uma abordagem diferente e uma configuração de benchmark diferente.
-
Faça uma alteração de cada vez
O que quer que você esteja testando e ajustando, é de extrema importância que você faça apenas uma alteração de configuração por vez. Isso é realmente crítico. O benchmark destina-se a dar uma ideia sobre o desempenho. Consultas por segundo, latência, percentil 99, tudo isso informa o quão rápido você pode executar as consultas e quão estável e previsível é a carga de trabalho. É fácil saber se a mudança que você fez na configuração, hardware ou mix de consultas muda alguma coisa:as métricas do benchmark parecerão diferentes. O problema é que, se você fizer algumas alterações ao mesmo tempo, não há como saber qual delas é responsável pelo resultado geral. Pode ir ainda mais longe do que isso. Digamos que você alterou dois valores na configuração do banco de dados. Valor A e B. A melhoria geral é de 20%, o que é muito bom para apenas uma mudança de configuração. Sob o capô, porém, a mudança para o valor A trouxe uma melhoria de 30%, enquanto a mudança adicional para o valor B o colocou de volta em 20%. Com várias alterações ao mesmo tempo, você só pode observar seu impacto comum, essa não é a maneira de determinar adequadamente o resultado de cada alteração feita. Claro, isso aumenta significativamente o tempo que você gastará executando o benchmark, mas é assim que é.
-
Faça várias execuções de benchmark
Os computadores são sistemas complexos por si só. Eles têm vários componentes que interagem entre si:memória, CPU, disco, rede. Então vamos adicionar a essa virtualização, a conteinerização. Em seguida, software - sistema operacional, aplicativo, banco de dados. Camada sobre camada sobre camada sobre camada de elementos que interagem de alguma forma. Não é fácil prever seu comportamento. Bem, você pode dizer que é quase impossível prever com precisão o comportamento de sistemas tão complexos. Esta é a razão pela qual executar uma execução de benchmark não é suficiente para tirar as conclusões. E se, sem saber para você, algum elemento, totalmente alheio ao que você quer testar, impactar no desempenho geral? Carga alta em outra VM localizada no mesmo host. Algum outro servidor está transmitindo backup pela rede. Isso pode afetar temporariamente o desempenho e distorcer os resultados do benchmark. Se você executar apenas uma execução de benchmark, acabará com resultados incorretos. É por isso que a melhor prática é executar várias passagens de um benchmark e depois remover o mais lento e o mais rápido, calculando a média dos outros.
-
Uma imagem vale mais que mil palavras
Bem, esta é uma descrição muito precisa de benchmarking. Se possível, sempre gere gráficos. Idealmente, acompanhe as métricas durante o benchmark com a maior frequência possível. Um segundo de granularidade deve ser suficiente para a maioria dos casos. Para evitar escrever milhares de palavras, vamos incluir este exemplo. O que você acha que é mais útil? Este conjunto de saídas de referência que representam QPS médio para cada uma das 10 passagens, cada passagem levando 600 segundos
11650,52
11237,97
11550.16
11247.08
11177,78
11163,76
11131,47
11235.06
11235,59
11277,25
Ou este gráfico:
O QPS médio é de 11k, mas a realidade é que o desempenho está em todo o place, incluindo quedas para 0 consultas executadas em um segundo, e é definitivamente algo que você deseja trabalhar e melhorar nos sistemas de produção.
-
Consultas por segundo não são a métrica mais importante
Você pode pensar que a consulta por segundo é o santo graal do desempenho, pois representa quantas consultas um banco de dados pode executar em um segundo. A verdade é que não é a métrica mais importante, especialmente se estivermos falando de saída média de um benchmark. QPS representa a taxa de transferência, mas ignora a latência. Você pode tentar enviar um grande volume de consultas, mas acaba esperando que elas retornem resultados. Isso não é o que os usuários esperam do aplicativo. Os usuários esperam um desempenho estável. Não precisa ser muito rápido, mas quando alguma ação leva um segundo para ser concluída, tendemos a esperar que essa ação leve sempre 1 segundo. Se, por algum motivo, começar a demorar mais, os humanos tendem a ficar ansiosos. Esta é a principal razão pela qual tendemos a preferir a latência, especialmente seu P99 (99º percentil) como uma métrica mais confiável. A latência nos diz quanto tempo o aplicativo teve que esperar pelo resultado do banco de dados. P99 nos diz latência que 99% das consultas têm menor que. Digamos que temos um P99 de 100ms, isso significa que 99% das consultas retornam resultados não mais lentos que 100ms. Se observarmos baixa latência do P99, significa que quase todas as consultas estão retornando rapidamente e com desempenho estável e previsível. Isso é algo que nossos usuários querem ver.
-
Entenda o que está acontecendo antes de tirar conclusões
Último ponto que temos neste pequeno blog, mas diríamos que é o mais importante. Você verá diferentes resultados e comportamentos estranhos e inesperados durante os benchmarks. Pior ainda, você pode ver resultados bastante padrão, repetitivos, mas ainda falhos. A maioria deles pode ser rastreada para o comportamento do banco de dados ou hardware. Isso é realmente crucial - antes de tomar o resultado como garantido, você deve ser capaz de explicar o comportamento e descrever o que aconteceu. Sabemos que não é fácil e sabemos que realmente requer conhecimento específico do banco de dados, especialmente conhecimento relacionado aos internos do banco de dados. Sabemos que no mundo real as pessoas normalmente não se preocupam com isso, elas só querem obter alguns resultados. O problema é que, especialmente nos casos em que você está tentando melhorar o desempenho por meio de configurações ou ajustes de hardware, entender o que aconteceu nos bastidores permite que você escolha a maneira correta de prosseguir com o ajuste. Também permite saber se o benchmark executado pode ter algum sentido. Estamos realmente testando o elemento correto? Um exemplo seria um teste executado na rede (porque você não gostaria de usar núcleos de CPU locais do nó do banco de dados para a ferramenta de benchmark). É bem provável que a própria rede e a carga da CPU do softirq sejam o fator limitante, muito antes de você atingir gargalos “esperados”, como a saturação da CPU. Se você não estiver ciente de seu ambiente e de seu comportamento, medirá o desempenho de sua rede para transferir grandes volumes de dados, não o desempenho da CPU.
Como você pode ver, benchmarking não é a coisa mais fácil de fazer, você tem que ter um nível de consciência do que está acontecendo, você deve ter um plano adequado para o que você vai fazer e o que você quer testar? Na próxima parte deste blog, vamos passar por alguns dos casos de teste do mundo real. O que pode dar errado, quais problemas encontraremos e como lidar com eles.
