记一次翻页性能优化

这篇具有很好参考价值的文章主要介绍了记一次翻页性能优化。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

背景

   由于是公司项目,所以不方便给出代码或者视频,只能列一些自己画的流程图。

记一次翻页性能优化

   大致情况如上,前端有7个显示区。在对其进行滚动翻页的时候,存在以下问题:
1. 连续滚轮翻页,每次所有显示区刷新完,进行下一次翻页用时较久。(说人话就是,平均耗时翻页时间长)
2. 连续滚轮翻页,会出现一下子翻不动,然后连续刷新很多层的情况。且有的显示区更新快,有的层更新更新很慢。

分析

   通过分析代码,调查log发现,翻页切换平均耗时在600ms。其主要的业务逻辑如下:
1.前端线程发送同步翻页命令给后端
2.后端进行处理,共7个显示区。前三个每个耗时30ms左右,后4个业务处理平均需要100ms。在后端处理过程中,已完成的场景数据,已经异步发送给前端。
3.前端等到后端处理完数据,根据接收数据,进行前端绘制,耗时110ms左右。

记一次翻页性能优化

问题

主要问题有三个:

1.后端处理逻辑耗时太长了,特别是后4个场景。
2.前端等到后端逻辑处理完,才可以UI渲染,中间白白等待,耗时过长
3.在前端连续翻页情况下,有可能出现,第一次翻页的场景还没渲染完(只渲染了几个区域,或者一个都没有),就开始发送下一次渲染。造成“卡很久,然后一下次渲染好几帧的现象”。

解决

优化有3点:
1.以空间换时间。把耗时的即时计算操作,提前计算好,存储在内存中。那么在翻页过程中,就只是拷贝数据。
2.将图像刷新从同步改成异步。
    2.1前端发送命令变成异步(这里最初同步是有一些业务需求,需要改造)
    2.2我们的后端框架的刷新逻辑由两部分组成:数据序列化+发送。如果采用同步,后面4个场景的序列化的总时间,大概需要200ms。如下图所示。如果采用异步,那前端阻塞的时间,就几乎可以忽略不急

记一次翻页性能优化
3.同步机制

   前两点优化以后,翻页速度非常快。主要耗时只在后端序列化+发送数据+前端处理,可以达到200ms左右一次翻页。但存在异步刷新的问题。具体情况如下:

记一次翻页性能优化

1.第一次翻页后,后端发送给前端数据,前端还只收到前两个场景的数据,并渲染。
2.前端收到翻页指令,接着发送翻页。后端发送7个场景,因为前几个场景,数据少,很快又发到了前端。
3.前端渲染第二次翻页的前几个数据
4.前端渲染第一次和第二次的剩余数据。

解决:

后端在收到翻页指令以后,先等待自己上一次所有场景都刷新完,再接着序列化、发送。这样前端数据就能最大程度的进行渲染了,不会出现错位。

总结

最后的流程图如下,从最初600ms左右延迟的卡顿翻页,如今变成200ms左右的稳定翻页,优化效果非常不错。
记一次翻页性能优化文章来源地址https://www.toymoban.com/news/detail-743819.html

