Alluxio 压力测试的方法与实践

一、压力测试目的

　　1. 压力测试的目的

　　（1）确定配置和参数对性能的影响

　　检查影响性能的关键配置是否正确。如：Alluxio 计算内存JVM大小；Worker缓存容量等。

　　检查可调参数的值是否最优。如：根据用户使用场景，确定最佳读写方式。

　　若对数据持久性比较敏感的场景，建议使用CACHE_THROUGH方式同步写入UFS，避免数据丢失；若对临时文件、中间文件等使用场景，建议使用MUST_CACHE或ASYNC_THROUGH方式异步写入UFS，获取最佳写入速度。

　　若对于热数据读取的场景，建议使用CACHE或CACHE_PROMOTE方式，将数据读取至缓存中；若对于冷数据读取的场景，建议使用NO_CACHE，减少对缓存影响。

　　（2）确定系统性能的安全边界

　　确定系统能够稳定运行的最大外部压力。如：随着请求数量增加，系统吞吐量会逐渐稳定，但延时会增加，说明系统接近饱和状态。当进一步增加请求数量，出现吞吐量减少，延时继续增加的情况，说明系统已经超出安全边界。当明确安全边界后，在运维中，可通过监控及时发现系统达到安全边界的情况，此时可进行队列缓存、抛弃请求操作，保证系统稳定性。

　　（3）模拟压力过大情况下的失控状态

　　预演系统崩溃的情形，制定应急方案。

　　确定异常状态的恢复机制是否正常工作。如：Alluxio多Worker机制，当Client发现当前Worker Crash后，会向其他Worker发送请求。Master Crash时可通过HA机制，切换至Standby Master，防止集群失去响应能力。

　　非压力测试的目的：

　　·系统的行为是否符合预期。

　　· 功能是否满足需求。

　　· 与外部组件是否能够协同工作。

　　2. Alluxio中压力的来源

　　（1）客户端的请求

　　对于Master，是元数据相关操作，如：创建、删除文件。

　　对于Worker，是Alluxio缓存的数据读写操作。

　　对于UFS，是底层数据的读写操作。

　　（2）Alluxio内部的异步和周期性任务

　　异步持久化，启动异步任务将数据写入UFS中。

　　副本数检查，周期性检查副本数是否满足用户设定范围。

　　Worker状态报告，周期性向Master上报Worker上文件块的增减，存储容量的增减。

　　存储健康检查，存储设备失效时，需要向Master汇报。

　　（3）规模

　　Alluxio集群管理的文件数量。当集群文件数量较大时，对Master的元数据管理会造成较大压力。

　　Alluxio集群的Worker数量。在大集群中，大量Worker向Master汇报状态时，会对Master造成比较大的压力。

　　3. Alluxio中压力的具体表现形式

　　· 并发量。如：客户端同时发送大量请求、在Alluxio内部同时发起的异步任务、Worker同时对Master进行注册操作。该场景下瓶颈在于CPU或内存。

　　· 数据量。如：大流量的读或写。该场景下瓶颈在于存储介质和网络。

　　· 复杂度。复杂文件系统操作，如递归删除目录等。该场景下瓶颈在于CPU或内存。

　　Alluxio作为计算应用和底层存储之间的中间件，Alluxio的性能通过计算应用的性能而体现。这导致不同类型的计算应用在Alluxio上部署时，需要有不同的性能衡量方式。

　　如使用Presto+Alluxio时，使用TPC-DS等性能评估框架，获取QPS、查询复杂度、Presto I/O等性能指标。

　　再比如AI等工作负载场景，使用fio等评估工具，获得IOPS、数据吞吐量等性能指标。

　　因为不同类型的计算应用使用Alluxio方式不同，导致获得的性能指标不能直接进行比较。而且Alluxio和计算应用各自都是十分复杂的系统，各自有一系列的调优选项，如果将计算应用也作为压测对象一部分，则可能由于计算应用本身达到瓶颈，无法真正测试Alluxio的性能边界。

　　因此，Alluxio提供一套内置的压测框架。

　　二、Alluxio内置的压测框架

　　1. 基本概念

　　（1）压测操作

　　Alluxio支持的某一文件系统操作，其性能表现具有代表性。如创建文件，读取数据块时，内置压测框架会收集单次操作耗时作为原始数据。

　　（2）压测任务

　　指在一定的压测参数下重复执行单个或一组预定义的压测操作。如：向Master请求创建100万个文件，向Worker请求读取1GB的文件块。压测任务将会被封装为Job Service的执行单元，可以通过Job Worker执行。

　　压测任务结果即是本次任务计算汇总的统计数据，如：吞吐量、延迟平均值、中位数等。

　　2. 压测运行模式

　　Alluxio压测框架，支持两种基本的运行模式：集群模式、单机模式。

　　（1）集群模式（--cluster）

