Ao comparar a performance, defina o que você espera aprender com o teste antes de começar. Exemplo:
- Qual é a capacidade de processamento máxima 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 performance da minha consulta?
- Quanta carga um banco de dados pode processar antes de eu considerar a atualização para uma máquina mais potente?
Entender as metas do estudo de performance informa qual comparativo de mercado executar, qual ambiente é necessário e quais métricas você precisa coletar.
Repetibilidade
Para tirar conclusões dos testes de performance, 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. Executar testes várias vezes ou por períodos mais longos para fornecer mais dados pode ajudar a diminuir a quantidade de variação.
O ideal é que os testes de performance sejam executados em sistemas isolados de outros. A execução em um ambiente em que sistemas externos podem afetar a performance 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 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 ela 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 execução para execução, a performance 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. Executar testes com uma pequena quantidade de dados quando você tem centenas de gigabytes ou terabytes de dados 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 oferecem performance 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 performance 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 performance, a inicialização desses componentes pode consumir recursos do sistema e afetar negativamente a performance medida 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 do banco de dados são um recurso essencial dos sistemas de banco de dados e podem ter um impacto significativo na performance. 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 as execuções, não será possível isolar qual variável melhorou a performance. Na verdade, várias mudanças podem se compensar para que você não veja o benefício de uma mudança adequada. Se o servidor de banco de dados estiver superutilizado, 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 sistema pode afetar os resultados do teste de performance. A latência entre as 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 da rede e oferece a melhor performance, especialmente para aplicativos com alta capacidade de processamento e transações curtas, já que a latência da 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 de 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 o aplicativo, considere um aplicativo da Web típico de alto volume para entender melhor o impacto das latências entre zonas. 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 servidor da Web entre muitos. 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á em execução e vão encontrar 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 os usos de recursos do sistema de banco de dados e dos sistemas clientes que usam o sistema de banco de dados. Ao monitorar os dois sistemas, você pode garantir que os sistemas clientes estejam 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. O monitoramento da utilização de recursos dos sistemas clientes que você está usando para gerar 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 oferecer suporte antes de ficar sem recursos de CPU, será necessário ter sistemas 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 performance mudam à medida que uma característica de uma carga de trabalho varia. Confira alguns exemplos de estudos de escalonabilidade:
- 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 é variada 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 com uma configuração específica, a carga máxima que um sistema pode oferecer suporte 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. O monitoramento necessário para isso usa recursos na máquina que executa o AlloyDB Omni. Em tamanhos de máquinas muito pequenos, há recursos limitados de memória e CPU para começar. Portanto, para comparativos de mercado, recomendamos o uso de tamanhos de máquinas de quatro vCPUs no mínimo.