开发者社区> 咖啡机(K.F.J)> 正文
阿里云
为了无法计算的价值
打开APP
阿里云APP内打开

从零开始搞监控系统(3)——性能监控

简介:   前端性能监控是个老话题了,各个团队都会对其有所关注,因为关注性能是工程师的本分。
+关注继续查看

  前端性能监控是个老话题了,各个团队都会对其有所关注,因为关注性能是工程师的本分。

  页面性能对用户体验而言十分关键,每次重构或优化,仅靠手中的几个设备或模拟的测试,缺少说服力,需要有大量的真实数据来做验证。

  在2016年,我就写过一篇《前端页面性能参数搜集》的文章,当时采用的还是W3C性能参数的第一版,现在已有第二版了。

  在2020年,根据自己所学整理了一套监控系统,代号菠萝,不过并没有正式上线,所以只能算是个玩具。

  这次不同,公司急切的需要一套性能监控系统,用于分析线上的活动,要扎扎实实的提升用户体验。

  整个系统大致的运行流程如下:


19.png


一、SDK


  性能参数搜集的代码仍然写在前面的监控 shin.js(SDK) 中,为了兼容两个版本的性能标准,专门编写了一个函数。


function _getTiming() {
  var timing =
    performance.getEntriesByType("navigation")[0] || performance.timing;
  var now = 0;
  if (!timing) {
    return { now: now };
  }
  var navigationStart;
  if (timing.startTime === undefined) {
    navigationStart = timing.navigationStart;
    /**
     * 之所以老版本的用 Date,是为了防止出现负数
     * 当 performance.now 是最新版本时,数值的位数要比 timing 中的少很多
     */
    now = new Date().getTime() - navigationStart;
  } else {
    navigationStart = timing.startTime;
    now = shin.now() - navigationStart;
  }
  return {
    timing: timing,
    navigationStart: navigationStart,
    now: _rounded(now)
  };
}


  其实两种方式得当的参数类似,第二版中的参数比第一版来的多,下面两张图是官方给的参数示意图,粗看的话下面两种差不多。


20.png

W3C第一版的性能参数


21.png


W3C第二版的性能参数

  但其实在将 performance.getEntriesByType("navigation")[0] 打印出来后,就会发现它还会包含页面地址、传输的数据量、协议等字段。

1)统计的参数

  网上有很多种统计性能参数的计算方式,大部分都差不多,我选取了其中较为常规的参数。


