开源性能工程团队的一天 | Opensource.com

与社区协作使性能工程能够解决在广泛的产品范围内工作时带来的困惑和复杂性。

在当今世界，开源软件解决方案是社区的协作成果。性能工程团队能否以同样的方式运作，通过与社区协作来解决在广泛的产品范围内工作时带来的困惑和复杂性？

要回答这个问题，我们需要探讨一些基本问题

性能工程团队是做什么的？
性能工程团队如何履行其职责？
如何开发或利用开源工具进行性能分析？

“性能工程”一词有不同的含义，这导致难以确定性能工程团队的职责。更令人困惑的是，一个团队可能负责处理范围广泛的产品，从像 RHEL 这样的操作系统（其性能可能受到硬件组件（CPU 缓存、网络接口控制器、磁盘技术等）的显着影响）到堆栈中更高层级的产品（如 Kubernetes），后者带来了在不牺牲性能的情况下进行大规模操作的额外挑战。

自手动 A/B 测试和单系统基准测试时代以来，性能工程已经取得了很大进展。现在，这些团队测试云基础设施，并将机器学习分类器作为 CI/CD 管道中的组件，用于识别产品发布中的性能回归。

性能工程团队是做什么的？

性能工程团队通常负责以下事项（以及其他事项）

识别潜在的性能问题
识别可能发生的任何规模问题
开发调整指南和/或工具，使用户能够充分利用产品
开发指南和/或与客户合作，以帮助进行容量规划
为客户提供产品不同用例的性能预期

我们特定团队的使命是

确立 Red Hat 产品组合的性能和规模领导地位；范围包括组件级别、系统和解决方案分析
与工程、产品管理、产品营销以及客户体验和互动 (CEE) 部门以及硬件和软件合作伙伴合作
交付面向公众的指南、内部赋能和持续集成测试

我们的团队通过以下方式履行我们的使命

我们与产品团队合作，设定性能目标并开发性能测试，以针对部署的这些产品运行，从而查看它们如何达到这些目标。
- 我们还致力于重新运行性能测试，以确保行为中没有回归。
我们开发开源工具来实现我们的产品性能目标，并将这些工具提供给产品衍生的社区，以重现我们所做的工作。
- 我们努力做到透明和开放，公开我们如何进行性能工程；分享这些方法和途径有利于社区，允许他们重用我们的工作，并通过利用他们使用这些工具贡献的工作使我们受益。

性能工程团队如何履行其职责？

履行这些职责需要与其他团队（如产品管理、开发、QA/QE、文档和咨询）以及社区进行协作。

协作使团队能够通过汇集团队成员多样化的知识和经验而获得成功。性能工程团队构建工具，以便在团队内部和社区内部分享他们的知识，从而进一步提升协作的价值。

我们的性能工程团队通过以下方式取得成功

协作： 对于我们的性能工程团队来说，团队内部 协作与团队之间 协作同样重要
- 大多数性能工程师倾向于通过工具、性能分析、系统知识、系统配置等方式在性能工程的一个或多个子学科中为自己创造一个利基市场。我们的团队由工程师组成，他们了解如何在整个产品堆栈中设置/配置系统，那些了解配置选项将如何影响系统性能的人，等等。我们团队的成功在很大程度上依赖于团队中性能工程师之间的有效协作。
- 我们的团队在 Red Hat 内的各个层级以及我们的产品所衍生的社区中与其他组织密切合作。
知识： 要了解配置和/或系统更改的性能影响，仅了解产品本身是不够的。
- 我们的团队拥有涵盖堆栈所有级别的性能知识
  - 硬件设置和配置
  - 网络和规模考量
  - 操作系统设置和配置（Linux 内核、用户空间堆栈）
  - 存储子系统 (Ceph)
  - 云基础设施 (OpenStack, RHV)
  - 云部署 (OpenShift/Kubernetes)
  - 产品架构
  - 软件技术（如 Postgres 数据库；软件定义网络和存储）
  - 产品与底层硬件的交互
  - 用于监控和完成可重复基准测试的工具
