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 a performance muda à medida que a quantidade de dados aumenta?
- Como a performance de dois sistemas diferentes se compara?
- Quanto o mecanismo colunar reduz o tempo de resposta da minha consulta?
- Qual é a capacidade de carga de um banco de dados antes de eu considerar fazer upgrade para uma máquina mais potente?
Entender as metas do seu 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 dos testes de desempenho, os resultados precisam ser repetíveis. Se os resultados do teste tiverem uma variação grande, será difícil avaliar o impacto das mudanças feitas no aplicativo ou na configuração do sistema. Executar 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 ao executar em um ambiente de nuvem multitenant. Portanto, espere uma variabilidade maior nos resultados.
Parte da capacidade de repetição é 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 do aplicativo. Se a entrada do cliente gerada aleatoriamente mudar a combinação de leituras e gravações de uma execução para outra, a performance vai variar muito.
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. Executar testes com uma pequena quantidade de dados quando você tem centenas de gigabytes ou terabytes provavelmente não vai dar uma representação verdadeira de como seu aplicativo funciona. O tamanho do conjunto de dados também influencia as escolhas feitas pelo otimizador de consultas. Consultas em tabelas de teste pequenas podem usar verificações de tabela que têm desempenho ruim em escalas maiores, e você não vai identificar índices ausentes nessa configuração.
Procure replicar os padrões de E/S do seu aplicativo. A proporção de leituras para 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 à medida que 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 performance por pelo menos 20 minutos para minimizar os efeitos do aquecimento do sistema. Meça a performance durante um estado estável após a inicialização e por tempo suficiente para garantir que todos os aspectos das operações de banco de dados estejam incluídos. Por exemplo, os pontos de verificação 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 seja concluído antes do intervalo do ponto de verificação oculta esse fator importante no comportamento do aplicativo.
Teste metódico
Ao ajustar a performance, mude apenas uma variável por vez. Se você mudar várias variáveis entre execuções, não será possível isolar qual delas melhorou a performance. Na verdade, várias mudanças podem se compensar, e você não vai notar o benefício de uma mudança adequada. Se o servidor de banco de dados estiver sendo usado em excesso, tente mudar para uma máquina com mais vCPUs, mantendo a carga constante. Se o servidor de banco de dados estiver subutilizado, tente aumentar a carga mantendo a configuração da CPU constante.
Topologia e latências de rede
A topologia de rede do seu sistema pode afetar os resultados do teste de desempenho. A latência entre zonas é diferente. Ao fazer testes de performance, 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, principalmente para aplicativos com alta capacidade de processamento e transações curtas, já que a latência de rede pode ser um grande componente do tempo de resposta geral da transação.
Ao comparar a performance de dois sistemas diferentes, verifique se a topologia de rede é a mesma para ambos. A variabilidade da latência da rede não pode ser completamente eliminada. Mesmo na mesma zona, pode haver diferenças na latência devido a topologias de rede subjacentes.
Ao implantar seu aplicativo, talvez seja interessante 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 usando o AlloyDB Omni. As solicitações do cliente são processadas por um balanceador de carga, que encaminha cada solicitação para um de vários servidores da Web. Todos os servidores da Web estão conectados ao AlloyDB Omni. Alguns servidores estão em uma zona diferente de onde o AlloyDB Omni está sendo executado e terão latências mais altas ao fazer solicitações de banco de dados.
Monitoramento de recursos
Para otimizar a performance do sistema de banco de dados, é necessário monitorar o uso de recursos do sistema de banco de dados e dos sistemas clientes que o utilizam. Ao monitorar os dois sistemas, você garante que os sistemas clientes estão fornecendo 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. É igualmente importante monitorar a utilização de recursos dos sistemas clientes que você está usando para impulsionar a carga de trabalho. Por exemplo, se você quiser determinar o número máximo de clientes que seu sistema de banco de dados pode oferecer suporte antes de ficar sem recursos de CPU, precisará de sistemas de clientes 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 forçar o sistema de banco de dados 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 performance. A escalonabilidade se refere a como as métricas de desempenho mudam à medida que 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 taxa de transferência 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 representadas. Esse tipo de teste informa decisões sobre quais gargalos existem no sistema, quanta carga ele pode processar com 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, melhorando 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 tamanhos de máquina muito pequenos, há recursos limitados de memória e CPU para começar. Por isso, para comparativos de mercado, recomendamos usar tamanhos de máquina de quatro vCPUs no mínimo.