评论

抽奖助手小程序优化过程记录

抽奖助手小程序优化过程记录

本文背景

抽奖助手小程序开发采用云开发模式,通过本次总结可以看到,当云开发小程序数据达到一定级别(比如单个集合数据超过10万)会不会存在瓶颈,这个问题我只抛出来,不做结论


首先说明一下,小程序本身没有问题,在用户少的情况下,没有太多历史数据积累,小程序非常流畅,本文讨论的具体场景是当存在较多历史数据,小程序日活UV相对较大,比如5000左右,单个抽奖参与人数在1500,每天投放100个抽奖奖项,这种量级

集合添加索引已经不能解决问题了,小程序过多依赖云函数,但是云函数请求已经超出20秒的上限


f

f

问题表现

f

当云函数由于超时报错时,首页抽奖记录不能展示,首页就只有很空的两个广告

通过下图左边面板我们不难看到,云函数调用失败的频率太高了,云函数失败有两种原因

1、云函数整体调用时间超时

2、云函数内部执行某种数据库查询超时

调用失败,代表首页抽奖列表页不能正常展示,抽奖的入口就没有了,问题非常严重,由于目前云函数使用大量的联表查询,联表查询在数据量过大的时候,必然会存在这种问题,所以说只能从逻辑上优化


首页的逻辑就是根据当前用户查询抽奖列表,并根据用户已参与的抽奖,进行状态标记,从逻辑上很简单,我举个例子

当前未开奖,也就是可抽奖有以下几条记录

001、002、003、004、005、006、007、008、009

当前用户已参与的抽奖有

001、002、003

那么需要在展示的时候,把001、002、003的状态标记为已抽奖

通过两次查询,便可以完成,具体代码在云函数queryLottery中,由于代码是开源的,对该优化代码感兴趣的可以打开看看,具体的对比效果如下图所示

f

之前联表查询20秒都不够,现在只需要100毫秒,效果非常明显的,提高了200倍

f


本文内容

抽奖助手小程序包含了三个核心模块

(1)首页,主要展示,中奖记录以及奖项记录

(2)详情页,顾名思义,就是单个奖项详情,主要展示详情信息,比如参与人数

(3)我的,主要统计我参与抽奖的一个统计信息

截止目前,我已完成上面模块中(1)(3)的优化,具体优化的过程,我会在本文详细的阐述下,对于模块(2)的优化,我会在后面补充或者单独开一篇新的文章用来记录




本文总结

本文首先描述了,当前小程序遇到的瓶颈,然后给出了具体的优化方案,通过这次优化将云函数提高了200倍,20秒降到100毫秒,在这里通过实践可以给出一个结论:

在数据量大的情况下,为充分利用索引的作用,不建议做联表查询,可以将联表分开拆成多个单一集合查询,然后通过逻辑来实现联表的作用

最后一次编辑于  08-05  
点赞 1
收藏
评论

1 个评论

  • 海棠依旧
    海棠依旧
    08-05

    无法通过代码实现,就付费升级配额

    08-05
    赞同
    回复 2
    • 小肥羊
      小肥羊
      08-05
      套餐没有用的,现在不是套餐的问题
      08-05
      回复
    • 小肥羊
      小肥羊
      08-05
      数据量大了,云函数的上限时间,不是换个套餐就可以提高的
      08-05
      回复
登录 后发表内容