工具： 我们的性能工程团队的与众不同之处在于通过其工具收集的数据，这些数据有助于解决我们的产品部署环境中性能分析的复杂性。

如何开发或利用开源工具进行性能分析？

对于今天的性能工程团队来说，工具不再是奢侈品，而是必需品。由于今天的产品解决方案非常复杂（并且随着更多解决方案被组合起来以解决更大的问题而变得越来越复杂），我们需要工具来帮助我们以可重复的方式运行性能测试套件，收集有关这些运行的数据，并帮助我们提炼这些数据，使其变得可理解和可用。

然而，没有哪个性能工程团队是根据性能分析的完成方式来评判的，而是根据从这种分析中获得的结果来评判的。

这种紧张关系可以通过协作开发工具来解决。性能工程团队不能将所有时间都花在开发工具上，因为这会阻止其有效地收集数据。通过以协作方式开发其工具，团队可以利用社区的工作来取得进一步的进展，同时仍然产生他们将被衡量的结果。

工具是我们性能工程团队的支柱，我们努力使用上游已有的工具。当社区中没有可满足我们需求的工具时，我们构建了工具来帮助我们实现目标，并将它们提供给社区。开源我们的工具对我们帮助很大，因为我们收到了来自竞争对手和合作伙伴的贡献，使我们能够通过协作共同解决问题。

以下是我们团队贡献和依赖的一些工具

Perf-c2c： 您的性能是否受到 CPU 缓存中错误共享的影响？perf-c2c 工具可以通过帮助您检查检测到错误共享的缓存行，并了解访问这些缓存行的读取器/写入器以及发生这些访问的偏移量来帮助您解决此问题。您可以在 Joe Mario 的博客上阅读有关此工具的更多信息。
Pbench： 您是否在收集有关性能的数据时重复相同的步骤，但未能始终如一地执行？或者您是否发现很难与他人比较结果，因为您收集了不同的配置数据？Pbench 是一种尝试标准化性能数据收集方式的工具，以便更轻松地进行比较和历史回顾。Pbench 是我们工具工作的核心，因为大多数其他工具都以某种形式使用它。Pbench 是一把瑞士军刀，因为它允许用户运行 fio、uperf 或自定义的、用户定义的测试等基准测试，同时通过 sar、iostat 和 pidstat 等工具收集指标，从而标准化收集有关环境配置数据的方法。Pbench 提供了一个仪表板 UI，以帮助查看和分析收集的数据。
Browbeat： 您是否想在运行测试时监控 OpenStack 集群等复杂环境？Browbeat 是解决方案，其强大之处在于它能够在编排工作负载时收集有关 OpenStack 集群的全面数据，范围从日志到系统指标。Browbeat 还可以在用户手动或通过他们自己的自动化运行他们选择的测试/工作负载时监控 OpenStack 集群。
Ripsaw： 您是否想比较不同 Kubernetes 发行版在同一平台上的性能？您是否想比较部署在不同平台上的相同 Kubernetes 发行版的性能？Ripsaw 是一种相对较新的工具，旨在通过使用 Ansible operator 框架的 Kubernetes 原生调用来运行工作负载，从而为上述问题提供解决方案。Ripsaw 独特的卖点是它可以针对任何类型的 Kubernetes 发行版运行，因此它可以在 Kubernetes 集群、Minikube 或部署在 OpenStack 或裸机上的 OpenShift 集群上运行。
ClusterLoader： 有没有想过 OpenShift 组件在不同集群状态下的性能如何？如果您正在寻找可以压力测试集群的答案，ClusterLoader 将会有所帮助。该团队已经对该工具进行了通用化，因此它可以与任何 Kubernetes 发行版一起使用。它目前托管在 perf-tests 存储库中。