到了这里,关于记一次翻页性能优化的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 记一次 JMeter 压测 HTTPS 性能问题

    在使用 JMeter 压测时,发现同一后端服务,在单机 500 并发下,HTTP 和 HTTPS 协议压测 RT 差距非常大。同时观测后端服务各监控指标水位都很低,因此怀疑性能瓶颈在 JMeter 施压客户端。 切入点:垃圾回收 首先在施压机观察到 CPU 使用率和内存使用率都很高,详细看下各线程

    2024年01月21日
    浏览(43)
  • 记一次SpringBoot应用性能调优过程

    使用SpringBoot、MyBatis-Plus开发一个接口转发的能,将第三方接口注册到平台中,由平台对外提供统一的地址,平台转发时记录接口的转发日志信息。开发完成后使用Jmeter进行性能测试,使用100个线程、持续压测180秒,测试结果如下,每秒仅支持8个并发。 服务器 作用 CPU核数 内

    2024年02月03日
    浏览(44)
  • 优化记录 -- 记一次搜索引擎(SOLR)优化

    某服务根据用户相关信息,使用搜索引擎进行数据检索 solr 1台:32c 64g 数据10gb左右,版本 7.5.5 应用服务器1台:16c 64g 应用程序 3节点 1、因业务系统因处理能不足,对业务系统硬件平台进行升级,升级变更为 16c64g — 32c64g 增加 16c 2、业务系统升级,处理能力增加,对原搜索引

    2024年02月05日
    浏览(63)
  • 记一次项目内存优化--内存泄漏

    主要是与某个版本作基准进行对比(一般是最新版本的前一个版本作原数据),优化后,PSS有所下降,线上OOM率减少(Bugly版本对比),泄漏点减少(从捉取一些线上上传回来的内存堆栈信息分析,或本地测试后dump下hprof文件分析)。 了解什么是内存泄漏 了解虚拟机中的对象

    2024年02月12日
    浏览(77)
  • 记一次 Oracle 下的 SQL 优化过程

    事情是这样的,UAT 环境的测试小伙伴向我扔来一个小 bug,说是一个放大镜的查询很慢,转几分钟才出数据,我立马上开发环境试了一下,很快啊我说😏,放大镜的数据立马就出来了,然后我登录 UAT 环境一看,诶是有些慢😕 ,于是开始了我的排查之旅... 首先我立马拿到了

    2024年02月05日
    浏览(42)
  • 【Swift】公司项目性能优化(一)

    随着项目开发接近了尾声,改Bug和性能优化成了工作的重中之重,移动端开发,最注重用户体验,一个丝滑般的应用程序能在用户心里加很多印象分。 1、优化列表的滑动速度 作为内容创作类的app,里面包含了大量的写作、画作、小说、动态等多种动态高度的样式;列表滑动

    2024年01月20日
    浏览(51)
  • 【PyTorch】记一次卷积神经网络优化过程

    在深度学习的世界中,图像分类任务是一个经典的问题,它涉及到识别给定图像中的对象类别。CIFAR-10数据集是一个常用的基准数据集,包含了10个类别的60000张32x32彩色图像。在上一篇博客中,我们已经探讨如何使用PyTorch框架创建一个简单的卷积神经网络(CNN)来对CIFAR-10数

    2024年01月24日
    浏览(47)
  • 记一次生产慢sql索引优化及思考

    夜黑风高的某一晚,突然收到一条运营后台数据库慢sql的报警,耗时竟然达到了60s。 看了一下,还好不是很频繁,内心会更加从容排查问题,应该是特定条件下没有走到索引导致,如果频繁出现慢查询,可能会将数据库连接池打满,导致数据库不可用,从而导致应用不可用。

    2024年02月04日
    浏览(47)
  • 记一次线上问题 → Deadlock 的分析与优化

    今天女朋友很生气 女朋友:我发现你们男的,都挺单纯的 我:这话怎么说 女朋友:脑袋里就只想三件事,搞钱,跟谁喝点,还有这娘们真好看 我:你错了,其实我们男人吧,每天只合计一件事 女朋友:啥事呀? 我:这娘们真好看,得搞钱跟她喝点   MySQL8. 0.30  ,隔离级别

    2024年02月15日
    浏览(48)
  • .Net6 记一次RabbitMq消息订阅/发布优化

             首先介绍一下项目情况,项目需要设备在线实时采集,最高采集频率为1次/秒,设备上传数据时,协议规定的是10条/包,服务端通过rabbitMq接收消息,并进行存储、预警、推送等进行多层处理,因为web端要求数据实时展示,且延时不得超过1分钟,因数据量较大,

    2024年01月18日
    浏览(46)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包