Ao comparar a performance, defina o que você espera aprender com o teste antes de começar. Exemplo:
- Qual é a capacidade máxima de processamento que o sistema pode alcançar?
- Quanto tempo leva uma consulta ou carga de trabalho específica?
- Como o desempenho muda conforme a quantidade de dados aumenta?
- Como o desempenho de dois sistemas diferentes se compara?
- Em quanto o mecanismo colunar reduz o tempo de resposta do desempenho da minha consulta?
- Qual é a carga máxima que um banco de dados pode suportar antes de eu precisar fazer upgrade para uma máquina mais potente?
Entender os objetivos do estudo de desempenho informa qual comparativo de mercado você executa, qual ambiente é necessário e quais métricas você precisa coletar.
Repetibilidade
Para tirar conclusões do teste de desempenho, os resultados precisam ser repetíveis. Se os resultados do teste tiverem uma grande variação, será difícil avaliar o impacto das mudanças feitas no aplicativo ou na configuração do sistema. Realizar testes várias vezes ou por períodos mais longos para fornecer mais dados pode ajudar a reduzir a variação.
O ideal é que os testes de desempenho sejam executados em sistemas isolados de outros sistemas. Executar em um ambiente em que sistemas externos podem afetar o desempenho do aplicativo pode levar a conclusões incorretas. O isolamento total geralmente não é possível em um ambiente de nuvem multilocatário. Por isso, é esperado que haja maior variabilidade nos resultados.
Parte da repetibilidade é garantir que a carga de trabalho de teste permaneça a mesma entre as execuções. Alguma aleatoriedade na entrada de um teste é aceitável, desde que não cause um comportamento significativamente diferente no aplicativo. Se a entrada do cliente gerada aleatoriamente mudar a combinação de leituras e gravações de uma execução para outra, o desempenho vai variar significativamente.
Tamanho do banco de dados, armazenamento em cache e padrões de E/S
Verifique se a quantidade de dados que você está testando é representativa do seu aplicativo. Se você tiver centenas de gigabytes ou terabytes de dados, realizar testes com uma quantidade pequena de dados provavelmente não vai representar de forma realista o desempenho do seu aplicativo. O tamanho do conjunto de dados também influencia as escolhas do otimizador de consultas. As consultas em tabelas de teste pequenas podem usar verificações de tabela que oferecem um desempenho ruim em escalas maiores, e você não vai identificar índices ausentes nessa configuração.
Tente replicar os padrões de E/S do aplicativo. A proporção de leituras e gravações é importante para o perfil de desempenho do aplicativo.
Duração do comparativo de mercado
Em um sistema complexo, há muitas informações de estado que são mantidas enquanto o sistema é executado: conexões de banco de dados são estabelecidas, caches são preenchidos, processos e linhas de execução são gerados. No início de um teste de desempenho, a inicialização desses componentes pode consumir recursos do sistema e afetar negativamente o desempenho medido se o tempo de execução da carga de trabalho for muito curto.
Recomendamos executar testes de desempenho por pelo menos 20 minutos para minimizar os efeitos do aquecimento do sistema. Meça o desempenho durante um estado estável após a inicialização e por tempo suficiente para garantir que todos os aspectos das operações do banco de dados sejam incluídos. Por exemplo, os checkpoints de banco de dados são um recurso essencial dos sistemas de banco de dados e podem ter um impacto significativo no desempenho. Executar um comparativo de mercado curto que termina antes do intervalo de checkpoint oculta esse fator importante no comportamento do aplicativo.
Teste metódico
Ao ajustar o desempenho, mude apenas uma variável por vez. Se você mudar várias variáveis entre as execuções, não será possível isolar qual delas melhorou o desempenho. Na verdade, várias mudanças podem se anular, de modo que você não verá o benefício de uma mudança adequada. Se o servidor de banco de dados estiver sobrecarregado, mude para uma máquina com mais vCPUs e mantenha a carga constante. Se o servidor de banco de dados estiver subutilizado, tente aumentar a carga mantendo a configuração da CPU constante.
Topologia de rede e latências
A topologia de rede do seu sistema pode afetar os resultados do teste de desempenho. A latência entre as zonas é diferente. Ao fazer testes de desempenho, garantir que o cliente e o cluster de banco de dados estejam na mesma zona minimiza a latência de rede e gera o melhor desempenho, especialmente para aplicativos com alta capacidade de processamento e transações curtas, já que a latência de rede pode ser um componente importante do tempo de resposta geral da transação.
Ao comparar o desempenho de dois sistemas diferentes, verifique se a topologia de rede é a mesma para ambos. A variabilidade da latência de rede não pode ser completamente eliminada. Mesmo dentro da mesma zona, pode haver diferenças na latência devido às topologias de rede subjacentes.
Ao implantar seu aplicativo, talvez você queira entender melhor o impacto das latências entre zonas considerando um aplicativo da Web típico de alto volume. O aplicativo tem um balanceador de carga que envia solicitações para vários servidores da Web implantados em várias zonas para alta disponibilidade. As latências podem variar dependendo de qual servidor da Web processa uma solicitação devido a diferenças de latência entre zonas.
A figura a seguir mostra a arquitetura típica de um aplicativo da Web que usa o AlloyDB Omni. As solicitações do cliente são processadas por um balanceador de carga, que encaminha cada solicitação para um dos muitos servidores da Web. Os servidores da Web estão todos conectados ao AlloyDB Omni. Alguns servidores estão em uma zona diferente daquela em que o AlloyDB Omni está em execução e vão encontrar latências mais altas ao fazer solicitações de banco de dados.
Monitoramento de recursos
Para otimizar o desempenho do sistema de banco de dados, é necessário monitorar o uso de recursos do sistema de banco de dados e dos sistemas de cliente que o utilizam. Ao monitorar os dois sistemas, você garante que os sistemas cliente forneçam carga de trabalho suficiente para receber medições significativas no sistema de banco de dados. É fundamental monitorar a utilização de recursos do sistema que você está testando. Monitorar a utilização de recursos dos sistemas cliente que você está usando para impulsionar a carga de trabalho é igualmente importante. Por exemplo, se você quiser determinar o número máximo de clientes que seu sistema de banco de dados pode aceitar antes de ficar sem recursos de CPU, vai precisar de sistemas de cliente suficientes para gerar a carga de trabalho necessária para usar todos os recursos de CPU no sistema de banco de dados. Não será possível usar o sistema de banco de dados de maneira intensa se as máquinas clientes que geram carga não tiverem CPU suficiente.
Teste de escalonabilidade
O teste de escalonabilidade é outro aspecto do teste de desempenho. A escalonabilidade se refere a como as métricas de performance mudam conforme uma característica de uma carga de trabalho varia. Alguns exemplos de estudos de escalonabilidade incluem:
- Como um aumento no número de solicitações simultâneas muda a capacidade de processamento e os tempos de resposta?
- Como um aumento no tamanho do banco de dados muda a capacidade de processamento e os tempos de resposta?
Os testes de escalonabilidade 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 coletadas e plotadas. Esse tipo de teste informa decisões sobre quais gargalos existem no sistema, quanta carga o sistema pode processar em uma configuração específica, a carga máxima que um sistema pode suportar e qual é o comportamento do sistema quando a carga aumenta além desses níveis.
Considerações sobre o tamanho da máquina
O AlloyDB Omni apresenta muitos recursos novos para o Postgres para melhorar a confiabilidade e a disponibilidade do banco de dados. O monitoramento necessário para isso usa recursos na máquina que executa o AlloyDB Omni. Em máquinas muito pequenas, os recursos de memória e CPU são limitados. Por isso, para o comparativo de mercado, recomendamos o uso de máquinas com pelo menos quatro vCPUs.