记一次微信小程序页面加载慢的排查过程

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了记一次微信小程序页面加载慢的排查过程相关的知识,希望对你有一定的参考价值。

参考技术A 公司新上线了一个微信小程序,在测试环境以及小程序体验版上测试一切正常,但上线之后,页面加载尤其慢。

经过运维排查,所有的请求到达服务器后均在1s内处理完成并响应,偶尔有2-3s的请求,极少。

既然服务端处理请求没有问题,那么,加载可能出现在小程序本身或网络延迟,但后者可能性较低。于是,使用fiddler抓包,其中一个加载较慢的请求结果如下:

关键时间节点如下:

· 客户端与服务器完成tcp链接时间是11:31:35(时分秒)
· 客户端开始向服务端发送请求的时间是11:31:36(时分秒)
· 服务端接收到请求的时间是11:31:36(时分秒)
· 服务端开始响应的时间是11:31:46(时分秒)

也就是说,从服务器接收到请求到开始响应耗时10s,可这跟运维查看的日志结果不符!

鉴于上面的抓包结果和生产日志结果相悖,决定使用curl对耗时较长的http请求进行分析。

运行结果如下

对应的结果含义如下:

· time_namelookup :DNS 域名解析的时候,就是把 https://zhihu.com 转换成 ip 地址的过程
· time_connect :TCP 连接建立的时间,就是三次握手的时间
· time_appconnect :SSL/SSH 等上层协议建立连接的时间,比如 connect/handshake 的时间
· time_redirect :从开始到最后一个请求事务的时间
· time_pretransfer :从请求开始到响应开始传输的时间
· time_starttransfer :从请求开始到第一个字节将要传输的时间
· time_total :这次请求花费的全部时间

那么对应的时间点应该是:

· DNS解析耗时:0.005s
· TCP建立连接的耗时:0.035-0.005=0.03s
· SSL握手完成耗时:3.8-0.034=3.7s
· server处理数据的时间:3.8402-3.8401=0.0001s
· 总体的耗时:14.5s

emmm,按照这个结果来看,从服务器开始响应到传输完成一共耗时14.5-3.8=10.7s。
那么这里问题又来了,这结果跟fiddler的结果完全相反,到底是在哪个环节出了问题?

fiddler的结果显示从服务器接收到请求到开始响应耗时10s,是服务器处理请求消耗了10s;而curl显示服务器处理请求只用了0.0001s,响应开始到结束耗时10.7s。到底哪个是对的,难道是根据本身有问题?
于是在跟运维同事一波交流之后,得到请求流转过程如下:

客户端<---------->CDN服务器<---------->nginx代理<---------->应用服务器<---------->DB

弄清请求流转过程之后,手动发送请求,实时查看Nginx和应用服务器日志,发现请求发出后,间隔一段时间(10s左右)Nginx日志才有输出,接着很快App Server日志也有输出(包括请求和响应)。事实就摆在眼前,是CDN服务器<---------->Nginx代理之间出现了问题,具体是为什么目前还不清楚。
那么fiddler和curl抓包的结果如何解释?
fiddler:从服务器接收到请求到开始响应耗时10s,是正确的。
curl:服务器处理请求只用了0.0001s,响应开始到结束耗时10.7s。这里就有问题了,要想解释得通,只能说time_pretransfer和time_starttransfer是CDN服务器的响应时间,由于配置了CND,在向小程序应用服务器发送请求时,会先请求到CDN服务器此时CDN服务器很快就响应了客户端的请求,但CDN服务器在转发请求到Nginx代理时出现了延迟,因此在curl的请求结果中才会看起来像是响应开始到响应结束耗时较长。

至于为什么请求从CND服务器到应用服务器会出现延迟,目前还没有结论。待更新

http://blog.51cto.com/h2ofly/1957171
http://developer.51cto.com/art/201704/536923.htm?foxhandler=RssReadRenderProcessHandler

记一次微信小程序在安卓的白屏问题

在做小程序的时候,做到了一个限时商品售卖,用到了倒计时,因为这个原因导致了安卓手机上使用小程序时,将小程序放入后台运行一段时间后,再次进入小程序后出现了页面白屏或者点击事件失效的情况,这里记录下

1.相关代码文件

我这里是使用了自定义组件的形式来渲染的
  • 外部的引用的自定义组件的wxml文件

