Ao representar graficamente a capacidade de processamento ao longo do tempo, à medida que outra variável é modificada, normalmente você vê a capacidade de processamento aumentar até atingir um ponto de esgotamento de recursos.
A figura a seguir mostra um gráfico de escalonamento de capacidade de processamento típico. À medida que o número de clientes aumenta, a carga de trabalho e a capacidade de processamento aumentam até que todos os recursos sejam esgotados.
O ideal é que, ao dobrar a carga no sistema, a capacidade de processamento também dobre. Na prática, haverá disputa de recursos que levará a aumentos menores na capacidade de processamento. Em algum momento, o esgotamento ou a disputa de recursos fará com que a capacidade de processamento se estabilize ou até diminua. Se você estiver otimizando a capacidade de processamento, esse é um ponto fundamental a ser identificado, já que ele direciona seus esforços para onde ajustar o aplicativo ou o sistema de banco de dados para melhorar a capacidade de processamento.
Os motivos típicos para a capacidade de processamento se estabilizar ou cair incluem o seguinte:
- Esgotamento de recursos da CPU no servidor de banco de dados
- Esgotamento de recursos da CPU no cliente, para que o servidor de banco de dados não receba mais trabalho
- Disputa de bloqueio de banco de dados
- Tempo de espera de E/S quando os dados excedem o tamanho do pool de buffer do Postgres
- Tempo de espera de E/S devido à utilização do mecanismo de armazenamento
- Gargalos de largura de banda da rede que retornam dados ao cliente
A latência e a capacidade de processamento são inversamente proporcionais. À medida que a latência aumenta, a capacidade de processamento diminui. Isso faz sentido intuitivamente. À medida que um gargalo começa a se materializar, as operações começam a demorar mais e o sistema executa menos operações por segundo.
O gráfico de escalonamento de latência mostra como a latência muda à medida que a carga colocada em um sistema aumenta. A latência permanece relativamente constante até que ocorra atrito devido à disputa de recursos. O ponto de inflexão dessa curva geralmente corresponde ao achatamento da curva de capacidade de processamento no gráfico de escalonamento de capacidade de processamento.
Outra maneira útil de avaliar a latência é como um histograma. Nessa representação, agrupamos as latências em buckets e contamos quantas solicitações se enquadram em cada bucket.
Esse histograma de latência mostra que a maioria das solicitações tem menos de 100 milissegundos e latências maiores que 100 milissegundos. Entender a causa das solicitações com uma cauda de latências mais longas pode ajudar a explicar as variações de performance do aplicativo. As causas da cauda longa de latências aumentadas correspondem às latências aumentadas vistas no gráfico de escalonamento de latência típico e ao achatamento do gráfico de capacidade de processamento.
O histograma de latência é mais útil quando há várias modalidades em um aplicativo. Uma modalidade é um conjunto normal de condições operacionais. Por exemplo, na maioria das vezes, o aplicativo acessa páginas que estão no cache de buffer. Na maioria das vezes, o aplicativo está atualizando linhas existentes. No entanto, pode haver vários modos. Em alguns momentos, o aplicativo está recuperando páginas do armazenamento, inserindo novas linhas ou enfrentando disputa de bloqueio.
Quando um aplicativo encontra esses diferentes modos de operação ao longo do tempo, o histograma de latência mostra essas várias modalidades.
Essa figura mostra um histograma bimodal típico em que a maioria das solicitações é atendida em menos de 100 milissegundos, mas há outro cluster de solicitações que leva de 401 a 500 milissegundos. Entender a causa dessa segunda modalidade pode ajudar a melhorar a performance do aplicativo. Também pode haver mais de duas modalidades.
A segunda modalidade pode ser devido a operações normais de banco de dados, infraestrutura e topologia heterogêneas ou comportamento do aplicativo. Confira alguns exemplos:
- A maioria dos acessos a dados é do pool de buffer do PostgreSQL, mas alguns vêm do armazenamento
- Diferenças nas latências de rede para alguns clientes no servidor de banco de dados
- Lógica de aplicativo que executa operações diferentes dependendo da entrada ou da hora do dia
- Disputa de bloqueio esporádica
- Picos na atividade do cliente