当您绘制吞吐量随时间变化的图表时，随着另一个变量的修改，您通常会看到吞吐量增加，直到吞吐量达到资源耗尽的程度。
下图显示了典型的吞吐量扩缩图表。随着客户端数量的增加，工作负载和吞吐量会增加，直到所有资源都用尽。
理想情况下，当系统负载加倍时，吞吐量也应加倍。实际上，资源争用会导致吞吐量增加变小。在某些时候，资源耗尽或争用会导致吞吐量趋于平稳甚至下降。如果您要针对吞吐量进行优化，则这是一个关键点，因为它会引导您确定在哪些方面调优应用或数据库系统以提高吞吐量。
吞吐量趋于平稳或下降的典型原因包括以下几点：
- 数据库服务器上的 CPU 资源耗尽
- 客户端上的 CPU 资源耗尽，因此数据库服务器不会再发送更多工作
- 数据库锁定争用
- 数据超过 Postgres 缓冲区池大小时的 I/O 等待时间
- 因存储引擎利用率而产生的 I/O 等待时间
- 网络带宽瓶颈导致数据返回到客户端
延迟时间和吞吐量成反比。随着延迟时间增加，吞吐量会降低。从直观上讲，这很合理。当瓶颈开始显现时，操作开始花费更长时间，且系统每秒执行的操作数量更少。
延迟时间扩缩图表显示了延迟时间随着系统负载增加而发生的变化。延迟时间会保持相对不变，直到因资源争用而造成影响。此曲线的拐点通常对应于吞吐量扩缩图表中的吞吐量曲线的扁平化。
另一种评估延迟时间的实用方法是使用直方图。在此表示法中，我们将延迟时间分组到各个存储桶中，并计算每个存储桶中的请求数量。
此延迟时间直方图显示，大多数请求的延迟时间都低于 100 毫秒，而延迟时间超过 100 毫秒的请求很少。了解延迟时间较长的请求的原因有助于解释所看到的应用性能变化。延迟时间增加的长尾原因与典型延迟时间扩缩图表中看到的延迟时间增加和吞吐量图表的扁平化相对应。
延迟时间直方图最有用的情况是应用中存在多种模态。模态是一组正常的操作条件。例如，在大多数情况下，应用会访问缓冲区缓存中的页面。大多数情况下，应用会更新现有行，但也可能有多种模式。有时，应用会从存储空间检索页面、插入新行或遇到锁定争用。
当应用在一段时间内遇到这些不同的操作模式时，延迟时间直方图会显示这些多种模态。
此图显示了典型的双模直方图，其中大多数请求在 100 毫秒内完成，但还有一个集群的请求需要 401-500 毫秒。了解这种第二种模态的原因有助于提升应用的性能。也可以有两种以上的模态。
第二种模态可能是由于正常的数据库操作、异构基础设施和拓扑或应用行为造成的。以下是一些需要考虑的示例：
- 大多数数据访问来自 PostgreSQL 缓冲区池，但有些来自存储空间
- 某些客户端到数据库服务器的网络延迟时间不同
- 根据输入或时间执行不同操作的应用逻辑
- 偶尔的锁定争用
- 客户端活动激增