Quando representa graficamente o débito ao longo do tempo à medida que outra variável é modificada, normalmente, vê o débito aumentar até atingir um ponto de esgotamento dos recursos.
A figura seguinte mostra um gráfico de escalabilidade da taxa de transferência típico. À medida que o número de clientes aumenta, a carga de trabalho e o débito aumentam até que todos os recursos se esgotem.
Idealmente, à medida que duplica a carga no sistema, o débito também deve duplicar. Na prática, existe contenção nos recursos que leva a aumentos de débito mais pequenos. Em algum momento, o esgotamento ou a contenção de recursos fará com que o débito se estabilize ou até diminua. Se estiver a otimizar o débito, este é um ponto fundamental a identificar, uma vez que direciona os seus esforços para onde ajustar o sistema de base de dados ou de aplicação para melhorar o débito.
Os motivos típicos para a estabilização ou a diminuição da taxa de transferência incluem o seguinte:
- Esgotamento dos recursos da CPU no servidor da base de dados
- Esgotamento dos recursos da CPU no cliente, pelo que não é enviado mais trabalho para o servidor da base de dados
- Contenção de bloqueio da base de dados
- Tempo de espera de E/S quando os dados excedem o tamanho do conjunto de buffers do Postgres
- Tempo de espera de E/S devido à utilização do motor de armazenamento
- Restrições da largura de banda da rede que devolvem dados ao cliente
A latência e o débito são inversamente proporcionais. À medida que a latência aumenta, o débito diminui. Intuitivamente, isto faz sentido. À medida que um gargalo começa a materializar-se, as operações demoram mais tempo e o sistema realiza menos operações por segundo.
O gráfico de escalabilidade da latência mostra como a latência muda à medida que a carga colocada num sistema aumenta. A latência permanece relativamente constante até ocorrer atrito devido à contenção de recursos. O ponto de inflexão desta curva corresponde geralmente ao achatamento da curva de débito no gráfico de escalabilidade do débito.
Outra forma útil de avaliar a latência é através de um histograma. Nesta representação, agrupamos as latências em segmentos e contamos quantos pedidos se enquadram em cada segmento.
Este histograma de latência mostra que a maioria dos pedidos está abaixo dos 100 milissegundos e as latências são superiores a 100 milissegundos. Compreender a causa dos pedidos com caudas de latências mais longas pode ajudar a explicar as variações no desempenho da aplicação observadas. As causas da cauda longa de latências aumentadas correspondem às latências aumentadas observadas no gráfico de escalabilidade de latência típico e ao achatamento do gráfico de débito.
O histograma de latência é mais útil quando existem várias modalidades numa aplicação. Uma modalidade é um conjunto normal de condições de funcionamento. Por exemplo, na maioria das vezes, a aplicação está a aceder a páginas que se encontram na cache do buffer. Na maioria das vezes, a aplicação está a atualizar linhas existentes. No entanto, podem existir vários modos. Por vezes, a aplicação está a obter páginas do armazenamento, a inserir novas linhas ou a ter problemas de contenção de bloqueios.
Quando uma aplicação encontra estes diferentes modos de funcionamento ao longo do tempo, o histograma de latência mostra estas várias modalidades.
Esta figura mostra um histograma bimodal típico em que a maioria dos pedidos é processada em menos de 100 milissegundos, mas existe outro cluster de pedidos que demoram entre 401 e 500 milissegundos. Compreender a causa desta segunda modalidade pode ajudar a melhorar o desempenho da sua aplicação. Também pode haver mais de duas modalidades.
A segunda modalidade pode dever-se a operações normais da base de dados, a uma infraestrutura e topologia heterogéneas ou ao comportamento da aplicação. Seguem-se alguns exemplos a ter em conta:
- A maioria dos acessos aos dados é proveniente do buffer pool do PostgreSQL, mas alguns são provenientes do armazenamento
- Diferenças nas latências de rede para alguns clientes no servidor de base de dados
- Lógica da aplicação que executa operações diferentes consoante a entrada ou a hora do dia
- Contenção de bloqueio esporádica
- Picos na atividade do cliente