当前位置:网站首页>产品好不好,谁说了算?Sonar提出分析的性能指标,帮助您轻松判断产品性能及表现

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

2022-07-05 20:39:00 龙智—DevOps解决方案

近日,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/

原网站

版权声明
本文为[龙智—DevOps解决方案]所创,转载请带上原文链接,感谢
https://blog.csdn.net/weixin_49715102/article/details/125598174