开源团队聊天_开源性能工程团队生命中的一天

最新推荐文章于 2024-09-27 10:47:12 发布

cumo3681

最新推荐文章于 2024-09-27 10:47:12 发布

阅读量92

点赞数

文章标签：大数据 python 人工智能 java 编程语言

原文链接：https://opensource.com/article/19/5/life-performance-engineer

版权

开源团队聊天

在当今世界，开源软件解决方案是社区的共同努力。绩效工程团队是否可以通过与社区合作来解决使用广泛的产品所带来的困惑和复杂性，以相同的方式运作？

要回答该问题，我们需要探索一些基本问题：

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

术语“性能工程”具有不同的含义，这导致难以确定性能工程团队的职责。更令人困惑的是，一个团队可能要负责开发广泛的产品，包括像RHEL这样的操作系统，其性能可能会受到硬件组件（CPU缓存，网络接口控制器，磁盘技术等）的显着影响。，到像Kubernetes这样的堆栈中更高的东西，它伴随着在不影响性能的前提下进行大规模操作的额外挑战。

自运行手动A / B测试和单系统基准测试以来，性能工程已经取得了很大进步。现在，这些团队测试云基础架构，并将机器学习分类器添加为CI / CD管道中的组件，以识别产品版本中的性能下降。

绩效工程团队做什么？

绩效工程团队通常负责以下工作（除其他事项外）：

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

我们特定团队的任务是：

建立红帽产品组合的性能和规模领导地位；范围包括组件级别，系统和解决方案分析
与工程，产品管理，产品营销，客户体验和参与度（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运算符框架通过Kubernetes本地调用运行工作负载，以提供上述问题的解决方案。 Ripsaw的独特卖点是它可以在任何种类的Kubernetes发行版上运行，因此可以在Kubernetes集群，Minikube或部署在OpenStack或裸机上的OpenShift集群上运行。
ClusterLoader ：您是否想过OpenShift组件在不同的群集状态下将如何执行？如果您正在寻找可以使集群承受压力的答案，ClusterLoader将为您提供帮助。团队已经对该工具进行了通用化，因此可以与任何Kubernetes发行版一起使用。它当前托管在perf-tests存储库中。