shin.getTimes = function () {
  //出于对浏览器兼容性的考虑,仍然引入即将淘汰的 performance.timing
  var currentTiming = _getTiming();
  var timing = currentTiming.timing;
  var api = {};     //时间单位 ms
  if (!timing) {
    return api;
  }
  var navigationStart = currentTiming.navigationStart;
  /**
   * 页面加载总时间
   * 这几乎代表了用户等待页面可用的时间
   * loadEventEnd(加载结束)-navigationStart(导航开始)
   */
  api.loadTime = timing.loadEventEnd - navigationStart;
  /**
   * Unload事件耗时
   */
  api.unloadEventTime = timing.unloadEventEnd - timing.unloadEventStart;
  /**
   * 执行 onload 回调函数的时间
   * 是否太多不必要的操作都放到 onload 回调函数里执行了,考虑过延迟加载、按需加载的策略么?
   */
  api.loadEventTime = timing.loadEventEnd - timing.loadEventStart;
  /**
   * 首次可交互时间
   */
  api.interactiveTime = timing.domInteractive - timing.fetchStart;
  /**
   * 用户可操作时间(DOM Ready时间)
   */
  api.domReadyTime = timing.domContentLoadedEventEnd - timing.fetchStart;
  /**
   * 白屏时间
   */
  var paint = performance.getEntriesByType("paint");
  if (paint && timing.entryType && paint[0]) {
    api.firstPaint = paint[0].startTime - timing.fetchStart;
  } else {
    api.firstPaint = timing.responseEnd - timing.fetchStart;
  }
  /**
   * 解析 DOM 树结构的时间
   * 期间要加载内嵌资源
   * 反省下你的 DOM 树嵌套是不是太多了
   */
  api.parseDomTime = timing.domComplete - timing.domInteractive;
  /**
   * 请求完毕至DOM加载耗时
   */
  api.initDomTreeTime = timing.domInteractive - timing.responseEnd;
  /**
   * 准备新页面耗时
   */
  api.readyStart = timing.fetchStart - navigationStart;
  /**
   * 重定向次数(新)
   */
  api.redirectCount = timing.redirectCount || 0;
  /**
   * 传输内容压缩百分比(新)
   */
  api.compression = (1 - timing.encodedBodySize / timing.decodedBodySize) * 100 || 0;
  /**
   * 重定向的时间
   * 拒绝重定向!比如,http://example.com/ 就不该写成 http://example.com
   */
  api.redirectTime = timing.redirectEnd - timing.redirectStart;
  /**
   * DNS缓存耗时
   */
  api.appcacheTime = timing.domainLookupStart - timing.fetchStart;
  /**
   * DNS查询耗时
   * DNS 预加载做了么?页面内是不是使用了太多不同的域名导致域名查询的时间太长?
   * 可使用 HTML5 Prefetch 预查询 DNS 
   */
  api.lookupDomainTime = timing.domainLookupEnd - timing.domainLookupStart;
  /**
   * SSL连接耗时
   */
  var sslTime = timing.secureConnectionStart;
  api.connectSslTime = sslTime > 0 ? timing.connectEnd - sslTime : 0;
  /**
   * TCP连接耗时
   */
  api.connectTime = timing.connectEnd - timing.connectStart;
  /**
   * 内容加载完成的时间
   * 页面内容经过 gzip 压缩了么,静态资源 css/js 等压缩了么?
   */
  api.requestTime = timing.responseEnd - timing.requestStart;
  /**
   * 请求文档
   * 开始请求文档到开始接收文档
   */
  api.requestDocumentTime = timing.responseStart - timing.requestStart;
  /**
   * 接收文档(内容传输耗时)
   * 开始接收文档到文档接收完成
   */
  api.responseDocumentTime = timing.responseEnd - timing.responseStart;
  /**
   * 读取页面第一个字节的时间
   * 这可以理解为用户拿到你的资源占用的时间,加异地机房了么,加CDN 处理了么?加带宽了么?加 CPU 运算速度了么?
   * TTFB 即 Time To First Byte 的意思
   * 维基百科:https://en.wikipedia.org/wiki/Time_To_First_Byte
   */
  api.TTFB = timing.responseStart - timing.fetchStart;
  //全部取整
  for (var key in api) {
    api[key] = _rounded(api[key]);
  }
  /**
   * 浏览器读取到的性能参数,用于排查
   */
  api.timing = timing;
  return api;
};


  所有的性能参数最终都要被取整,以毫秒作单位。兼容的 timing 对象也会被整个传递到后台,便于分析性能参数是怎么计算出来的。

  compression(传输内容压缩百分比)是一个新的参数。白屏时间的计算有两种:

  第一种是调用 performance.getEntriesByType("paint") 方法,再减去 fetchStart;第二种是用 responseEnd 来与 fetchStart 相减。

  loadTime(页面加载总时间)有可能为0,就是当页面资源还没加载完,触发 load 事件前将页面关闭。

  如果这种很多,那就很有可能页面被阻塞在某个位置,可能是接收时间过长、可能是DOM解析过长等。

  当这个页面加载时间超过了用户的心理承受范围时,就需要抽出时间来做各个方面的页面优化了。

2)首屏时间

  首屏时间很难计算,一般有几种计算方式。

  第一种是算出首屏页面中所有图片都加载完后的时间,这种方法难以覆盖所有场景,并且计算结果并不准。


/**
 * 计算首屏时间
 * 记录首屏图片的载入时间
 * 用户在没有滚动时候看到的内容渲染完成并且可以交互的时间
 */
