如果您对软件产品没有任何经验，您将如何帮助我解决问题？
准备好惊讶吧。
那个设定
这是性能工程师面临的典型挑战。这要么是生产性能问题类型的场景，要么是“我们即将投入生产，我们已经延迟发布一次”的场景。
了解产品的当地团队无法找到性能和稳定性问题的根本原因。他们已经找到了一些原因并针对新版本进行了更改。他们召集了 SWAT 团队进行分类和故障排除，并且他们每天两次报告故障排除进度的更新。团队中的一些成员以前经历过这种情况，而对于其他人来说，这是第一次。一个关键问题是获得产品供应商的全力支持，因为他们的主要技术架构师目前在六个时区之外。供应商很沮丧，因为他们不得不转移资源来解决不属于他们的问题。
不仅有核心软件产品，还有他们的合作伙伴系统集成商所做的一些定制。因此，可以这么说，有很多人和团体参与其中，每个人都有一匹马参加比赛，包括业务部门 CIO。
所讨论的系统很复杂——由 Web 服务器、具有自定义和现成代码的 Java 应用程序服务器、发送到第三方公司系统的消息以及一个大型数据库组成。接下来，让我们添加一两个虚拟机。团队继续关注每个组件；网络永远是他们最先去的地方。 Oracle Automatic Workload Repository Reports (AWR) 会被反复审查，然后偶尔会审查 Java 堆转储。有需要审查的来宾操作系统和需要审查的 VMware Hypervisor 指标。
在此过程中，团队在数据库中发现了一些索引问题并进行了更正。他们将一些表分隔到不同的表空间中。重新排列数据库已经很晚了。正在进行一项任务，以再次确认实际的基础设施配置，因为平台的状态似乎存在一些分歧。例如，数据库服务器应该有 32 个 CPU，现在好像有 24 个。他们需要升级一些组件以使其成为最新的，因为供应商说新的更新应该有所帮助。谁拥有配置管理数据库？
在这一点上，进展似乎停滞了。很多关键的业务交易都非常缓慢，还有一些是断断续续的慢。性能测试表明，只有第一波用户的响应会降低。第一波的工作负载消耗了所有系统资源。容量计划显示配置的系统有能力处理四波用户的工作负载。
进入性能工程师
高级性能工程师以前遇到过这种情况；他们一直处于困境。他们拥有使用许多不同系统的技术知识，并且具有开发或数据库管理的核心基础。他们拥有利用现有关键团队成员的知识找到根本原因所需的技能和技术。在 Collaborative Consulting（现为 CGI），我们的性能工程团队已经为根本原因分析项目创建了一种行之有效的方法。它们基于我们的软件性能工程知识体系，包括我们的五个知识领域； 1) SDLC 中的性能工程，2) 性能测试，3) 容量规划，4) 应用程序性能管理，以及 5) 问题检测和解决。
他们在使用不同的应用程序性能管理 (APM) 工具方面拥有广泛的经验。在当今复杂的环境中，APM 工具是 必不可少的 。将来自所有组件的不同日志拼接在一起的替代方案不是对资源和时间的有效利用。目标是使 RCA 过程尽可能自动化。 APM 工具还使您能够在下一个版本准备就绪时立即进行新的测量，从而实现前后比较。这压缩了验证更改所需的时间。
由经验丰富的性能工程师或技术架构使用的 APM 工具可以动态查看运行时环境，发现技术架构。这可以大大加快应用程序或系统的物理架构审查。从端到端的角度评估应用程序，从业务事务一直到数据库事务。
成功的 RCA 项目所需的第二个关键人物是平台技术方面的技术主题专家。此人必须具有使用 APM 工具的经验。在 Collaborative（现为 CGI），我们在用于 Java 和 Microsoft 环境的 Dynatrace 工具集方面取得了巨大成功。我们通常会在 RCA 项目中使用 APM 工具。
没有应用程序或供应商产品的经验
通常在快节奏的根本原因分析项目中，团队会投入感情并开始捍卫他们的代码或技术。引入外部性能工程师的好处是，他们可以成为中立的第三方，可以了解事实。正如他们所说，性能工程师在比赛中没有马。
性能工程师可以领导结果分析，定义计划和优先级，将技术细节传达给项目团队，并管理 RCA 流程。他们还可以帮助就成功标准应该是什么达成共识。通常，关键业务交易没有正式的性能响应时间目标，因此定义这些目标非常重要。如果不定义结束状态，怎么知道什么时候完成？性能工程师还将通过定义流程来衡量每个版本的性能，从而着眼于更大的图景。
了解技术环境是成功的关键。有了 Java 技术架构师和 APM 工具，性能工程师就可以开始跟踪事务以找到瓶颈。凭借 APM 工具的经验和知识，性能工程师可以告诉您哪些 Java 方法速度慢，他或她可以告诉您哪些 SQL 语句导致问题或耗时过长。他们可以找到被阻塞的线程并告诉您它们被阻塞的原因。您可以立即评估 Java 垃圾收集。他们可以告诉您出现网络带宽问题的位置。
然后绩效可以将研究分配给合适的团队；网络信息给网络团队，数据库观察给数据库团队，软件产品给软件团队，修改后的性能测试场景给性能测试团队。
对于每个业务事务，性能工程师可以映射给定工作负载下的整个调用堆栈，并将详细信息传递给软件供应商/产品团队。软件供应商将乐于了解导致速度放缓的事实和工作负载条件。然后软件供应商可以纠正问题并发送新版本。例如，在我们最近的一个项目中，产品供应商并不知道他们进行了 200 次 SQL 调用来创建订单。他们有一个产品错误，错误地调用了同一个过程十次，而实际上应该调用一次。
经验丰富的性能工程师提出问题；
- 为什么应用程序要在创建订单时更新所有这些表？
- 为什么要调用远程定价调用 3 次？
- 为什么要为同一客户或产品创建新对象？
- 为什么数据库连接处理程序要为固定数量的用户建立如此多的连接？
- 您是否期望您的用户/客户来自慢速无线连接？你测试了吗？
- 您是否意识到应用程序服务器位于一个数据中心而数据库位于另一个数据中心？
- 谁设置了 JVM 内存配置？
- 为什么索引和文件在同一个卷上？
- 性能测试数据库是生产数据库的四分之一。
- 您实际为数据库服务器分配了多少个物理 CPU？
- 峰体积是如何确定的？
这些促进了与产品技术团队的富有成效的深入对话。
所以，是的，有经验的性能工程师可以隔离并提供建议来解决他们以前没有经验的应用程序和产品的性能问题。然而，它需要适当的经验、适当的工具和知识渊博的地面团队才能成功。