Azure Database for MySQL - 灵活服务器性能基准测试的最佳做法
性能是任何应用程序的标志，定义明确的策略来分析和评估数据库在处理应用程序的可变工作负载要求时的表现至关重要。
本文提供了针对 Azure Database for MySQL 灵活服务器运行性能基准测试的注意事项和最佳做法。
性能测试
初看之下，综合性地对关系数据库系统的性能进行基准测试似乎是一项微不足道的任务。 毕竟，手动评估单个查询的性能，甚至使用可用的某个基准测试工具启动简单的综合测试相对容易。 这些类型的测试花费的时间很少，并可以快速生成易于理解的结果。
但是，对真实生产系统的性能进行基准测试需要付出大量额外努力。 设计、实现和运行真正代表生产工作负载的测试并不容易。 更难的是，基于在隔离环境中执行的一系列基准测试的结果，做出关于生产数据堆栈的决策。
性能测试方法
综合基准测试
综合测试旨在使用模拟数据库环境中可重复结果的人工工作负载样本对数据库系统施加压力。 这样，客户就可以在多个环境之间执行比较，以衡量适合其生产部署的数据库资源。
使用综合基准测试可以获得多种好处。 例如，它们：
- 可预测、可重复，并允许进行选择性测试（例如，只写测试、只读测试、读写混合测试，以及专门针对表的测试）。
- 提供可以使用简单指标（例如“每秒查询数”、“每秒事务数”等）表示的总体结果。
- 不需要特定于应用程序或环境的知识来生成和运行。
- 可以快速执行，几乎不需要准备工作。 但是，它们也存在一些缺点，因为：
- 人工工作负载样本并不代表真实的应用程序流量。
- 结果不能用于准确预测生产工作负载的性能。
- 用于测试不同的数据库产品时，它们可能不会公开特定于产品的性能特征。
- 很容易错误地执行测试，并生成更不具有代表性的结果。
综合测试非常适合用于产品之间的快速比较。 你还可以使用它们来实现持续的性能监视机制。 例如，可在每个周末运行一个测试套件来验证数据库系统的基线性能、检测异常情况并预测长期性能模式（例如，由于数据增长而导致的查询延迟降级）。
真实基准测试
使用真实基准测试可为数据库提供与生产流量非常相似的工作负载样本。 可以通过重播生产查询日志并度量数据库性能来直接实现此目的。 还可以通过在应用程序级别运行测试并度量给定数据库服务器上的应用程序性能来间接实现此目的。
使用真实基准测试可获得多种好处，因为它们：
- 提供真实生产条件下系统性能的准确视图。
- 可以揭示简化的综合测试所不能揭示的特定于应用程序或数据库的特征。
- 帮助根据应用程序的增长相应地规划容量。
真实基准测试也存在一些缺点：
- 难以设计和运行。
- 必须予以维护，以确保随着应用程序的增长保持相关性。
- 提供仅在给定应用程序的上下文中才有意义的结果。
准备对环境进行重大更改时（例如，在部署新的数据库产品时），建议使用真实测试。 在这种情况下，使用实际生产工作负载运行综合基准测试将有很大帮助。 它不仅可以提供可信任的准确结果，还可以移除或至少大大减少你的系统中“未知”的数量。
选择“正确的”测试方法
针对你的目的，“正确的”测试方法完全取决于测试的目标。
如果要快速比较使用人工数据和工作负载示例的不同数据库产品，则可以安全地使用现有基准测试程序来生成数据并运行测试。
若要准确评估你打算在新数据库产品上运行的实际应用程序的性能，应执行真实基准测试。 每个应用程序都有一套独特的要求和性能特征，因此建议在所有性能评估中包括真实基准测试。
有关准备和运行综合与真实基准测试的指导，请参阅本文稍后的以下部分：
- 准备和运行综合测试
- 准备和运行真实测试
性能测试最佳做法
特定于服务器的建议
服务器大小调整
启动 Azure Database for MySQL 灵活服务器实例以执行基准测试时，请使用与你当前数据库环境匹配的 Azure Database for MySQL 灵活服务器实例层、SKU 和实例计数。
例如：
- 如果你的当前服务器具有 8 个 CPU 核心和 64 GB 内存，则最好选择基于 Standard_E8ds_v4 SKU 的实例。
- 如果你的当前数据库环境使用只读副本，请使用 Azure Database for MySQL 灵活服务器只读副本。
根据基准测试的结果，可以决定在生产环境中使用不同的实例大小和数量。 但是，好的做法仍然是，确保测试实例的初始规范接近你当前的服务器规范，以提供更准确的同类比较。
服务器配置
如果应用程序/基准测试需要启用某些数据库功能，则应在运行基准测试之前相应地调整服务器参数。 例如，你可能需要：
- 设置非默认服务器时区。
- 如果默认值不足，请设置自定义“max_connections”参数。
- 如果你的 Azure Database for MySQL 灵活服务器实例正在运行版本 8.0，请配置线程池。
- 如果你预期需要在生产环境中使用慢速查询日志，请启用该功能，以便可以分析任何导致瓶颈的查询。
其他参数（如与各种数据库缓冲区和缓存的大小相关的参数）已在 Azure Database for MySQL 灵活服务器中进行预优化，你可以在开始时将它们保留为默认值。 虽然你可以修改它们，但最好避免进行服务器参数更改，除非你的性能基准表明给定的更改确实可以提高性能。
执行测试并将 Azure Database for MySQL 灵活服务器与其他数据库产品进行比较时，请务必在测试数据库上启用你预期在生产中使用的所有功能。 例如，如果你未在测试环境中启用区域冗余 HA、备份和只读副本，则结果可能无法准确反映实际性能。
特定于客户端的建议
所有性能基准测试都涉及客户端的使用，因此无论选择哪种基准测试方法，都必须考虑以下客户端建议。
- 确保客户端实例与要测试的 Azure Database for MySQL 灵活服务器实例位于同一 Azure 虚拟网络 (VNet) 中。 对于延迟敏感型应用程序，最好将客户端实例置于与数据库服务器相同的可用性区域 (AZ)。
- 如果生产应用程序预期在多个实例上运行（例如负载均衡器后面的应用服务器舰队），则执行基准测试时最好使用多个客户端实例。
- 确保所有客户端实例有足够的计算、内存、I/O 和网络容量来处理基准测试。 换言之，客户端生成请求的速度必须比数据库引擎处理请求的速度要快。 所有操作系统都提供诊断工具（例如 Linux 上的“top”、“htop”、“dstat”或“iostat”），可帮助诊断客户端实例上的资源利用率。 建议使用这些工具，并确保所有客户端实例在运行基准测试时始终具有备用 CPU、内存、网络和 IO 容量。
即使对于大 SKU，单个客户端实例也可能无法始终足够快地生成请求以使数据库饱和。 根据测试配置，Azure Database for MySQL 灵活服务器每秒可以处理数十万个读/写请求，这可能超过单个客户端可以容纳的范围。 为了避免在繁重的性能测试期间出现客户端争用，从多个客户端实例并行运行基准是一种常见做法。
重要
如果要使用流量生成器脚本或第三方工具（如 Apache Benchmark、Apache JMeter 或 Siege）对应用程序进行基准测试，则还应使用之前提到的建议评估运行工具的实例。
准备和运行综合测试
综合基准测试工具（例如 sysbench）易于安装和运行，但它们通常需要一定程度的配置和优化才能使任何给定基准测试实现最佳结果。
表计数和大小
在基准测试之前生成的表的数量和大小应该较大。 例如，对包含 10 万行的单个表执行的测试不太可能产生有用的结果，因为此类数据集可能比几乎所有的真实数据库都要小。 要进行比较，使用多个表（例如 10-25 个，每个表包含 500 万行）的基准测试可能会更真实地反映实时工作负载。
测试模式
使用大多数基准测试工具（包括热门的 sysbench）时，可以定义要针对服务器运行的工作负载类型。 例如，该工具可以生成：
- 语法相同但参数不同的只读查询。
- 不同类型的只读查询（点选择、范围选择、排序选择等）。
- 修改单个行或行范围的只写语句。
- 读/写语句的混合形式。
如果要在这些特定方案中测试数据库性能和可伸缩性，则可以使用只读或只写工作负载。 但是，有代表性的基准测试通常应该包括适当的读/写语句混合形式，因为这是大多数 OLTP 数据库必须处理的工作负载类型。
并发级别
并发级别是同时对数据库执行操作的线程数。 大多数基准测试工具默认使用单线程，而这不能代表真实的数据库环境，因为单个客户端极少同时使用多个数据库。
若要测试数据库的理论峰值性能，请使用以下过程：
- 运行多个测试并为每个测试使用不同的线程数。 例如，从 32 个线程开始，然后增加每个后续测试的线程数（64、128、256 等）。
- 不断增加线程数，直到数据库性能稳定 – 这是理论上的峰值性能。
- 确定数据库性能在给定的并发级别停止提升时，仍可以尝试将线程数再增加几次，这会表明性能是保持稳定还是开始下降。 有关详细信息，请参阅博客文章使用 Sysbench 对 Azure Database for MySQL � 灵活服务器进行基准测试。
准备和运行真实测试
每个应用程序在数据特征和性能要求方面是独特的。 因此，很难想出一套通用的步骤清单，能够在任意数据库环境中准备和运行具有代表性的现实基准。
本部分提出的思路旨在使性能测试项目变得简单一些。
准备测试数据
在针对 Azure Database for MySQL 灵活服务器执行性能基准测试之前，请确保服务器已填充你的生产数据集的代表样本。
尽可能使用生产集的完整副本。 如果无法做到，请使用以下建议来帮助确定你应始终包含哪些数据部分以及可以忽略哪些数据。
- 测试服务器需要包含由基准测试直接使用的所有对象（即模式、表、函数和过程）。 应该完整填充每个表，即它应该包含它在生产环境中包含的所有行。 如果未完整填充表（例如，它们只包含行集的小样本），则基准测试结果不会有代表性。
- 排除生产应用程序使用的表，但那不是连续操作流量的一部分。 例如，如果数据库包含实时操作数据集以及用于分析的历史数据，则无需提供历史数据来运行基准测试。
- 使用真实生产数据而不是以编程方式生成的人工样本来填充要复制到测试服务器的所有表。
设计应用程序基准测试
执行应用程序基准测试的概要过程如下：
- 创建 Azure Database for MySQL 灵活服务器实例，并使用你的生产数据的副本填充它。
- 在 Azure 中部署应用程序的副本。
- 将应用程序配置为使用 Azure Database for MySQL 灵活服务器实例。
- 对应用程序运行负载测试并评估结果。
如果可以轻松地在 Azure 中部署应用程序的副本，则此方法非常有用。 使用此方法能够以最彻底且准确的方式进行性能评估，但仍需要记住一些建议。
- 用于生成应用程序流量的工具必须能够生成代表生产工作负载的混合请求。 例如，不要通过重复访问相同的应用程序 URL 来进行测试，因为这可能无法代表客户在现实世界中使用该应用程序的方式。
- 客户端和应用程序实例池必须足够强大以生成请求、处理请求并从数据库接收响应，而不会造成任何瓶颈。
- 并发级别（基准测试工具生成的并行请求数）应该匹配或者略高于在应用程序中观察到的预期峰值并发级别。
设计数据库基准测试
如果无法轻松地在 Azure 中部署应用程序的副本，则需要直接对数据库运行 SQL 语句来执行基准测试。 为此，请使用以下概要过程：
- 确定最常出现在生产工作负载中的 SQL 语句。
- 根据在第一个步骤中收集的信息，准备 SQL 语句的大型样本进行测试。
- 创建 Azure Database for MySQL 灵活服务器节点，并使用你的生产数据的副本填充它。
- 在 Azure 中启动 Azure 虚拟机 (VM) 客户端实例。
- 从 VM 中，针对 Azure Database for MySQL 灵活服务器实例运行 SQL 工作负载示例并评估结果。
生成测试有效负载（SQL 语句样本）的主要方法有两种：
- 观察/记录当前数据库中发生的 SQL 流量，然后根据这些观察结果生成 SQL 样本。 有关如何结合使用 Azure Database for MySQL 灵活服务器中的审核日志和慢速查询日志来记录查询流量的详细信息。
- 使用实际查询日志作为有效负载。 第三方工具（如“Percona Playback”）可以根据 MySQL 慢速查询日志生成多线程工作负载。
如果你要手动生成 SQL 样本，请确保该样本包含：
足够多的独特语句。
示例：如果你确定生产工作负载使用 15 种主要类型的语句，则样本总共包含 15 个语句（每种类型有一个语句）是不够的。 对于如此小的样本，数据库很容易将所需数据缓存在内存中，从而导致基准测试没有代表性。 应该为每种语句类型提供一个大型查询样本并使用以下附加建议。
不同类型的比例适当的语句。
示例：如果确定生产工作负载使用 12 种类型的语句，则某些类型的语句可能比其他类型的语句出现得更频繁。 样本应反映这些比例：如果查询 A 在生产工作负载中出现的频率是查询 B 的 10 倍，则它在样本中出现的频率也应该是查询 B 的 10 倍。
事实上随机化的查询参数。
如果你遵循了前面的建议并且查询样本包含相同类型/语法的查询组，则此类查询的参数应该随机化。 如果样本包含 100 万个相同类型的查询，并且它们全都相同（包括 WHERE 条件中的参数），则所需的数据将很容易缓存在数据库内存中，从而使得基准测试没有代表性。
事实上随机化的语句执行顺序。
如果你遵循了前面的建议并且测试有效负载包含许多不同类型的查询，则应以真实顺序执行这些查询。 例如，样本可能包含 1000 万个 SELECT 语句和 100 万个 UPDATE 语句。 在这种情况下，在所有 UPDATE 语句之前执行所有 SELECT 语句可能不是最佳选择，因为这可能不是应用程序在现实世界中执行查询的方式。 更有可能的是，应用程序交错使用 SELECT 和 UPDATE 语句，你的测试应该尝试模拟这种用法。
查询样本准备就绪后，使用命令行 MySQL 客户端或 mysqlslapv 等工具对服务器运行该样本。
运行测试
无论你是运行综合基准还是现实应用程序性能测试，都有一些经验法则可以遵循，以帮助确保取得更具代表性的结果。
针对多种实例类型运行测试
假设你决定对 db.r3.2xlarge 服务器运行基准测试并发现应用程序/查询性能已满足要求。 此外，建议针对较小和较大的实例类型运行测试，这可以带来两项好处：
- 使用较小的实例类型进行测试可能仍会产生良好的性能结果并找到潜在的成本节省机会。
- 使用较大的实例类型进行测试可能会提供有关将来可伸缩性选项的思路或见解。
度量可持续性能和峰值性能
所选的测试策略应该能够解答数据库是否可充分提供以下两种性能：
- 可持续性能 - 当用户流量平稳且保持预期水平时，数据库是否可在承受正常工作负载的情况下按预期方式执行？
- 峰值性能 - 数据库是否可以确保应用程序在流量高峰期间的响应能力？
遵循以下指南：
- 确保测试运行时间足够长，以评估稳定状态下的数据库性能。 例如，仅持续 10 分钟的复杂测试可能会生成不准确的结果，因为数据库缓存和缓冲区可能无法在如此短的时间内预热。
- 如果工作负载级别在整个测试过程中发生变化，则基准测试的结果可能更有意义且更具参考性。 例如，如果应用程序通常接收来自 64 个并发客户端的流量，则使用 64 个客户端开始执行基准测试。 然后，在测试仍在运行的同时，添加 64 个额外的客户端以确定服务器在模拟流量高峰期间的行为。
在基准测试过程中包括停电/掉电测试
持续的服务器性能是一个重要指标，可能会成为测试期间的主要关注点。 但是，对于任务关键型应用程序，性能测试不应局限于度量服务器在稳定状态下的行为。
考虑在测试中包括以下场景。
- “停电”测试旨在确定数据库在重启或崩溃期间的行为方式。 Azure Database for MySQL 灵活服务器在崩溃恢复时间方面引入了显著改进，重启/崩溃测试有助于了解 Azure Database for MySQL 灵活服务器如何帮助减少此类情况下的应用程序停机时间。
- “降功率”测试旨在衡量数据库在重启或崩溃后达到名义性能级别的速度。 数据库通常需要时间来实现最佳性能，Azure Database for MySQL 灵活服务器也引入了此方面的改进。
如果出现了影响数据库的稳定性问题，在性能基准测试期间收集的任何信息都有助于识别瓶颈或进一步优化应用程序以满足工作负载需求。