Este documento descreve recomendações para executar testes de desempenho no AlloyDB Omni em uma VM. Este documento pressupõe que você já conhece o PostgreSQL.
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 comparar a performance de dois sistemas diferentes?
- Em quanto o mecanismo de colunas reduz o tempo de resposta da minha consulta?
- Quantos dados um banco de dados pode processar antes de precisar de uma máquina mais potente?
Compreender as metas do estudo de performance 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 do teste 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 performance sejam executados em sistemas isolados. A execução em um ambiente em que sistemas externos podem afetar o desempenho do aplicativo pode levar a conclusões incorretas. Muitas vezes, o isolamento total não é possível quando executado em um ambiente de nuvem multiusuário. Portanto, é esperado que haja uma maior variabilidade nos resultados.
Parte da repetibilidade é garantir que a carga de trabalho do teste permaneça a mesma entre as execuções. É aceitável que haja alguma aleatoriedade na entrada de um teste, desde que ela 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. A execução de testes com uma pequena quantidade de dados quando você tem centenas de gigabytes ou terabytes de dados provavelmente não vai representar de forma verdadeira o desempenho do aplicativo. O tamanho do conjunto de dados também influencia as escolhas feitas pelo otimizador de consultas. As consultas em pequenas tabelas de teste 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.
Tente replicar os padrões de E/S do seu aplicativo. A proporção de leituras e gravações é importante para o perfil de desempenho do seu 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: as conexões de banco de dados são estabelecidas, os caches são preenchidos, os processos e as linhas de execução são geradas. No início de um teste de desempenho, a inicialização desses componentes pode ocupar 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 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 pontos de verificação do banco de dados são um recurso essencial dos sistemas de banco de dados e podem ter um impacto significativo no desempenho. A execução de um comparativo de mercado curto que é concluído antes do intervalo de verificação oculta esse fator importante no comportamento do aplicativo.
Testes metódicos
Ao ajustar a performance, 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 compensar umas às outras, de modo que você não vai notar o benefício de uma mudança adequada. Se o servidor de banco de dados estiver sobrecarregado, 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 de rede e latências
A topologia de rede do seu sistema pode afetar os resultados do teste de performance. A latência entre as zonas é diferente. Ao fazer testes de desempenho, garantir que o cliente e o cluster do banco de dados estejam na mesma zona minimiza a latência da rede e gera o melhor desempenho, especialmente para aplicativos com alto throughput e transações curtas, já que a latência da rede pode ser um componente importante 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 às topologias de rede subjacentes.
Ao implantar seu aplicativo, é possível entender melhor o impacto das latências entre zonas considerando um aplicativo da Web de alto volume típico. 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 as 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 servidor da Web entre muitos. Os servidores da Web estão todos conectados ao AlloyDB Omni. Alguns servidores estão em uma zona diferente de onde 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 usam o sistema de banco de dados. Ao monitorar os dois sistemas, você pode garantir que os sistemas de cliente estejam fornecendo carga de trabalho suficiente para obter 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 de 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 o sistema de banco de dados pode suportar antes de ficar sem recursos de CPU, será necessário ter 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 direcionar o sistema de banco de dados de forma eficiente se as máquinas clientes que geram carga não tiverem CPU suficiente.
Teste de escalonabilidade
O teste de escalonabilidade é outro aspecto dos testes de performance. A escalabilidade 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 capacidade de resposta consistem em várias execuções de uma carga de trabalho em que uma única dimensão é variada 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 o sistema 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 ao Postgres para melhorar a confiabilidade e a disponibilidade do banco de dados. A monitoração necessária para fazer isso usa recursos na máquina que executa o AlloyDB Omni. Em máquinas muito pequenas, há recursos de memória e CPU limitados para começar. Portanto, para a comparação de mercado, recomendamos o uso de máquinas com pelo menos quatro vCPUs.