性能分析

作者：旷视 MegEngine 架构师 张孝斌疾速理解 mperf在挪动/嵌入式平台，为了最大水平施展硬件算力，对算子极致性能的谋求变成必然，不同于桌面/服务器平台，挪动/嵌入式平台在算子性能调优方面可抉择的工具很少。 MegEngine 团队始终在摸索什么样的工具可能在算子调优流程中带来助益，来帮忙达成如下的算子性能调优反馈回路，这也是 mperf 诞生的背景。 <p align=center><img src="https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/db65dd714a724afd943a3860cc041974~tplv-k3u1fbpfcp-zoom-1.image" alt="图1 算子性能调优反馈回路" /></p><p align=center>图1 算子性能调优反馈回路</p> mperf 是一个微架构档次的算子性能调优工具箱，次要面向挪动/嵌入式平台的 CPU/GPU 外围，指标是“为构建一个更靠近闭环的算子调优反馈回路”提供系列根底工具。 外围性能： [根底能力] 测试微架构档次的各类罕用性能剖析参数（GFLOPS/Multi-level Bandwidth/Latency...）[根底能力] 提供 PMU（Performance Monitoring Unit） 数据获取能力[性能剖析] 绘制 Hierarchical Roofline[问题定位] 加工 PMU 数据失去各种指标（如 IPC, Instructions per cycle）、TMA（Top-Down Microarchitecture Analysis Method）剖析能力，能够作为局部 vendor 提供的 GUI 剖析工具的平替[优化指引] 提供 OpenCL Linter 计划（后续版本提供）...作为一个 C++ API 级别的工程，mperf 内部依赖少，能够简略不便（侵入式）集成到指标工程中，目前曾经开源到 GitHub，欢送大家试用交换。 应用办法参考 README 文档；疾速上手指南见 Tutorial 文档 对 mperf 的实现原理感兴趣的同学，能够持续往下看~~ 开展说说 mperf 的工程实现缘起算子调优目前还是一个难以闭环的工作，须要开发者对指标硬件架构个性、算子优化程度评估、性能瓶颈定位、丰盛的优化技巧等都有很深的理解之后能力变得熟能生巧。同时随着 CPU/GPU 架构越来越多，越来越简单，一般的开发者很少有精力去深刻了解各个架构的个性，问题变得更加辣手。 现实中的调优过程是可能造成如上图所示的闭环，甚至能够走向编译器全自动化调优计划，过程中往往须要依赖工具实现，在桌面/服务器平台的工具较为齐备，如 linux perf, lmbench/stream，NVIDIA NSight Compute，Intel vtune/Advisor/pmu-tools 等开闭源工具等都提供了一部分能力，通过人为组合还是能失去比拟全的能力；与此同时，在挪动/嵌入式平台，也有 simpleperf、Arm mali streamline、snapdragon profiler、MegPeak、ArchProbe、HWCPipe 等优良的开闭源工具，然而齐备性和易用性方面都存在很多问题： ...

上篇文章A-Ops性能火焰图——实用于云原生的全栈继续性能监测工具分享了A-Ops性能火焰图的个性。 本文将分享基于A-Ops性能热点火焰图进行性能诊断的2个理论案例，介绍如何应用火焰图疾速定位系统或者利用的性能问题，加深大家对A-Ops火焰图个性的了解。 案例1 云原生场景下Java类利用性能问题诊断 1. 场景及案例介绍 某Kafka producer客户端Java利用版本升级后性能呈现降落，性能从222W TPS降落到65W TPS，吞吐量从337MB/s降落到95.9MB/s，如下图所示（为了便于比拟，在不同POD里同时启动降级前后的两个利用）： 可见，Kafka 客户端利用的性能呈现了显著的降落，但此时Kafka服务端较轻载，CPU 0.7%，内存16.8%，阐明性能劣化是因为客户端利用的问题导致。Kafka服务端资源状况如下： 2. 性能问题诊断 通过降级前后的火焰图比拟能够看出，降级后的CPU性能次要耗费在字符串format处理函数上。对于Kafka生成端利用，个别存在大量字符串操作，而字符串处理函数format性能较低，与StringBuilder办法相比有几倍甚至几十倍的性能差距，可见字符串format函数是导致性能升高的次要起因。 案例2 CPU抖动类性能故障诊断案例 1. 场景及案例介绍 在生产环境中常常会遇到一些偶发性的CPU抖动问题，这会对利用的性能造成肯定的影响，但因为没有必然的法则，故障发现及问题定位比拟难。 2. 性能问题诊断 为了模仿上述偶发性的故障，咱们通过iperf打流注入2分钟的故障，而后从多个角度剖析故障注入前后火焰图的数据，进而对CPU抖动类性能故障进行诊断。 在10:36-10:38通过 iperf3注入2分钟的流量，命令如下： iperf3 -c 192.168.122.115 -p 5201 -i 10 -t 120 -P 100 -N -M 100 -b 10000M流量注入前后，零碎利用指标及火焰图如下图所示： 从上图可见，流量注入期间，CPU使用率从均匀22%升高到33%，利用性能从232w tps降落到215w tps，火焰图中iperf3过程对CPU的占用为8.96%。 咱们能够通过火焰图比拟视图进一步剖析这个问题，下图右边的火焰图是注入故障前的火焰图，左边为注入故障期间的火焰图，比照能够看到故障注入期间多个iperf3这个过程。 另外，咱们还能够通过火焰图diff视图来剖析这个问题，参考下图，火焰图红色局部为故障注入期间新减少的过程，进而能够定位到iperf3是造成这次CPU抖动以及利用性能劣化的根因。 通过A-Ops性能热点火焰图，开发者和维护者能够很不便地预测潜在问题和定位已产生问题。 装置A-Ops性能热点火焰图 gala-ops是针对云基础设施灰度故障的利用级/零碎级在线诊断工具，火焰图探针stackprobe集成在其中的gala-gopher组件内，用户只需一键装置gala-gopher后，在配置文件中开启或敞开火焰图探针即可应用。 A-Ops装置部署手册： https://gitee.com/Vchanger/a-... gala-gophe组件装置部署阐明： https://gitee.com/openeuler/g... 欢送大家应用A-Ops性能热点火焰图，也欢送大家交换和反馈意见