/* limitCommodity是一个数组,返回的是商品对象,包含商品价格、商品结束时间、商品图片等 */
&lt;block wx:for="{{limitCommodity}}" wx:key="{{item.id}}"&gt;
    &lt;commodityItem class="specialContent" goods="{{item}}" /&gt;
&lt;/block&gt;
  • 自定义组件的js文件

Component({
  properties: {
    goods: Object
  },
  data: {
  },
  timer: null,
  /* 在组件实例进入页面节点树时执行,开始定时器 */
  attached: function() {
    if(this.timer) {
      clearInterval(this.timer);
    }
    this.filterTime();
    let that = this;    
    this.timer = setInterval(function () {
      that.filterTime();
    }, 1000)
  },
  /* 在组件实例被从页面节点树移除时执行,将定时器清除 */
  detached: function() {
    clearInterval(this.timer);
    this.timer = null;
  },
  methods: {
    /* 用于将时间戳转换成自定义的时间格式 */
    filterTime() {
      let totalTime = new Date(parseInt(this.data.goods.endtime) * 1000) - new Date();
      let days = parseInt(totalTime / 1000 / 60 / 60 / 24, 10);
      let hours = parseInt(totalTime / 1000 / 60 / 60 % 24, 10);
      let minutes = parseInt(totalTime / 1000 / 60 % 60, 10);
      let seconds = parseInt(totalTime / 1000 % 60, 10);
      let day = days &gt;= 10 ? days : '0' + days;
      day = day == 0 ? '' : day + '天';
      let hour = hours &gt;= 10 ? hours : '0' + hours;
      let minute = minutes &gt;= 10 ? minutes : '0' + minutes;
      let second = seconds &gt;= 10 ? seconds : '0' + seconds;
      this.setData({
        limitTime: day + hour + ":" + minute + ":" + second
      })
    },
  }
})

2.引起的原因

  • 因为在外部引入自定义的组件时,直接就是调用了定时器并且进行了setData操作,这就导致了当在外部引用这个组件时,如果传入的商品数组长度较大时,定时器增多的同时,setData操作也不断的增多
  • setData多了就会导致内存占用多

3.改进方法

改进方法就是减少setData操作
  • 可以再自定义一个组件,用于将整个数组传入
  • 然后对商品数组里的时间先进行计算
  • 改进后的js文件

Component({
  properties: {
    limitCommodity:Array
  },
  data: {
  },
  timeOut:null,
  /* 在组件实例进入页面节点树时执行 */
  attached(){
    this.calculate();
  },
  /* 在组件实例被从页面节点树移除时执行,将定时器清除 */
  detached(){
    clearTimeout(this.timeOut);
    this.timeOut = null;
  },
  methods: {
    filterTime(endtime) {
      let totalTime = new Date(parseInt(endtime) * 1000) - new Date();
      let days = parseInt(totalTime / 1000 / 60 / 60 / 24, 10);
      let hours = parseInt(totalTime / 1000 / 60 / 60 % 24, 10);
      let minutes = parseInt(totalTime / 1000 / 60 % 60, 10);
      let seconds = parseInt(totalTime / 1000 % 60, 10);
      let day = days &gt;= 10 ? days : '0' + days;
      day = day == 0 ? '' : day + '天';
      let hour = hours &gt;= 10 ? hours : '0' + hours;
      let minute = minutes &gt;= 10 ? minutes : '0' + minutes;
      let second = seconds &gt;= 10 ? seconds : '0' + seconds;
      return day + hour + ":" + minute + ":" + second
    },
    calculate(){
      let limitCommodity = this.data.limitCommodity;
      for (let i = 0; i &lt; limitCommodity.length;i++){
        limitCommodity[i]['endtime_date'] = this.filterTime(limitCommodity[i]['endtime'])
      }
      this.setData({
        limitCommodity
      })
      this.timeOut = setTimeout(()=&gt;{
        this.calculate();
      },1000);
    }
  }
})
  • 改进就是计算时间后再返回时间,而setData的是整个商品列表数组,这样就减少了setData次数
正在努力学习中,若对你的学习有帮助,留下你的印记呗(点个赞咯^_^)

来源:https://segmentfault.com/a/1190000017478925

以上是关于记一次微信小程序页面加载慢的排查过程的主要内容,如果未能解决你的问题,请参考以下文章

记一次微信小程序人脸比对开发

记一次微信小程序在安卓的白屏问题

记一次微信支付开发的坑!!

记一次微信小程序开发

记录一次微信小程序getUserProfile的踩坑经历

记录一次微信小程序getUserProfile的踩坑经历