doc.addEventListener(
  "DOMContentLoaded",
  function () {
    var isFindLastImg = false,
      allFirsrImgsLoaded = false,
      firstScreenImgs = [];
    //用一个定时器差值页面中的图像元素
    var interval = setInterval(function () {
      //如果自定义了 firstScreen 的值,就销毁定时器
      if (shin.firstScreen) {
        clearInterval(interval);
        return;
      }
      if (isFindLastImg) {
        allFirsrImgsLoaded = firstScreenImgs.every(function (img) {
          return img.complete;
        });
        //当所有的首屏图像都载入后,关闭定时器并记录首屏时间
        if (allFirsrImgsLoaded) {
          shin.firstScreen = _calcCurrentTime();
          clearInterval(interval);
        }
        return;
      }
      var imgs = doc.querySelectorAll("img");
      imgs = [].slice.call(imgs); //转换成数组
      //遍历页面中的图像
      imgs.forEach(function (img) {
        if (isFindLastImg) return;
        //当图像离顶部的距离超过屏幕宽度时,被认为找到了首屏的最后一张图
        var rect = img.getBoundingClientRect();
        if (rect.top + rect.height > firstScreenHeight) {
          isFindLastImg = true;
          return;
        }
        //若未超过,则认为图像在首屏中
        firstScreenImgs.push(img);
      });
    }, 0);
  },
  false
);


  第二种是自定义首屏时间,也就是自己来控制何时算首屏全部加载好了,这种方法相对来说要精确很多。


shin.setFirstScreen = function() {
  this.firstScreen = _calcCurrentTime();
}
/**
 * 计算当前时间与 fetchStart 之间的差值
 */
function _calcCurrentTime() {
  return _getTiming().now;
}
/**
 * 标记时间,单位毫秒
 */
shin.now = function () {
  return performance.now();
}


  之所以未用 Date.now() 是因为它会受系统程序执行阻塞的影响, 而performance.now() 的时间是以恒定速率递增的,不受系统时间的影响(系统时间可被人为或软件调整)。

  在页面关闭时还未获取到首屏时间,那么它就默认是 domReadyTime(用户可操作时间)。

3)上报

  本次上报与之前不同,需要在页面关闭时上报。而在此时普通的请求可能都无法发送成功,那么就需要 navigator.sendBeacon() 的帮忙了。

  它能将少量数据异步 POST 到后台,并且支持跨域,而少量是指多少并没有特别指明,由浏览器控制,网上查到的资料说一般在 64KB 左右。

  在接收数据时遇到个问题,由于后台使用的是 KOA 框架,解析请求数据使用了 koa-bodyparser 库,而它默认不会接收 Content-Type: text 的数据,因此要额外配置一下,具体可参考此处


/**
 * 在页面卸载之前,推送性能信息
 */
window.addEventListener("beforeunload", function () {
    var data = shin.getTimes();
    if (shin.param.rate > Math.random(0, 1) && shin.param.pkey) {
      navigator.sendBeacon(shin.param.psrc, _paramifyPerformance(data));
    }
  },
  false
);


  在上报时,还限定了一个采样率,默认只会把 50% 的性能数据上报到后台,并且必须定义 pkey 参数,这其实就是一个用于区分项目的 token。

  本来一切都是这么的顺利,但是在实际使用中发现,在 iOS 设备上调试发现不会触发 beforeunload 事件,安卓会将其触发,一番查找后,根据iOS支持的事件社区的解答,发现得用 pagehide 事件替代。

  以为万事大吉,但还是太年轻,在微信浏览器中的确能触发 pagehide 事件,但是在自己公司APP中,表现不尽如意,无法触发,若要监控关闭按钮,得发一次版本。

  无奈,只能自己想了个比较迂回的方法,那就是在后台跑个定时器,每 200ms 缓存一次要搜集的性能数据,在第二次进入时,再上报到后台。


/**
 * 组装性能变量
 */
function _paramifyPerformance(obj) {
  obj.token = shin.param.token;
  obj.pkey = shin.param.pkey;
  obj.identity = getIdentity();
  obj.referer = location.href; //来源地址
  // 若未定义或未计算到,则默认为用户可操作时间
  obj.firstScreen = shin.firstScreen || obj.domReadyTime;
  return JSON.stringify(obj);
}

/**
 * 均匀获得两个数字之间的随机数
 */
function _randomNum(max, min) {
  return Math.floor(Math.random() * (max - min + 1) + min);
}
/**
 * iOS 设备不支持 beforeunload 事件,需要使用 pagehide 事件
 * 在页面卸载之前,推送性能信息
 */
