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

39次阅读

共计 2301 个字符,预计需要花费 6 分钟才能阅读完成。

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

正文完
 0