虚拟机上 AlloyDB Omni 的性能测试方法

本文档介绍了在虚拟机上对 AlloyDB Omni 运行性能测试的建议。本文档假定您熟悉 PostgreSQL。

在对性能进行基准测试时,请先确定您希望从测试中了解什么。例如:

  • 系统可以达到的最大吞吐量是多少?
  • 特定查询或工作负载需要多长时间?
  • 随着数据量的增加,性能会发生怎样的变化?
  • 两种不同系统的性能如何?
  • 列式引擎能将查询性能的响应时间缩短多少?
  • 数据库能处理多少负载,我才应该考虑升级到更强大的机器?

了解性能研究的目标有助于确定要运行的基准测试、所需的环境以及需要收集的指标。

重复性

为了从性能测试中得出结论,测试结果必须可重复。如果测试结果差异很大,您将很难评估自己在应用或系统配置中所做的更改的影响。多次运行测试或让测试运行更长时间以提供更多数据,有助于降低差异量。

理想情况下,性能测试应在与其他系统隔离的系统上运行。如果在外部系统可能会影响应用性能的环境中运行,可能会得出错误的结论。在多租户云环境中运行时,通常无法实现完全隔离,因此您应该预计结果会出现更大的差异

可重复性部分包括确保测试工作负载在每次运行之间保持不变。测试输入中存在一些随机性是可以接受的,前提是这种随机性不会导致应用行为出现明显差异。如果随机生成的客户端输入会导致每次运行时读写混合比例不同,性能将会出现很大差异。

数据库大小、缓存和 I/O 模式

确保您用于测试的数据量能代表您的应用。如果您有数百 GB 或数 TB 的数据,而使用少量数据运行测试,则可能无法真实反映应用的性能。数据集的大小也会影响查询优化器做出的选择。针对小型测试表的查询可能会使用表扫描,但在更大规模的情况下,性能会较差,并且您无法在此配置中识别缺少的索引。

尽量复制应用的 I/O 模式。读写比率对应用的性能配置文件至关重要。

基准时长

在复杂系统中,系统执行时会维护大量状态信息:建立数据库连接、填充缓存、生成进程和线程。在性能测试开始时,如果工作负载的运行时过短,这些组件的初始化可能会占用系统资源,并对测量的性能产生不利影响。

我们建议您让性能测试至少运行 20 分钟,以最大限度地减少系统预热的影响。在启动后测量稳定状态下的性能,并确保测量时间足够长,以涵盖数据库操作的所有方面。例如,数据库检查点是数据库系统的一项关键功能,可能会对性能产生重大影响。运行在检查点间隔之前完成的短基准测试会隐藏应用行为中这一重要因素。

有条理地测试

优化广告效果时,请一次只更改一个变量。如果您在运行之间更改多个变量,则无法确定哪个变量提升了性能。事实上,多项更改可能会相互抵消,因此您不会看到适当更改的好处。如果数据库服务器过度使用,请尝试切换到具有更多 vCPU 的机器,同时保持负载不变。如果数据库服务器未充分利用,请尝试增加负载,同时保持 CPU 配置不变。

网络拓扑和延迟时间

系统的网络拓扑可能会影响性能测试结果。可用区之间的延迟时间不同。进行性能测试时,确保客户端和数据库集群位于同一可用区可最大限度地缩短网络延迟时间并获得最佳性能,尤其是对于吞吐量高、事务短的应用,因为网络延迟时间可能是总体事务响应时间的重要组成部分。

比较两种不同系统的性能时,请确保这两种系统的网络拓扑相同。请注意,网络延迟时间差异无法完全消除,即使在同一可用区内,延迟时间也可能会因基础网络拓扑而异。

在部署应用时,您不妨考虑一个典型的高流量 Web 应用,以便更好地了解跨可用区延迟时间的影响。该应用有一个负载平衡器,用于将请求发送到部署在多个可用区中的多个 Web 服务器,以实现高可用性。由于跨可用区延迟时间不同,延迟时间可能会因处理请求的 Web 服务器而异。

下图显示了使用 AlloyDB Omni 的 Web 应用的典型架构。客户端请求由负载平衡器处理,负载平衡器会将每个请求转发到众多 Web 服务器中的某个服务器。Web 服务器都连接到 AlloyDB Omni。有些服务器位于 AlloyDB Omni 运行所在区域之外的区域,因此在发出数据库请求时会遇到更长的延迟时间。

展示典型 Web 应用架构的流程图。
图 1:典型 Web 应用架构示意图。我们预计,当可用区 B 中的网络服务器向数据库发出请求时,延迟时间会更短,因为它们与 AlloyDB Omni 数据库位于同一可用区。

资源监控

如需优化数据库系统的性能,您需要监控数据库系统以及使用数据库系统的客户端系统的资源使用情况。通过监控这两个系统,您可以确保客户端系统提供足够的工作负载,以便在数据库系统中获得有意义的测量结果。监控您要测试的系统的资源利用率至关重要。监控您用于驱动工作负载的客户端系统的资源利用率同样重要。例如,如果您想确定数据库系统在耗尽 CPU 资源之前可以支持的客户端数量上限,则需要足够多的客户端系统来生成足以耗尽数据库系统中所有 CPU 资源的工作负载。如果产生负载的客户端机器本身没有足够的 CPU,您将无法充分驱动数据库系统。

可伸缩性测试

可伸缩性测试是性能测试的另一个方面。可扩缩性是指随着工作负载的一个特征的变化,性能指标的变化方式。可伸缩性研究的一些示例包括:

  • 并发请求数量的增加会如何影响吞吐量和响应时间?
  • 数据库大小的增加如何影响吞吐量和响应时间?

可伸缩性测试由工作负载的多次运行组成,每次运行时单个维度都会有所变化,系统会收集一个或多个指标并绘制图表。此类测试有助于您做出以下决策:系统存在哪些瓶颈、在特定配置下系统可以处理多少负载、系统可以支持的最大负载,以及当负载超过这些水平时系统的行为。

机器大小注意事项

AlloyDB Omni 为 Postgres 引入了许多新功能,以提高数据库的可靠性和可用性。为此,所需的监控会使用运行 AlloyDB Omni 的机器上的资源。在非常小的机器大小上,内存和 CPU 资源从一开始就很有限,因此在进行基准测试时,我们建议至少使用 4 个 vCPU 的机器大小。