var isIOS = !!navigator.userAgent.match(/\(i[^;]+;( U;)? CPU.+Mac OS X/);
var eventName = isIOS ? "pagehide" : "beforeunload";
window.addEventListener(
  eventName,
  function () {
    sendBeacon();
  },
  false
);

var SHIN_PERFORMANCE_DATA = "shin_performance_data";
var heartbeat; //心跳定时器
/**
 * 发送数据
 */
function sendBeacon(existData) {
  // 如果传了数据就使用该数据,否则读取性能参数,并格式化为字符串
  var data = existData || _paramifyPerformance(shin.getTimes());
  var rate = _randomNum(10, 1); // 选取1~10之间的整数
  if (shin.param.rate >= rate && shin.param.pkey) {
    navigator.sendBeacon(shin.param.psrc, data);
  }
  clearTimeout(heartbeat);
  localStorage.removeItem(SHIN_PERFORMANCE_DATA); //移除性能缓存
}
/**
 * 发送已存在的性能数据
 */
function sendExistData() {
  var exist = localStorage.getItem(SHIN_PERFORMANCE_DATA);
  if (!exist) return;
  setTimeout(function () {
    sendBeacon(exist);
  }, 0);
}
sendExistData();
/**
 * 一个心跳回调函数,缓存性能参数
 * 适用于不能触发 pagehide 和 beforeunload 事件的浏览器
 */
function intervalHeartbeat() {
  localStorage.setItem(
    SHIN_PERFORMANCE_DATA,
    _paramifyPerformance(shin.getTimes())
  );
}
heartbeat = setInterval(intervalHeartbeat, 200);


二、存储


1)性能数据日志

  性能数据会被存储到 web_performance 表中,同样在接收时会通过队列来异步新增。


CREATE TABLE `web_performance` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `load` int(11) NOT NULL DEFAULT '0' COMMENT '页面加载总时间',
  `ready` int(11) NOT NULL DEFAULT '0' COMMENT '用户可操作时间',
  `paint` int(11) NOT NULL DEFAULT '0' COMMENT '白屏时间',
  `screen` int(11) NOT NULL DEFAULT '0' COMMENT '首屏时间',
  `measure` varchar(1000) COLLATE utf8mb4_bin NOT NULL COMMENT '其它测量参数,用JSON格式保存',
  `ctime` timestamp NULL DEFAULT CURRENT_TIMESTAMP,
  `day` int(11) NOT NULL COMMENT '格式化的天(冗余字段),用于排序,20210322',
  `hour` tinyint(2) NOT NULL COMMENT '格式化的小时(冗余字段),用于分组,11',
  `minute` tinyint(2) DEFAULT NULL COMMENT '格式化的分钟(冗余字段),用于分组,20',
  `identity` varchar(20) COLLATE utf8mb4_bin NOT NULL COMMENT '身份',
  `project` varchar(20) COLLATE utf8mb4_bin NOT NULL COMMENT '项目关键字,关联 web_performance_project 表中的key',
  `ua` varchar(600) COLLATE utf8mb4_bin NOT NULL COMMENT '代理信息',
  `referer` varchar(200) COLLATE utf8mb4_bin DEFAULT NULL COMMENT '来源地址',
  `timing` text COLLATE utf8mb4_bin COMMENT '浏览器读取到的性能参数,用于排查',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin COMMENT='性能监控';


  表中的 project 字段会关联 web_performance_project 表中的key。

2)性能项目

  性能项目就是要监控的页面,与之前不同,性能的监控粒度会更细,因此需要有个后台专门管理这类数据。


