Banco de Dados

Benchmarks de Performance

A Zenifra não publica hoje resultados oficiais de benchmark por plano. Números de performance dependem do esquema, dos índices, do volume de dados, do número de conexões, da latência entre a aplicação e o banco e da versão da engine; por isso, a forma mais confiável de escolher um plano é medir a sua própria carga.

Os recursos de cada plano (vCPU, RAM e preço por instância) estão em Planos de Banco de Dados.


Como medir no seu projeto

  1. Crie um projeto de banco de teste no plano que deseja avaliar, de preferência no pagamento por hora, e remova-o ao terminar.
  2. Rode o teste a partir de onde a sua aplicação vai rodar, para que a latência de rede seja realista.
  3. Use um volume de dados e uma quantidade de conexões parecidos com os de produção.
  4. Execute cada teste mais de uma vez e registre versão, plano, número de instâncias, tamanho do dataset, número de conexões e duração.

PostgreSQL com pgbench

O pgbench acompanha o cliente oficial do PostgreSQL. Use a URI copiada do console, mantendo a validação TLS (sslmode=verify-full):

# cria as tabelas de teste (fator de escala 10)
pgbench -i -s 10 "postgresql://app:<senha>@<host>:<porta>/app?sslmode=verify-full&sslrootcert=system"

# 60 segundos, 10 conexões, 2 threads
pgbench -c 10 -j 2 -T 60 -P 10 "postgresql://app:<senha>@<host>:<porta>/app?sslmode=verify-full&sslrootcert=system"

O resultado mostra transações por segundo (tps) e latência média. Para medir apenas leitura, acrescente -S. Remova as tabelas pgbench_* depois do teste.

Para MariaDB, use uma ferramenta equivalente, como o sysbench, com conexão TLS.

Durante o teste, acompanhe CPU, memória, conexões, locks e latência nas métricas do banco, disponíveis nos planos db-premium e db-enterprise.


Fatores que Afetam a Performance

  1. Número de conexões: muitas conexões simultâneas podem degradar a performance
  2. Índices: queries sem índices são significativamente mais lentas
  3. Tamanho do dataset: datasets maiores que a memória do plano dependem mais do disco
  4. Latência de rede: a distância entre a aplicação e o banco soma tempo a cada consulta

Dicas de Otimização

  • Use índices apropriados para suas queries
  • No PostgreSQL com 2 ou 3 instâncias, use a URI somente leitura para consultas SELECT que toleram pequeno atraso de replicação
  • Configure connection pooling na aplicação para controlar o número de conexões
  • Monitore as métricas do banco (planos db-premium e db-enterprise)

Última atualização em

Nessa página