　　· 通过Job Service分发压测任务到Job Worker。

　　· Job Worker模拟客户端，向被测组件发起请求。

　　· Job Worker收到被测组件响应后，向Job Master报告压测结果。

　　· 可根据设置的压力参数，控制并发量和数据量。

　　集群模式优点在于可以极大地提高可模拟的并发量，但缺点在于出错时不易debug。

　　（2）单机模式

　　用户在当前节点提交压测任务，运行压测任务的节点直接向被测组件发起请求。

　　可根据设置的压力参数，控制并发量和数据量。

　　单机模式优点在于不依赖Job Service，使用简单，易于debug。但缺点在于并发量受限于单节点的计算能力。

　　3. 压测结果结算方式

　　（1）基于时间（--duration）

　　指设置压测运行的目标时长，在运行过程中反复执行压测操作，直到时间达到目标时间。根据该时间段内记录的操作次数，计算吞吐量。

　　基于时间是比较常见的压测结果计算方式。

　　（2）基于次数（--stop-count）

　　指设置压测操作的次数，反复执行压测操作，直到到达目标次数。根据确定的次数和记录完成这些操作所需时间，计算吞吐量。

　　基于次数的压测结果计算方式更适用于以数据量为变量的压测方案，如测量文件数量对性能的影响。也可用作某些测试中生成测试文件的步骤。

　　4. 压力测试结果报告

　　当压测操作完成时，压测工具会记录每次操作的耗时。

　　当压测操作发生错误时，会记录错误原因。

　　会基于耗时数据计算吞吐量、延迟的平均值、中位数、最大值等统计信息。

　　每个Job Worker会向Job Master汇报结果。Job Master汇总数据后发送报告给用户，压测报告会附带并压测相关配置参数，方便用户进行数据对比。

　　5. 压测工具分类

　　目前压测工具分为7类：

　　·Master：StressMasterBench, MaxFileBench, MasterMaxThroughput

　　· Worker：StressWorkerBench

　　· Job Service：StressJobServiceBench

　　· UFS：UfsIOBench

　　· FUSE：FuseIOBench

　　· Client：StressClientBench, CompactionBench

　　· RPC：WorkerHeartbeatBench, RegisterWorkerBench, GetPinnedFileIdsBench

　　压测工具举例：

　　（1）StressMasterBench

　　测量Master处理元数据操作在压力下的性能。支持以下操作：

　　· 支持指定操作类型，如创建文件、获取文件信息、删除文件等

　　· 支持指定读写类型(MUST_CACHE、CACHE_PROMOTE等)

　　· 支持指定客户端线程数量

　　· 支持指定文件或目录数量

　　· 支持覆盖默认客户端配置

　　（2）CompactionBench

　　模拟一个实现文件合并功能的简单应用的IO操作，并从客户端的角度测量性能，即测量的耗时中同时包含与Master和Worker交互的耗时。具体包括以下步骤：

　　· 创建一个临时文件

　　· 依次读取输入文件，将数据写入到临时文件

　　· 重命名临时文件为输出文件

　　· 删除所有输入文件

　　支持以下操作：

　　· 支持指定合并比例

　　· 支持指定文件大小和数量

　　· 支持指定线程数量

　　· 支持指定读写类型

　　三、使用Alluxio压测工具

　　1. 压测工具运行方式

　　Alluxio压测工具位于alluxio.stress.cli包内，部分位于对应的子包内。

　　用户可以通过alluxio命令行运行所需的压测类，步骤如下：

　　第一步，进入Alluxio的安装目录；

　　第二步，运行bin/alluxio runClass 

　　alluxio.stress.cli.StressMasterBench等。

　　用户也可通过执行--help查看可用选项和帮助。

　　2. 常见问题

　　（1）压测运行超时。常见原因有压测规模过大，在默认的压测超时时间（20分钟）内无法获取结果导致超时。针对这种情况，建议设置更长的超时时间，或缩小压测规模。

　　（2）所有压测操作均出错（没有有效的吞吐量数值）。需要根据错误信息判断错误原因并修复。常见原因有配置错误、网络连接错误导致客户端无法连接Master等。

　　（3）部分压测操作出错。在部分压测途中出现异常，前面操作成功但后续操作失败。常见原因有Master等组件遇到内存资源紧张，进入长时间GC，导致客户端等待结果超时。

　　3. Debugging

　　针对上述压测问题，用户可以开启debug log，从而查看详细的debug日志。

　　单机模式下，debug log位于运行压测工具的节点的logs/user/<username>.log文件中，通过该文件可查看压测工具日志。

　　集群模式下，debug log位于各Job Worker节点的logs/user/<username>.log文件中，通过该文件可查看Job Worker上执行压测操作的日志。或在job_master.log和job_worker.log中查看Job Service分配压测任务产生的日志。

感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：

这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取