CREATE TABLE `web_performance_project` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `key` varchar(20) COLLATE utf8mb4_bin NOT NULL COMMENT '唯一值',
  `name` varchar(45) COLLATE utf8mb4_bin NOT NULL COMMENT '项目名称',
  `ctime` timestamp NULL DEFAULT CURRENT_TIMESTAMP,
  `status` tinyint(1) NOT NULL DEFAULT '1' COMMENT '1:正常  0:删除',
  PRIMARY KEY (`id`),
  UNIQUE KEY `name_UNIQUE` (`name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin COMMENT='性能监控项目';


  目前做的也比较简单,通过名称得到 16位MD5 字符串。 


22.png


三、分析


1)性能看板

  在性能看板中,会有四张折线图,当要统计一天的数据时,横坐标为小时(0~23),纵坐标为在这个小时内正序后处于 95% 位置的日志,也就是 95% 的用户打开页面的时间。

  这种写法也叫 TP95,TP 是 Top Percentile 的缩写,不用性能平均数是因为那么做不科学。

23.png


  过滤条件还可以选择具体的小时,此时横坐标为分钟,纵坐标为在这个分钟内正序后处于 95% 位置的日志。

  点击图表的 label 部分,可以在后面列表中显示日志细节,其中原始参数就是从浏览器中得到的计算前的性能数据。


24.png


  后面又增加了对比功能,就是将几天的数据放在一起对比,可更加直观的展示趋势。


25.png



2)定时任务

  在每天的凌晨 3点30 分,统计昨天的日志信息。

  本来是计划 web_performance_statis 表中每天只有一条记录,所有性能项目的统计信息都塞到 statis 字段中,并且会包含各个对应的日志。

  但奈何数据量实在太大,超出了 MySQL 中 TEXT 类型的范围,没办法塞进去,后面就只存储 id 并且一个项目每天各一条记录。

  数据结构如下,其中 loadZero 是指未执行load事件的数量。


{
  hour: {
    x: [11, 14],
    load: ["158", "162"],
    ready: ["157", "162"],
    paint: ["158", "162"],
    screen: ["157", "162"],
    loadZero: 1
  },
  minute: {
    11: {
      x: [11, 18, 30],
      load: ["157", "159", "160"],
      ready: ["156", "159", "160"],
      paint: ["157", "159", "160"],
      screen: ["156", "159", "160"],
      loadZero: 1
    },
    14: {
      x: [9, 16, 17, 18],
      load: ["161", "163", "164", "165"],
      ready: ["161", "163", "164", "165"],
      paint: ["161", "163", "164", "165"],
      screen: ["161", "163", "164", "165"],
      loadZero: 0
    }
  }
}


  还有个定时任务会在每天的凌晨 4点30 分执行,将四周前的 web_performance_statis 和 web_performance 两张表中的数据清除。

 

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
从零开始搞监控系统(7)——监控页面奔溃
  页面奔溃包含两种场景,第一种是浏览器在加载网页时遇到问题导致的奔溃,另一种是因为脚本渲染出错导致页面空白无内容的奔溃。
31 0
从零开始搞基建(3)——设计方案
  最近看了一篇文章,文章中提到在开发流程中包含一个设计方案的阶段,位于需求评审之后,用于描述自己对于该需求的实现思路、模块划分等相关考虑的点,可供今后自己或他人查阅。   目的就是在编码前理清思路,整体架构,查缺补漏,作为他人或自己的技术参考文档。   自己在项目开发的过程中,也曽有过这样类似的想法,但没有作者那样写的系统,也没有在团队中落地。   基于文章中的设计方案,自己做了点修改。设计方案包括4个部分:需求、调研、实现和复盘。
31 0
网络性能监控工具
本文研究全球及中国市场网络性能监控工具现状及未来发展趋势,侧重分析全球及中国市场的主要企业,同时对比北美、欧洲、中国、日本、东南亚和印度等地区的现状及未来发展趋势
47 0
10分钟彻底搞懂前端页面性能监控
前端页面性能是一个非常核心的用户体验指标。本文介绍阿里UC 岳鹰全景监控平台 如何设计一个通用、低侵入性、自动上报的页面性能监控方案。主要采用的是Navigation Timing API以及sendBeacon等方法。
2127 0
如何从零开始了解数据?
本文主要以零售为例,讲讲当要了解一个企业的数据时,需要了解什么,如何快速从“门外汉”到“门儿清”。
1378 0
进程监控树。
出自:http://blog.sina.com.cn/s/blog_96b8a1540101540i.html 一、 并不是简单的通过spawn在子进程启动函数中启动一个进程然后返回{ok, Pid}就可以让子进程拥有出错自动重启的功能。
585 0
+关注
咖啡机(K.F.J)
每天进步一点点 研磨生活的香甜
350
文章
0
问答
文章排行榜
最热
最新
相关电子书
更多
低代码开发师(初级)实战教程
立即下载
阿里巴巴DevOps 最佳实践手册
立即下载
冬季实战营第三期:MySQL数据库进阶实战
立即下载