写作背景： 领有一个良好用户体验的网页对于前端开发同学来说是一件必须做，继续做的一件事件，其中首屏的渲染尤为重要，因为用户与网页产生的交互就是从首屏开始的。接下来将介绍网页性能的几个指标以及如何计算和度量这些指标，通过监控和优化这些性能数据来继续优化网页，以进步用户体验。 Navigation Timing API： 咱们先来看一组 API，Navigation Timing API 提供了用来掂量一个网站性能的数据指标。相比于咱们传统的根底伎俩应用这组 API 能够获取更有用、更准确的数据还能够做更多的数据统计。Navigation Timing API 的兼容性也是相当的不错，兼容咱们当初罕用的浏览器，包含让人厌恶的 IE9+。残缺的兼容性表见链接： 资源加载过程：当咱们的一个资源发动拜访（navigationStart）后到资源实现加载（loadEventEnd）经验如下过程： ① 首先就是当资源须要重定向的时候会进入 redirect阶段，不须要重定向将会跳过这个阶段；② 接着就会查看资源是否有HTTP缓存的存在，当资源没有缓存的状况下回进入下一步；③ DNS 寻址的过程；④ TCP 协定握手建设通信；⑤ 发动申请；⑥ 响应资源；⑦ 对响应的内容进行解决，如：对 DOM 资源加载并解析；⑧ 最初一步实现资源加载。 上面这张图将是对这个过程的规范形容，也是一道前端经典面试题的标准答案，你懂得~ [](https://www.w3.org/TR/navigat...) 上图是W3C第一版的 Navigation Timing 的解决模型(Level 1)，从以后浏览器窗口卸载旧页面到加载实现新页面，整个过程一共分为 9 个阶段： 提醒卸载旧文档重定向/卸载利用缓存DNS 解析TCP 握手HTTP 申请解决HTTP 响应解决DOM 解决文档装载实现 Level 1 的标准从2012 年底进入候选倡议阶段应用已将近10年之久，也算实现了其历史使命，往年的3月20(2022年3月10日)正式进入Level2的标准( WorkingDraft )，Level2相比拟Level1精度更高。 Level2解决模型如下： Level2将整个过程划分为了11个阶段，各阶段指标明细： 序号指标解释1navigationStart示意从上一个文档卸载完结时的unix工夫戳，如果没有上一个文档，这个值将和fetchStart相等。2unloadEventStart示意前一个网页（与以后页面同域）unload的工夫戳，如果无前一个网页unload或者前一个网页与以后页面不同域，则值为0。3unloadEventEnd返回前一个页面unload工夫绑定的回掉函数执行结束的工夫戳。4redirectStart第一个HTTP重定向产生时的工夫。有跳转且是同域名内的重定向才算，否则值为0。5redirectEnd最初一个HTTP重定向实现时的工夫。有跳转且是同域名外部的重定向才算，否则值为0。6fetchStart浏览器筹备好应用HTTP申请抓取文档的工夫，这产生在查看本地缓存之前。7domainLookupStartdomainLookupEndDNS域名查问开始/完结的工夫，如果应用了本地缓存（即无DNS查问)或长久连贯，则与fetchStart值相等。8connectStartHTTP(TCP)开始/从新建设连贯的工夫，如果是长久连贯，则与fetchStart值相等9connectEndHTTP(TCP)实现建设连贯的工夫（实现握手），如果是长久接，则与fetchStart值相等。10secureConnectionStartHTTPS连贯开始的工夫，如果不是平安连贯，则值为0。11requestStartHTTP申请读取实在文档开始的工夫（实现建设连贯），包含从本地读取缓存。12responseStartHTTP开始接管响应的工夫（获取到第一个字节），包含从本地读取缓存。13responseEndHTTP响应全副接管实现的工夫（获取到最初一个字节），包含本地读取缓存。14domLoading开始解析渲染DOM树的工夫，此时Document..readyState变为loading,并将抛出readystatechange相干事件。15domlnteractive实现解析DOM树的工夫，Document..readyState变为interactive,并将抛出readystatechange相干事件，留神只是DOM树解析实现，这时候并没有开始加载网页内的资源。16domContentLoadedEventStartDOM解析实现后，网页内资源加载开始的工夫，在DOMContentLoaded事件抛出前产生。17domContentLoadedEventEndDOM解析实现后，网页内资源加载实现的工夫（如JS脚本加载执行结束)18domCompleteDOM树解析实现，且资源也准备就绪的工夫，Document..readyState变为complete,并将抛出readystatechange相干事件。19loadEventStartload事件发送给文档，也即load回调函数开始执行的工夫。20loadEventEndload事件的回调函数执行结束的工夫。计算页面加载的总时长： Navigation Timing API 为 window下挂的 Performance 对象减少了timing 和 navigation 属性，通过window.performance.timing能够失去 PerformanceTiming 接口，咱们能够应用接口外面提供的loadEventEnd减去navigationStart失去页面加载总的时长。 ...

最近在写一些货色的时候，把一些内容整顿了一下。在思考压力工具中的用户数（有些工具中称为线程数，本文后续都用“用户数”来阐明）、响应工夫、TPS三者之间的关系时，想到之前也有人问起过这样的问题，就是他们三者之间的共生的关系到底是什么样呢。这个公式我想谁都能晓得了：TPS = （ 1 / RT ) * user (其中，RT单位是秒，user是用户数) 先来画一下最简略的图（假如前提：每个user的事务定义都是统一的。）：当有五个用户时，响应工夫都稳固放弃在0.2s，那这个场景的TPS显然是：TPS = （1/0.2)*5 = 25这是最简略的计算了。 （兴许你会说：“咳，不对，因为线画歪了！” 你过去，我保障揍不你。） 这个看似简略的公式，在理论的场景中却是会呈现千奇百怪的后果。因为大部分的场景都不会如此规整，例如：这种状况下怎么计算TPS呢：TPS = 2 + 4 + 6 + 4 + 1 = 17显然响应工夫也是变动较大的，可能每个用户的每个事务的响应工夫都是不一样的。在实在的场景中，这样的状况是必然会呈现的，所以在计算TPS的时候，压力工具采纳的是：先采集原始数据。即每个用户每个事务都记录下来。再依据粒度计算。TPS散点值 = 事务数 / 粒度这样的计算结果再通过曲线体现进去。就会受几个因素的影响：用户数、粒度、响应工夫。当粒度过大时，就会均匀掉毛刺的影响；当粒度过小时，就会产生过多的事务点，让人抓狂。 那到底什么样的TPS和响应工夫是让人称心的呢？像这样吗？响应工夫随用户数回升而回升，TPS达到下限后变平；这显然不是让人称心的曲线，因为咱们心愿的是响应工夫不要减少那么快。那这样的曲线呢？响应工夫有减少，然而减少的趋势并不快，TPS也始终有减少的趋势，这就显然零碎还有容量的空间，就看性能指标该如何确定了。 咱们如许心愿这三者的关系像这个图呀。响应工夫素来没有减少过，TPS始终在减少，零碎性能在测试范畴内没有衰减。当然，这是不可能的。通常状况下，咱们都要面对更简单点的场景。如下图：在这个非常简单的场景下，咱们也看到了响应工夫无理的跳动。还好幅度并不大。所以才保障了TPS在每个不同的用户梯度下绝对的稳固。然而显然前面TPS曾经达到下限了，响应工夫开始减少得十分快。对于这样的场景来说，曾经算是十分清晰的用户数、TPS、RT的关系了。而对于一些这三者关系基本找不到的性能场景，首先要做的就是要把场景判断清晰，让曲线变得稳固，再判断瓶颈，而后才是定位瓶颈及剖析根本原因。想让曲线变得稳固，就波及到场景的执行策略了。递增用户和场景的连续性是肯定要保障的，只是梯度要依据理论的状况来判断。 明天先聊这么多，当前碰到有人问相似的问题再接着聊。