产品好不好，谁说了算？Sonar 提出分析的性能指标，帮助您轻松判断产品性能及表现

近日，Sonar 产品经理宣布了 Sonar 全新的、明确的分析性能指标，以更好地与其他有相同指标或结果的工具进行比较。

作为 SonarQube 授权合作伙伴，创实持续关注代码安全领域，为中国用户带来全球范围内的优秀工具和解决方案，帮助企业实现开发运营安全一体化。

在本文中，Sonar 产品经理 Alexandre Gigleux 详细解读了 Sonar 最新提出的性能指标、目前的指标完成进度，以及接下来的首要任务。

在此，我很自豪地宣布 Sonar 性能分析指标。一直以来，当用户讨论到 Sonar 分析性能时，会分为两种情况：

• 挑战：用户不断尝试突破极限，报告他们认为应改进的问题案例。

• 满意：由于用户已对要运行数小时且总是产生大量误报结果的 SAST 工具习以为常，他们对 Sonar 感到满意。

但无论是面对以上何种情况，我们都不知道该如何应对。因为最初我们在开始构建分析引擎时，脑海中没有明确的性能指标。方向尚不明确，是否达到指标这一命题就不成立。因此，在您告知我们性能还不够好的时候，我们并不清楚您的这些建议是否可取。

这就是为什么我们最终决定需要建立明确的性能分析指标：这样我们就不会将自己的产品与其它可能没有相同指标或结果的工具进行简单的比较，也不会主观地、从个人角度去评价分析“看起来”怎么样。

现在，我们可以明确地告知您可以从我们的产品中获得些什么，以及在标准化的条件下，分析项目所需要的时间。

那么，就让我们看看这些指标是什么，以及这些指标的实现情况。                     

第一次分析需要多长时间？

第一次分析应该理解为对一个分支的所有文件进行分析。当您在 SonarQube 或 SonarCloud 中加入新项目时，以及创建新分支时，这种情况都会发生。在这种情况下，您可以期待在不到几分钟的时间内就能看到项目的总体状态，具体几分钟则取决于项目规模：

根据在 SonarCloud 上的测量结果，我们的产品在处理 M、L 和 XL 类项目时都达标了——这些项目中的 95%是在指标时间范围内完成分析的。因为开始分析阶段的时间消耗，XS 和 S 类项目尚未达到要求。

代码变更分析需要多长时间？

代码变更分析发生通常在以下两种情况下发生：

• 创建一个 pull request 后，希望在合并前验证 PR 质量。

• 直接将文件提交到分支（主分支或其它分支），而未使用 pull/merge request 机制。

在这种情形下，我们自然地期望分析时间与变更集合的规模（添加或更新代码的数量）成正比，而不是像第一次分析那样需要等待相同的时间。

在这里，您可以期待在几分钟内看到您的项目、分支或 PR 更新后的质量关口（Quality Gate，也译作质量门），具体需要花几分钟则取决于代码更改的规模：

到目前为止，我们为实现这些指标做了哪些工作？

我们的新定义：一个项目可以包含多种编程语言。我们以项目中代码密度最大的语言来给项目命名，这让将一个特定的项目描述为 Java、TypeScript 或 PHP 项目变得很方便。

第一次分析执行时间

就 Java 目而言，我们对其总体分析性能进行了改进。与 SonarQube 9.3 相比，SonarQube 9.4 的 Java 分析速度平均提速 30%。一位测试了该版本的客户表示，他能够在不到 18 分钟的时间内分析一个 1M LOC 项目。这完全达到了我们的指标（<40 分钟），表明我们的产品已达到了良好的分析效果。

对于 Kotlin 项目，我们将分析性能提高了 10 倍，达到了性能指标。

就 C/C++项目而言，从 SonarQube 9.5 开始，我们默认的分析是多线程的。在这之前，它是一个可选选项，最新版本中我们将其改成了默认选项。通过此变动，分析中会分配到更多的 CPU，从而更容易达到预期的指标。

代码变更分析执行时间

对于 Sonar 所覆盖的许多语言，我们不需要从所有文件中收集信息来提高结果质量，这种情况下，只需要分析 pull request 涉及到的文件。从 2022 年 5 月 3 日起，这一功能可以从 SonarQube 9.3 和 SonarCloud 上获得。如果 pull request 中包含 CSS、HTML、XML、Ruby、Scala、Go、Apex、CloudFormation、Terraform、Swift、PL/SQL、T-SQL、ABAP、VB6、Flex 和 RPG 等代码的变更，则 pull request 的分析效率通常会得到一些改善。

对于主体是 Java 代码的 pull request，由于我们不再需要对整个项目级的数据进行分析，而只针对更改文件执行分析，所以速度还会再提升 8-25%。

总的来说提升了，但是我们还未达到我们代码变更分析时长的指标。          

接下来，我们要做什么？

作为我们的首要任务，我们希望优化 Java 项目的 pull request 分析时间。我们将借助存储项目级数据的新缓存机制实现这一点，这将确保我们的分析结果拥有较高的准确性。为什么首先优化 Java？因为 Java 是 Sonar 支持的第一种语言，也是被我们用户使用最多的一种语言。此外，Sonar 的开发人员使用了大量 Java，因此我们能够在发布前轻松发现问题。

接下来，我们将借助同一缓存系统优化分支的代码更改分析。

当运行稳定后，我们会将其扩展到 JS/TS、PHP、Python 和 COBOL 等语言。

想要体验 SonarQube 或试用 SonarCloud，请联系 SonarQube 中国官方授权合作伙伴——创实 ，我们提供 SonarQube 产品的咨询、销售、 实施、培训及技术支持服务。

作者简介：

ALEXANDRE GIGLEUX

产品经理

文章来源：https://blog.sonarsource.com/sonars-analysis-performance-targets/