Quando comparar o desempenho, defina o que espera aprender com o teste antes de o iniciar. Por exemplo:
- Qual é o débito máximo que o sistema pode alcançar?
- Quanto tempo demora uma consulta ou uma carga de trabalho específica?
- Como é que o desempenho muda à medida que a quantidade de dados aumenta?
- Como se compara o desempenho de dois sistemas diferentes?
- Em quanto tempo o motor de colunas reduz o tempo de resposta do desempenho das minhas consultas?
- Que carga pode uma base de dados processar antes de considerar a atualização para uma máquina mais potente?
Compreender os objetivos do seu estudo de desempenho indica que teste de referência executa, que ambiente é necessário e que métricas tem de recolher.
Repetibilidade
Para tirar conclusões dos testes de desempenho, os resultados dos testes têm de ser repetíveis. Se os resultados do teste tiverem uma grande variação, é difícil avaliar o impacto das alterações feitas na aplicação ou na configuração do sistema. A execução de testes várias vezes ou durante períodos mais longos para fornecer mais dados pode ajudar a reduzir o valor da variação.
Idealmente, os testes de desempenho devem ser executados em sistemas isolados de outros sistemas. A execução num ambiente em que os sistemas externos podem afetar o desempenho da sua aplicação pode levar a conclusões incorretas. Normalmente, o isolamento total não é possível quando a execução é feita num ambiente de nuvem multi-inquilino, pelo que deve esperar uma maior variabilidade nos resultados
Parte da repetibilidade consiste em garantir que a carga de trabalho de teste permanece a mesma entre execuções. Alguma aleatoriedade na entrada de um teste é aceitável, desde que não cause um comportamento da aplicação significativamente diferente. Se a entrada do cliente gerada aleatoriamente alterar a combinação de leituras e escritas de execução para execução, o desempenho varia significativamente.
Tamanho da base de dados, colocação em cache e padrões de E/S
Certifique-se de que a quantidade de dados com que está a testar é representativa da sua aplicação. A execução de testes com uma pequena quantidade de dados quando tem centenas de gigabytes ou terabytes de dados provavelmente não dá uma representação verdadeira do desempenho da sua aplicação. O tamanho do conjunto de dados também influencia as escolhas feitas pelo otimizador de consultas. As consultas em tabelas de teste pequenas podem usar análises de tabelas que têm um desempenho fraco em escalas maiores, e não vai identificar os índices em falta nesta configuração.
Esforce-se por replicar os padrões de E/S da sua aplicação. A proporção de leituras para escritas é importante para o perfil de desempenho da sua aplicação.
Duração da referência
Num sistema complexo, existem muitas informações de estado que são mantidas à medida que o sistema é executado: são estabelecidas ligações à base de dados, as caches são preenchidas e são gerados processos e threads. No início de um teste de desempenho, a inicialização destes componentes pode ocupar recursos do sistema e afetar negativamente o desempenho medido se o tempo de execução da carga de trabalho for demasiado curto.
Recomendamos que execute testes de desempenho durante, pelo menos, 20 minutos para minimizar os efeitos do aquecimento do sistema. Meça o desempenho durante um estado estável após o arranque e durante tempo suficiente para garantir que todos os aspetos das operações da base de dados estão incluídos. Por exemplo, os pontos de verificação da base de dados são uma funcionalidade crítica dos sistemas de base de dados e podem ter um impacto significativo no desempenho. A execução de um teste de referência curto que é concluído antes do intervalo do ponto de verificação oculta este fator importante no comportamento da sua aplicação.
Testes metódicos
Quando ajustar o desempenho, altere apenas uma variável de cada vez. Se alterar várias variáveis entre execuções, não vai poder isolar a variável que melhorou o desempenho. Na verdade, várias alterações podem compensar-se mutuamente, pelo que não vê a vantagem de uma alteração adequada. Se o servidor da base de dados estiver sobreutilizado, experimente mudar para uma máquina com mais vCPUs, mantendo a carga constante. Se o servidor de base de dados estiver subutilizado, experimente aumentar a carga mantendo a configuração da CPU constante.
Topologia e latências da rede
A topologia de rede do seu sistema pode afetar os resultados do teste de desempenho. A latência entre zonas difere. Ao fazer testes de desempenho, certificar-se de que o cliente e o cluster da base de dados estão na mesma zona minimiza a latência da rede e produz o melhor desempenho, especialmente para aplicações com elevado débito, transações curtas, uma vez que a latência da rede pode ser um componente importante do tempo de resposta geral da transação.
Quando comparar o desempenho de dois sistemas diferentes, certifique-se de que a topologia de rede é a mesma para ambos os sistemas. Tenha em atenção que a variabilidade da latência da rede não pode ser completamente eliminada. Mesmo dentro da mesma zona, podem existir diferenças na latência devido às topologias de rede subjacentes.
Ao implementar a sua aplicação, pode querer compreender melhor o impacto das latências entre zonas, considerando uma aplicação Web típica de elevado volume. A aplicação tem um equilibrador de carga que envia pedidos para vários servidores Web implementados em várias zonas para elevada disponibilidade. As latências podem diferir consoante o servidor Web que processa um pedido devido a diferenças de latência entre zonas.
A figura seguinte mostra a arquitetura típica de uma aplicação Web que usa o AlloyDB Omni. Os pedidos do cliente são processados por um equilibrador de carga, que encaminha cada pedido para um servidor Web entre muitos. Todos os servidores Web estão ligados ao AlloyDB Omni. Alguns servidores estão numa zona diferente daquela onde o AlloyDB Omni está a ser executado e vão encontrar latências mais elevadas ao fazer pedidos à base de dados.
Monitorização de recursos
Para otimizar o desempenho do sistema de base de dados, tem de monitorizar as utilizações de recursos do sistema de base de dados e dos sistemas de cliente que usam o sistema de base de dados. Ao monitorizar ambos os sistemas, pode garantir que os sistemas cliente estão a fornecer carga de trabalho suficiente para obter medições significativas no sistema de base de dados. A monitorização da utilização de recursos do sistema que está a testar é fundamental. A monitorização da utilização de recursos dos sistemas cliente que está a usar para gerar a carga de trabalho é igualmente importante. Por exemplo, se quiser determinar o número máximo de clientes que o seu sistema de base de dados pode suportar antes de ficar sem recursos de CPU, precisa de sistemas de clientes suficientes para gerar a carga de trabalho necessária para usar todos os recursos de CPU no sistema de base de dados. Não vai conseguir forçar o sistema de base de dados o suficiente se os computadores cliente que geram carga não tiverem CPUs suficientes.
Testes de escalabilidade
Os testes de escalabilidade são outro aspeto dos testes de desempenho. A escalabilidade refere-se à forma como as métricas de desempenho mudam à medida que uma característica de uma carga de trabalho varia. Alguns exemplos de estudos de escalabilidade incluem:
- Como é que um aumento no número de pedidos simultâneos altera o débito e os tempos de resposta?
- Como é que um aumento no tamanho da base de dados altera o débito e os tempos de resposta?
Os testes de escalabilidade consistem em várias execuções de uma carga de trabalho em que uma única dimensão varia entre as execuções e uma ou mais métricas são recolhidas e representadas graficamente. Este tipo de teste informa as decisões sobre os gargalos existentes no sistema, a quantidade de carga que o sistema pode processar com uma configuração específica, a carga máxima que um sistema pode suportar e o comportamento do sistema quando a carga aumenta para além desses níveis.
Considerações sobre o tamanho da máquina
O AlloyDB Omni introduz muitas funcionalidades novas no Postgres para melhorar a fiabilidade e a disponibilidade da base de dados. A monitorização necessária para o fazer usa recursos na máquina que executa o AlloyDB Omni. Em tamanhos de máquinas muito pequenos, existem recursos de memória e CPU limitados desde o início. Por isso, para testes de referência, recomendamos que use tamanhos de máquinas com, pelo menos, quatro CPUs virtuais.